Comment by lucideer
11 hours ago
I've been in such an org, & I've led initiatives to set up automated detection at very large scale. We started by issuing tickets to teams to resolve CVEs within varying timelines - ranging from a 24hr fix to 6 months - connected to the CVSS score. It wasn't viable.
- Firstly, you quickly realise how irrelevant CVSS scores are - initiatives like First's EPSS are designed to fix this but they aren't there yet
- Secondly, you need to begin implementing localised heuristics to determine exploitable code paths. This has generally been incredibly difficult to do reliably - LLMs have started to make it easier, but it's expensive.
- Lastly, you need to factor in consideration of actionable remediation pathways. A dependency upgrade for critical infrastructure might contain breaking changes that take months to fix, or two competing CVEs might be present in interdependent versions of transitive dependencies in your sbom tree.
Most orgs aren't applying any of the above three filters to reduce their CVE remediation burden, & even if they are, it's still too high to make zero a viable target.
In reality, most orgs aren't doing comprehensive detection to begin with - if you haven't discovered all of your CVEs, your remediation burden is going to be a lot more manageable.
> - Firstly, you quickly realise how irrelevant CVSS scores are
Even if you factor in the environmental score? I realize it's a lot more work, but it basically allows you to tune the score to get any value you want.
Imagine a YAML parsing library that can cause an out-of-memory exception if you give it a YAML file greater than 3 megabytes.
If you're an online service where untrusted users can submit arbitrary YAML, and an out-of-memory exception is a severe problem, then it's severity 10.
If you're an online service that doesn't use yaml in any way, but your web framework bundled the library as a transitive dependency because yaml is one of their five supported configuration options, then it's severity 2.
The problem is figuring out which of those situations you're in takes a load of time - and the flow of CVEs is endless, as CVE numbers are given out like candy at halloween. Often it's quicker to just update to the latest version of the YAML library.
Exactly, the amount of time it takes to figure out if you're exploitable generally exceeds the time to patch the application in the majority of the cases. You tend to try to focus on the ones that will cause the most interruption.
And then you can have all kind of other fun things, like users don't upload YAML so you think you're safe, but a clever hacker figures out another minor parser error that makes your JSON seem like YAML and suddenly YAML.so has loaded and you're now parsing a document that shouldn't be possible.
I could reword that CVSS is useless on its own - EPSS takes CVSS as an input afterall. The point here is that applying environmental scoring is the hard part. That's the algorithm that's containing the complexity.
True, I guess you might as well evaluate each vulnerability yourself without the CVSS base score.