All right, so we are starting, and the next stop is Rauh and Gork, we'll take about
Vex, cutting through the noise in software supply chain security, we'll allow it. Isn't it close?
Thanks a lot. Hi, welcome everybody. Really, thank you for being here. I really appreciate it.
It has been a long day for everybody. I love the air and this room. It's fantastic.
So finally, we are going to talk a bit about Vex today. The state of the technology, the maturity,
adoption across the industry, where do we stand? What's the state of the nation? Who are we?
My name is Kia Kunz. I'm with Ericsson. I work in Ericsson's open source program office, and besides doing
the open source program office, things I also do, some things in the open SSF, just like Rauh.
I gave everyone Rauh Lakakula and from Microsoft, I managed the open source ecosystem strategy.
As part of that, I managed a billion of those foundations out there.
Cool, thanks. So, now when we look at a typical day in the live of security team,
we notice that those security teams are basically drowning in vulnerabilities. They need to handle.
There is, of course, rightfully due to an increased awareness of the importance of handling vulnerabilities,
regulations such as the CRA that are kindly nudging manufacturers to take this more seriously.
But also contributing to this is like the architectural thing.
Modern applications are built obviously on top of hundreds of open source components.
With deep dependency chains, right? And if any or any of those dependencies can be hit by a vulnerability,
and that can, of course, well, that is a vulnerability report the team needs to look into.
Because the thing is, at the end of the day, it turns out that not all of those vulnerabilities are really harmful, right?
So it really requires a human currently to look into this,
and look into this, curate this, find out what's harmful, what's not.
And that, of course, is a lot of tedious, stupid work.
And the only real solution to that is to kind of replace this manual effort by a precise,
you know, data-driven process that takes in accurate data,
and allows teams to focus on what is important.
They really, the problematic security issues.
And this is where Vx comes in, Vx to the rescue.
Vx stands for vulnerability, exploitability, X change, and it is, in a nutshell, maybe over-simplifying.
But you can look at it as ideally kind of a negative security advisory in the sense that it's a document or a statement telling you that for a given application,
a given vulnerability is, no, sorry, that application, given application is not affected by a vulnerability, right?
It allows you to kind of sort out some of the non-applicable vulnerabilities.
There's a little bit more to it, but for now, that should be it.
So this is a data-based approach to say, to cut through all of that noise of all those vulnerabilities coming into the teams, to eliminate false positives,
and finally to automate vulnerability and handling, of course, but also risk assessment, right?
So this is the idea, this is the vision of Vx.
But where do we stand really in terms of the maturity of the technology?
It's adoption across the industries, ways of working, tooling.
And this question or all of these questions is basically what a team of industry experts from Google, Microsoft, Redhead, and other folks wanted to find out.
So a couple of months ago, they came together and conducted interviews with other industry experts, for instance,
with Sousa, Debian, Ericsson, for instance, to kind of ask them questions, like, what is your perspective on Vx?
How do you use it, what are the challenges, does it bring you value or only pain?
So those results basically from those conversations and interviews, the team has compiled into white paper that was recently published by the OpenSSF and by OASIS,
and basically the single line result of that white paper, please read it, you'll see the URLs later on.
Sure, the technology is great, we definitely need it, but it is currently not yet fully rolled out, and doesn't live up obviously,
yet through its full potential.
Adoption is inconsistent, everybody does it a little bit differently, so they're not yet agreed ways of working.
And there are different formats, it's usual, there are different standards, right?
I'm not advocating for a single fifth standard, but they're currently for SPDX and SectownDXs, as bomb formats allow to embed Vx information,
but then of course this open Vx and C-SF Vx.
And yeah, so there are a couple of challenges that the team identified and brought down in this white paper and they're trying to briefly run through those.
The first one is discovery and distribution.
It is, in fact, surprisingly hard to get your hands on a Vx statement for a given application,
because there's, again, no consistency in how to do this.
Some vendors use an API based approach, other web pages, repositories, registries, open source projects,
and I put it in the GitHub repo.
So, well, that's all good and done, but it makes it hard to automate, right?
Obviously, that's not yet what we need really.
Verification and trust is an issue, of course.
Some of the formats like open Vx, they have already atostations in mind,
but this not yet an industry aligned way of saying,
okay, we're going to sign these statements like this, and then you can verify it like that.
Of course, there is technology to do that, but what is the recommended way of doing it?
Who do you trust for a given thing, a maintainer, a distributor, a manufacturer, open questions?
Tooling maturity is a thing, and that does not necessarily mean that the tools are necessarily bad or incomplete,
or have bugs, well, all software has bugs, but for instance, CSF Vx is, by design, a fairly complex spec,
because it is meant to model complex commercial products.
That also makes the tooling harder to use, right?
In an open source project, do we want to maintain it to use complex tooling maybe not?
So, where's the middle ground?
How can we improve that?
mismatch life cycle.
It's a briefly mentioned that SPDX and cycling in the access,
as bomb formats allow to embed Vx information that is good,
but we need to realize that there is a life cycle mismatch.
As bomb is relatively static and associated with build, time, point in time,
thing for an application.
But Vx is supposed to be, you are supposed to have a new statement,
basically, for any new vulnerability coming in.
So, obviously, there are timeline issues.
Software identifies, I have to admit, this is still like an industry challenge
when we're making improvements and it's not solely due to Vx,
but that would also be great to have sorted out.
Yeah, an education, of course, obviously open source projects may not see
the need yet why they should publish this.
Some other manufacturers might see publishing Vx documents as a business case
and not a good security means, so that needs to also be sorted out.
But we have recommendations, right, Rao?
This is if we fix all the challenges, thus the recommendations.
So, on reality though, most all the challenges actually go out
to mention those are the areas to improve.
But we do have some in-place systems, right?
I think what we need is a consistent to bring all those to be useful.
So, first one is obviously, we need to build a common distribution system
where we know for the manufacturers where we can get a trusted
Vx statement for each of them.
As God mentioned, like, right-hat publishers through API.
Microsoft publishers through one of the websites.
Obviously, everyone has their own weight of distributing.
On top of it, even when you find the distribution channel,
how do we verify, how do we verify this is actually coming from Microsoft?
How do we trust it?
So, what we're proposing is, I think, we need to build a common distribution mechanism
and ideally hosting a neutral place like open SSF, like a Vx hub.
We do have a new construct by aquasica, come up with a Vx hub construct.
But obviously, it's not in a neutral place yet.
C-suff has actually, as C-suff got IO, BSI has a Niagara gate.
So, we have kind of distributed set, but they're not consistent.
So, what we're proposing is how, at least for the manufacturers,
couple of places where we can know consistent format and consistent
way to grab those.
Mechanism and also, open source, obviously, there's a big gap.
We need to have that hub where we can grab the open source,
Vx statement.
The tooling, also, as mentioned earlier, it's a spectrum, right?
Like, for if you look at the Go ecosystem, the tooling is pretty good.
There's a VxCTL for open vaccination, C-suff has a support for goal libraries,
Python is pretty good, but if you look at, like,
Java, Rust is especially, there's very little to no tooling to actually generate
this Vx statement.
So, what we're looking is for most common ecosystems,
we need to invest on building the tooling to make the doubt.
It's easy to generate.
I have to give that.
The NLI and I'm the standards without excluding other.
Obviously, when we studied and interviewed, most of the manufacturers
that are leaning towards the C-suff, mainly because C-suff being the
Defactor standard for publishing the vulnerability.
So, it makes totally sense.
If you are already doing that, let's go use the C-suff Vx,
because it's an edition.
But if you are open source, maintainer, and if it's actually
you have a better tooling for your ecosystem for any of the format,
go with, like, so the format doesn't matter, but I think producing
the Vx statement, and then building the tooling to actually do
intrapal, that's the area we have to focus on.
And then, obviously, the clarify experts, I mean, we don't also
don't want to overload the Vx.
It's purely meant to say, am I affected or not affected?
That is the main purpose.
But I think we don't want to overload that too.
And then, obviously, there is a great progress in the last six months
on the identifier, part will be in getting standardized by Ekma
and ISO.
I think eventually, we need to get all these Vx formats to adapt.
I identify, stick to it, and make it easy for the folks to go.
And then, class, industrial collaboration, obviously, this is a time I think
manufacturers, maintainer, towards need to get together,
and actually start producing those, because otherwise,
when the CRS start hitting, everyone going to have an issue
to understand, hey, am I impacted or not, which one should I be reporting?
I think the Vx is the only way we can get to it.
Like, the future direction, I say, like, they're up.
We're proposing few opportunity to improve the CSF for make it easy for open source
developer, same way for the open Vx.
How do we navigate to that good balance?
And then, also, building these Vx aggregators at least,
couple of them for manufacturers for the open source packages,
where do we host them?
And then, the second thing is, obviously, we don't want to give additional
to the maintainers.
But how do we embed this into the GitHub actions?
And also, of the CICD pipeline, so that Vx statements are automatically
generated as part of your SBOM, is something.
So, open SSF already have a vulnerability management workgroup, open Vx.
SIG, we're also proposing to start a Vx adoption group.
Like, we would love you to come and join those groups.
We'll get one minute.
Yep.
Okay.
Gathering the cloud.
Gotcha.
That's how we let's go, like, okay.
In conclusion, obviously, we put a lot more details in the white
paper, which is published in open SSF.
And also, on the way as this, you can scan the QR code here.
In conclusion, obviously, Vx is the only sane way for us to get
off the vulnerability strong, especially with the CIRA.
Definitely for the manufacturers.
I think that's where we are actually looking.
Manufacturers to start the lead and invest in the tooling,
involving the community so that we can make it easier for the
developers and maintainers.
And then, obviously, we are only to hear presenting,
but this work is done by so many other people from
turn off companies.
We also interviewed a lot of the vendors, scanning vendors,
also the package publishers, the VMs, Linux distributions,
others.
So, thank you for all those folks contributed to this study.
Think we got time for a couple of questions.
Oh, we don't.
Okay, cool.
Thank you, everyone.
Thank you.