Step 1 would be to not treat vulnerability == CVE. It's a simple change in terminology but we need to make sure to communicate that CVEs are just one, probably the most popular, but just one source of vulnerabilities.
Governance and security teams the world over need to learn this.
Next step ist to establish good tooling around publishing VEX statements (Vulnerability Exploitability Exchange). That is currently not easy.
In the EU we currently have the discussions about the upcoming Cyber Resilience Act which has language in it that says products must be "free of known vulnerabilities" to be allowed to be placed on the European market. We're trying to change that language but it ain't trivial. The current best proposal is saying "known _exploited_ vulnerabilities".
Otherwise I'd be able to DoS my competitors by publishing bogus vulnerabilities.
For that we have at least two sources: CISA KEV[1] (which just celebrated its thousands entry) and FIRST EPSS[2]. There might be more, these are the ones I'm aware of.
We are a software vendor and we want to do the best we can but at the moment it's a box ticking exercise that's not useful to anyone. We want to look at all vulnerabilities but we want to focus on the important ones. We need to be able to say "our product is not affected by this vulnerability" and we need our customers to trust us. Currently, they often trust the CVE/NVD database more which is a huge problem because they are not experts in the specific products.
And especially for things like libraries you need to take the context into account in which it is used. Vulnerabilities are reported (using CPE, pURL etc.) at the "library" or "application" level but they really exist at a much more granular level (e.g. a single function is affected and if that's not used there's no problem).
I'm convinced that the whole space of vulnerability disclosure and management will change significantly over the next few years.
We happened to stumble into this and are now active in trying to shape the Cyber Resilience Act into a form that makes more sense because that will force basically every European company to now start this process. Other countries will follow (yes I know the US already has rules for some sectors but not everything, so do other countries).
It's not only that the CVE database / process is broken, but via EO 14028 in the U.S. and CRA in Europe transparency is mandated via SBOMs. While I believe this transparency is good, it can be abused to enforce compliance-driven security: Fix all critical, high and medium CVEs within well defined time frames. PCI DSS and many other standards kind of encourage that view already today. It will then just be measurable by outside parties, which then means the limited security budget will be used to "fix" things that don't matter as much.
And I agree with you, Lars: We should be using CISA's KEV, First's EPSS and other means. But I'm not sure software customers would accept seemingly higher risk (high number of unfixed critical / high CVEs), even if the EPSS suggests overall much lower risk.
I've written in longer form at [1] about this issue.
> Next step ist to establish good tooling around publishing VEX statements (Vulnerability Exploitability Exchange). That is currently not easy.
Agreed.
Tooling is needed for creating/publishing/consuming both VEX statements for applications (i.e. exploitability of a dependency in context), but also VEX statements from library authors (many times the actual experts, like the OP) as a way dispute the weakness/exploitability.
Currently working hard on this [1]. When the tooling is in place the next step for the industry will be discoverability of SBOM/VEX/VDR attestations. Sigstore/Rekor [2] looks to be a viable alternative here.
> Vulnerabilities are reported (using CPE, pURL etc.) at the "library" or "application" level but they really exist at a much more granular level (e.g. a single function is affected and if that's not used there's no problem).
Again, agreed. Reachability info needs to be commoditized, standardized and shared. The current situation where it's a feature used by vendors to compete is not ideal.
Do you have any thoughts on CVSSv4[0]? It appears to incorporate finer-grained and organization-specific scoring to address issues many have with the one size fits all approach currently used for CVEs.
This already exists today where you can do custom scoring and some companies (e.g. Red Hat) already do so.
CVSSv4 fixes some things, yes, but not the underlying issue which isn't so much a technical challenge (partially, sure) but a shift in policies and thinking.
The current model of "we need to get to 0 vulnerabilities in our scans" will lead to malicious compliance[1] and worse results compared to being able to focus on the few vulnerabilities that are really important.
At least that's my very strong opinion.
Step 1 would be to not treat vulnerability == CVE. It's a simple change in terminology but we need to make sure to communicate that CVEs are just one, probably the most popular, but just one source of vulnerabilities. Governance and security teams the world over need to learn this.
Next step ist to establish good tooling around publishing VEX statements (Vulnerability Exploitability Exchange). That is currently not easy.
In the EU we currently have the discussions about the upcoming Cyber Resilience Act which has language in it that says products must be "free of known vulnerabilities" to be allowed to be placed on the European market. We're trying to change that language but it ain't trivial. The current best proposal is saying "known _exploited_ vulnerabilities". Otherwise I'd be able to DoS my competitors by publishing bogus vulnerabilities.
For that we have at least two sources: CISA KEV[1] (which just celebrated its thousands entry) and FIRST EPSS[2]. There might be more, these are the ones I'm aware of.
We are a software vendor and we want to do the best we can but at the moment it's a box ticking exercise that's not useful to anyone. We want to look at all vulnerabilities but we want to focus on the important ones. We need to be able to say "our product is not affected by this vulnerability" and we need our customers to trust us. Currently, they often trust the CVE/NVD database more which is a huge problem because they are not experts in the specific products.
And especially for things like libraries you need to take the context into account in which it is used. Vulnerabilities are reported (using CPE, pURL etc.) at the "library" or "application" level but they really exist at a much more granular level (e.g. a single function is affected and if that's not used there's no problem).
I'm convinced that the whole space of vulnerability disclosure and management will change significantly over the next few years.
We happened to stumble into this and are now active in trying to shape the Cyber Resilience Act into a form that makes more sense because that will force basically every European company to now start this process. Other countries will follow (yes I know the US already has rules for some sectors but not everything, so do other countries).
[1] <https://www.cisa.gov/known-exploited-vulnerabilities-catalog> [2] <https://www.first.org/epss/model>