Okay, afternoon, there will be no inter-active clapping, apart from at the end when you like this
presentation. Okay, like this talk is about Vex and another tool that you've mentioned that we've
heard all that you heard about and this is a story and I'm really representing somebody who should
be here but for lots of travel reasons you couldn't get here. So who am I? I've been delivering software
a long time, 40 years and I've got stills my software is still 40 years old, well before
security, well before S-bomb for every even thought about. I now, for me I'm company,
APX10, focusing on the world of S-bombs, trying to help educate people and how good S-bombs can be,
how to use S-bombs, how to create them and how to get the insights because there's a lot of valuable
data in there. I'm also a founder with Ali of S-bomb Europe where we want to try and help the community grow.
Where we want to help the community grow, there's a lot as we've already heard today
we're hearing a lot there's a lot of valuable information, how can we make that information valuable
for everybody. I write open to software, lots of S-bomb tools, I'm a STEM ambassador, that's
fine, includes the next generation of engineers and tell them how to write good secure software
and then I'm actually maybe able to retire and I'm a mentor.
One of the things I've been mentoring is for the Google Summer of Code and this story is about
my experience with Google Summer of Code last year and I'm from Manchester, Manchester has a
B, we're busy, we work and I'm also a member of O-Woss and that's not the O-Woss,
that's the Manchester B and most of the weekends I end up running round ruddy fields,
that's what I enjoy doing away from technology. This is about CVA Bintill, Chris mentioned it,
one of the features that Chris found was just putting there to see whether anybody wanted to use it.
Now I know Chris wants to use it, we may improve it, and that's one of the challenges of open
source, you never know what features people use, you don't get that feedback unless people put
requests or put features requests, okay? So messages from the community, that tools available
make it better by contributing. So for CVA Bintill, starters as a tool in Intel, I think it's
started at heartbleed when you try to find open SSL. It was to try and protect the business
from shipping, vulnerable libraries. It got open source to about 2020, which is when I got
interested in it, and over time it's added more and more features, I added S-Bomb features into it,
and every year we have one of the Google Summer of Code projects and that's where we get
students helping us add new features. So we've added S-Bomb, we've added support for the
known exploitable abilities from C-S, we've added EPS support, it's on GitHub, it's got 1000
plus stars, it's got 200 contributors, welcome to join our community.
2020-24 we had G-Sock Project, we had two two mentees meet and sounds gone from India,
three mentors, two on the west coast of the US, and we in Europe, challenge trying to get everyone
to talk to each other, so we find eight o'clock in the US time, nine o'clock in the
time UK, it's okay for me, sort of late afternoon, that's one of the challenges trying to keep
communication to go. But we worked. So architecture, they see if you build it as a number of
building blocks, we take data in, vulnerable data, we do stuff with it, we manage it, manage the
list of vulnerabilities to try and make them better, and then we triars them, and then we produce
various reports. So the challenge that I set the student was improving the triars process.
We all know, we get lots of vulnerable, it's reported, quite a lot of them are not white,
and we do process of sharing that intelligence, so the next time we do a scan, that's not
again, let's market again, we want to try and a better process of marking that
assessment. So the project scope and it's very vague in this list, we don't want to
frighten the students too much, and also we want to give them, we don't know where we're going to
get to, quite open-ended, was we wanted to get a triars file and associated with an S-bomb,
because we saw the value of an S-bomb and the triars file being quite a good unit together
to actually pass into the vulnerability triars in process.
We also wanted to support the standards. We've got two standards for S-bombs, we seem to have four
standards for Vx vulnerabilities. And we don't, you know, S-bombs have now had quite a few years
of experience, Vx hasn't really got that maturity, how are we going to manage that and the
adoption, are we going to get a market going to spread, because that's going to make it really
hard when you're going to share vulnerabilities, when the C-R-A wants you to share vulnerability
information, and you're going to have four formats, lots of people having to convert data,
but we can use T, maybe, in the future. So the triars process, very simply, is we take vulnerabilities,
we scan the S-bomb, we produce a candidate set of vulnerabilities, we triage them,
and then we produce a triage file. The triage is always going to have a manual element.
The engineer is going to have to make that decision, is the software vulnerability,
a real vulnerability, is the code exploitable, is it code readable? I'm sure we're going to get better,
but at the moment it's still quite a manual process.
Well, then we want to feed the results of that manual process back into the triave process,
so we don't forget that intelligence. So let me talk about Vx,
and we hold a bit about that from as fast as you're earlier on.
So it's vulnerability, exploitability, exchange, it's a variety of
exchanging information about whether vulnerabilities exploitable.
It is not just the list of vulnerabilities, which I increasingly see people using,
it's a way of communicating, phase all of all the abilities, with no real assessment.
So we want to look at it's like a security advisor, and we need to know whether that vulnerability
applies to your product. And we can all think about, you know, vulnerability,
depending on where it gets deployed will have a different impact. If you're internet facing,
that's a different, different potential scenario for me if you don't have any internal network,
same software, you need to be able to share that.
So let's look at the four formats, and it's quite hard, and I've tried to find the commonality.
Yes, a vulnerability identifier, a CVE, but there's lots of vulnerability identifiers.
What's the status?
Has it been assessed or not?
The all have status fields. The all have different ways of expressing status. There's no commonality.
How do you express a component? Are we down at the further lots of this morning and
afternoon about Pearl? Are we talking about a component at that level?
Or are we talking at the higher level, which is the integrated product? Like a router?
See, South is more at the router level. The other ones are more like at a software component level.
Can you link to an S-bomb? See, South really can with a bit of a bit of work,
the others are a bit more flexible. And then the final two are remediation.
If you have a vulnerability, what do you do about it? Is it, go to the next release of the software?
Is it a worker round?
I don't know. How do you express that information? Because that's all valuable information
that you want to pass to your customer, whoever that customer is.
And they're really what we're seeing is, these standards are looking at slightly different use cases.
See, South is looking primarily at the system. SPD-action cycle and DX are really looking at this supply chain.
And the open VACs, I think is a little just more about just sharing of vulnerabilities.
It's not really quite at the same level of context. All valuable, but different different use cases.
So I started thinking, how can we abstract them? It'd be really nice if you could make applications
ignore all these complicated different formats and data and just abstract it. So I created
lib for VACs and then I gave the students make it work. Nice challenge. And it follows something
similar to one or another one of my packages. But basically,
generate a VAC stock image in JSON format, which generally the all are,
pass them and extract the common information, and then create the new document.
And I had to make a constraint.
See South allows you to do a whole family of products.
I think because of that, it's a complicated standard. I've said, let's just focus on a single product
and try and get that to work. And that probably makes life a lot simpler,
the people to understand. Architecturally, it's just a layer,
sits above a couple of other abstractions that I've done and that can grow. So it's trying to make
it quite a simple API or the heavy lifting is done behind the scenes.
And generally all we're doing is we've got metadata, very similar to what we just saw previous
thing about S-bombs metadata, bit information about the products and then it's for these statements
for each of the vulnerabilities. Quite simple.
I had to make some decisions. The reason I wanted a link to an S-bombs was just
almost like a validation check. So if I got a list of vulnerabilities,
and against a number of components, if that component was not in the S-bombs, then I
wouldn't go to pass it through into the VACs. It was just to try and sort of
a brief sanity check. And what I also tried to do was to generate an update the document
and then create it. So if you're always asked for the latest VAC documents,
it was always called VACs at me wall. You would always get VACs at me one,
it was the latest version. And I would keep an order to the history.
Because it's probably quite useful to know at the moment in time, what did you
do on where were your assessments, where was each we have for process?
So very simply trying to keep it simple. Simple Python package,
create a set, create a product. It's got a name, it's got a release, and it's got an S-bombs.
Hopefully that's all you've already know that.
You've then got some metadata. Yeah, Fred floats. I think so, it's a very important supplier.
And these, the metadata, unfortunately, is not consistent among the standards. So you're probably
going to have to do a little bit of what's appropriate, but generally they are, you know,
reasonably sent straightforward. And the most important thing I think is really valuable for VACs,
why do you make a change? So with a revision reason. See stuff is really good, it
recognizes. That's a revision notes. Every time you're up a shoe, it says, why have you done that?
Well, that's really, well, we need that in all of our text documents. Why somebody updating
a text document as a key audit statement? Someone's done the triage or a new vulnerability is appeared.
That gives you the trace of ability. You know, if the regulator wants to say to see what your
process was in terms of addressing vulnerabilities, that would be a good way of capturing that
information to say, well, we assessed it on last Tuesday. And then specify the vulnerabilities.
It would be nice to be able to do it using Pearl or you may just do a name and version and the
identifier. Quite simple. Set the status. Yeah, the status is different depending on which version
at which type of VACs document you're following. Maybe we can try and come up with a nice mapping.
I've tried. It's not easy. And then maybe if you've got a vulnerability that's not affected,
then you can put the justification reason as well. Again, that's type of format specific.
Partying with specifying what type of, you're going to read a file.
I've now got it so you can just do also. So it'll automatically detect what type of VACs document is.
It might be quite useful if you're just a customer. Then you can extract the metadata for the product,
the vulnerabilities, or the just a general VAC document. The simple get statements.
So that's where we are. This worked example as a tutorial. It needs a bit of love, please.
And it needs a bit more documentation. I'll load up. It was a case of trying to get something going
and see whether it would work. So please go on there. Help. Don't just throw lots of pull requests.
Yeah, throw lots of pull requests. Not lots of issues, please. Yes, and make it better.
Because I think something like this is valuable. It could be very valuable for us all.
So how did see the event will do it? So in addition to integrating this, we came up with a load of
additional command line promises. See if you've been tools to CLI?
It's got a lot of command lines now because every year we add a few more. So we've added a whole load more
relation to VACs. So you specify if you initially go to create a three-hour file, you specify the output
file, the type of VACs you're going to produce and the name version of the product.
And then when you're doing it repeatedly, you're going to say, I'm going to do an update
and again specify the reason. So you can see how you could do this as part of your
maybe daily update. You're going to do a scan or every time you trigger a run of it because you've
got a new vulnerabilities coming to the U.D. detected a new vulnerability.
Quite simple. Every new vulnerability gets to default status, which is do something. Look at it.
If there are vulnerabilities already being assessed, we retain that status. Quite simple.
But there are some challenges.
And first of all, how do you validate a VAC document? So for CSAF, there's an interactive tool called
SETVISIOGRAM. But you put a VACS a CSAF into it and it gives you a nice traffic light red or green.
And that's the happy scenario when I get one to validate. It is trial and error. There's no command
line to interactively play with it and eventually you get everything green.
Cyclone DX, there are lots of validators. I think we've heard quite a much is a mature ecosystem
there. So there are a number of options for validation, command lines or online. What you
tend to find some of them like a little bit behind the latest version. So that online vulnerability
hasn't been updated to 1.6 year. I know there's a pull request into update it. Sometimes there's
a bit of a lag. But again, they will validate the validate against the schema increasingly they're
getting quite sophisticated. Where's the doll for? He's not here. Open VACS. It's been around for a
couple of years. There are example tools. There's no validator. So all I can do is look at the example
and try and replace the example. It looks right. But there's no validator. We need, if we're going to
use open VACS, we need validators. If we're going to create standards, we need to have
reference implementations and reference standards before the standard becomes a standard.
So I think it's what always trying to do with T. We'd finally build tools with the standard.
Because that's the way to, I've seen being made up successful is a way of getting a standard
mature quickly. And then let's be the X. So this is SPDX3. SPDX3 took a long time, didn't it? To get there.
And once you've got the standard, then they started thinking about the tooling.
There was need no tooling for quite some time. So when I started doing this last March April,
there was no validators. So all I could do was use this specification as my reference point.
To my thought, I'm creating next document, value to SPDX3.
Now there's a validator. And I wasn't creating valid documents. The documentation hasn't changed.
The validators are now there. The documentation that I was using doesn't match
what the validators are validating against. So hint hint, it would be nice if the schema that defines
the standard is also going to generate the documentation as well as documenting,
generating the tooling. Yes, but maybe there's still a few, possibly.
Yes, the might be. If we don't have an issue, we don't have an issue. So example, one of the things
was a relationship type. I had a relationship type that's something with it. I'm asking
you to have three fixed with security dash. And I have to find that by going into the schema.
And I could do that, not everyone's going to be able to do that. Anyway, we get in better,
which is good. Now validate. So it was validate. It took me two days to get it to validate this week.
Yeah, that was a good chance. But we do need to recognize the tools I still release,
candidates, Gary has been sending me stuff. So help.
Second thing is about scope. How do you know that X is complete? The same questions I've
read, you know, as S-bombs complete. We all know that the C-R-A is going to request you to sort
of state your statements of your vulnerable components. What's the stop you saying I've only got
full component for vulnerable components? There's my document. How do we ensure that the
X document is the complete truth point of truth of your products? And the other question is,
how do you demonstrate the opposite that I've got all the components of checked over components
and that are not vulnerable? How do I demonstrate that positive response? C-V-A to actually report
we found these components, we've scanned them and we can't find any vulnerabilities. That's
really valuable information that you want to pass. And we think we saw that earlier on about
comparing to S-bombs and say, well there's no vulnerabilities. That's really valuable information
you want to want to retain. So, Vex, we don't have a way of doing that yet.
And thirdly, is every Vex user fully hundreds of percent flu and ingestion and given this
four standards of Vex formats are this familiar with all four JSON formats.
Probably not. It's not a simple case of just changing the status from under under 3Rs to fixed.
You're going to have to put other digital data. We need a new tool that can help people
do this triage process. So, what we're going to do is, so this is on our G-Sect 2025 list,
that's potentially one of the projects that we will maybe get students to help us do.
I've maybe we need to understand what the community really wants for that.
What we have done, you can document the Vex's. So you can just give a Vex,
command line to give it a Vex and it produces human readable and that can be converted into
marked down HTML, PDF, Excel spreadsheet, various formats. That's a start that helps people understand
and gets away from the frightening room of JSON, but we do need to think about the ecosystem around
Vex to help people with this process. Because it's going to become a really important process
for the CRA and other regulations.
I'm starting to think about where the support says from the other various open source tools
that I'm aware of. SPDX has got to start because there's now a poorly-quest well,
there's an issue that will now become a poorly-quest. Now I fixed it this week.
What we can start seeing triavey depends on the strategy track starting to look at Vex
and I'm sure there will be other tools and I know that some commercial tools are starting to look at
this. Please, it would be great to build that map across all the tooling so we can see what that
what support is, or where the support needs is needed.
Loader tools, these slides are on the first website so you can go and happily click.
Always looking for help, money, normal things that open source developers want.
And you can find me on LinkedIn, let me get to the repository's various or the contacts.
Thank you very much. Any questions?