[lars_francke]

I'm not sure if you're replying to the correct thread?

All I'm saying is that all CVEs are supposed to be vulnerabilities but not all vulnerabilities have a CVE. So, the name artificially limits the scope of the product. Trivy reports more than just CVEs

[heads]

It was directed at you as you seem to know what you are talking about!

[lars_francke]

I have been tangentially involved in the Cyber Resilience Act (CRA). I'm more an interested party than a real expert.

We recently wrote a document on how we would like to approach our own vulnerability management process. It received a lot of comments and we'll gladly take more:

https://docs.google.com/document/d/1QB3EaimrS0KlL6wIpfY5-SlE...

To answer your questions then :)

> Do vulnerabilities normally get a patch and are we expecting upcoming regulation to require the patches are installed?

Not all vulnerabilities get a patch, it's really up to the project. But this is what the CRA is about. In the commercial context it will require vendors to handle vulnerabilities by e.g. providing patches. And depending on which industry you are in you might also be required to install said patches.

> If action is required to be taken when vulns are published do we all have to just uninstall the thing until the bug gets fixed, lest we invalidate our corporate insurance policy?

I doubt it but it's a good idea to have a good overview of what you're running in your company. This extends to dependencies which might be included in things you're running. That is what SBOMs are meant for. They will be required in the future.

> Will I have to cease my current policy of running Trivy, reading the CVE output, and then declaring (and making a git commit saying) “while this stdlib library technically supports CORBA and our OS technically supports IPX, we don’t use CORBA or IPX… or networking… or this library… so I’m ignoring this!”

No. That is excellent! It will be formalized into a machine readable format. Currently often called a VEX statement: Vulnerability Exploitability Exchange. One popularish format for this is CSAF. But CycloneDX (an SBOM format) can also be used for this.

Having this in a machine readable format makes it easier for users to consume the information.

The tooling for this is not great yet, which is what our document above is about.

Hope it helps.

Happy to chat about this if you're interested. Reach out if you like. Details should be in my profile.

[beardedwizard]

The question on everyone's mind is whether or not regulators (Fed/State RAMP, etc) will accept variances with a vex statement. The posture for the vast majority of businesses subject to this kind of regulation is "fix every single CVE regardless of impact".

[lars_francke]

That's a good question and I encourage you to join the CISA Working Groups on VEX etc. It is only indirect work but it might help steer things in the right direction.

I'm repeating myself but: CVEs are useless. Please don't use them as an equivalent for "vulnerabilities".

Regulators might take a few years to catch up but if I'm able to DDoS my competition with bogus vulnerabilities then people will do just that.

The CRA says that only "exploitable" vulnerabilities have to be fixed and it does accept VEX statements. So that's good. I would have liked to see "exploited" instead of "exploitable" but it's better than nothing.

I assume/hope the US will follow.

[richbell]

I love the hundreds of critical vulnerabilities on test libraries for nonsense like ReDOS or "if you write code that does something unsafe, it will do something unsafe."