The report, which is phrased as a press release, buries the lede. Some good quotes:
> I'm wondering if perhaps the Linux ecosystem is actually a bunch of aging infrastructure. If so, that fact might be obscured by seemingly healthy contributions to the Linux kernel. There's a ton of other "basic infrastructure" that gets shipped alongside the kernel, though: coreutils, binutils, gcc, make, autotools, cmake, zlib, xz, etc etc etc. -- Camdon Cady
> Our team at Socket catches 100+ software supply chain attacks in npm, PyPI, and Go every week.
> Software engineer Andrew Nesbitt has been playing around with the concept of a "blast radius" for open source security advisories on Ecosyste.ms. He uses the CVSS score of a security advisory multiplied by the number of repositories that depend upon that package to determine the “blast radius.”
I could see some value to a kind of measurement like that, but I agree that that particular method seems heavy handed.
This is partly what SBOMs are meant to solve for.
I’m also not sure calling Linux “aging infrastructure” that is obscured by activity in the Kernel is intellectually honest. Perhaps it’s better framed as a naive take. If the point is about shopping the rest of the OS (“all the dependencies” if you will) being a supply chain issue, I think the point would be better.
It's probably close to the best thing that can be done with the available data, even if the available data is bad - the main flaw of such a metric is that while you could argue that the total impact is proportional to the number of machines affected, you can't reasonably argue that the impact is proportional to the CVSS score, the relationship is very non-linear.
A vulnerability with CVSS 2.5 wouldn't have a quarter of impact of a CVSS 10 vulnerability, its impact would be insignificant.
The problem is that it really depends on your stack/application. A score pretends to be an absolute frame of reference to work on, and this is hardly reliable to assess real risk and impact.
A CVSS 10 on several internal services with all user input being filtered may be substantially less risky than a public facing component using a library with a CVSS 2.5 depending on your application and vulnerability.
The only correct way is to assess risk is analyze how you utilize each component and determine if your application would run into the issue to begin with. This work cannot be hand-waved away with a simple number despite this practice being the hot fad in cybersecurity.
While individual circumstances matter a lot for impact to a single organization, for estimating the global "blast impact" of a vulnerability, we'd expect that all of that would somewhat average out between all the thousands or millions of different systems and organizations running that tool, and a library with 100 times more users can be expected (all things being equal) to have 100-ish times more situations where it's used in a publicly reachable way - but the difference in average expected impact of having a million systems with a 2.5 CVSS vulnerability (likely causing zero incidents) and a million systems with a 10.0 CVSS vulnerability (likely wormable RCE) isn't 4 times, not even close to that.
> I'm wondering if perhaps the Linux ecosystem is actually a bunch of aging infrastructure. If so, that fact might be obscured by seemingly healthy contributions to the Linux kernel. There's a ton of other "basic infrastructure" that gets shipped alongside the kernel, though: coreutils, binutils, gcc, make, autotools, cmake, zlib, xz, etc etc etc. -- Camdon Cady
> Our team at Socket catches 100+ software supply chain attacks in npm, PyPI, and Go every week.
> Software engineer Andrew Nesbitt has been playing around with the concept of a "blast radius" for open source security advisories on Ecosyste.ms. He uses the CVSS score of a security advisory multiplied by the number of repositories that depend upon that package to determine the “blast radius.”