Getting Infinite CVEs via Software Supply Chain Security

TL;DR: Open-source projects commonly use known vulnerable software dependencies. Because the CVE review process doesn’t know how to handle supply chain vulnerabilities, these are often reviewed and approved as legitimate CVEs.

Common Vulnerabilities and Exposures

CVEs are publicly disclosed security flaws in software. They’re reviewed and assigned a unique identifier by a CVE Numbering Authority (CNA), like CVE-2023-1234, allowing for standardized tracking and discussion across various security platforms and tools.

CVEs originated in 1999 by MITRE, a not-for-profit organization managing federally funded research. The system was designed to standardize the way vulnerabilities are identified and discussed. By providing a unique identifier to each vulnerability, CVEs help professionals communicate about specific issues efficiently, facilitating data sharing across separate databases and tools.

The Problem

CVEs were not originally designed to address supply chain security vulnerabilities. In 2023, roughly 30,000 CVEs were reviewed and published; however, if we look at open-source projects dependent on these known vulnerable packages, the number quickly surpasses tens of millions.

An example is the vm2 sandbox package, which still receives over 3M weekly downloads even though it has been deprecated for over six months with known critical vulnerabilities impacting all versions.

It’s great that a CVE was assigned for the vm2 package, but what about all the project’s dependents? Well, that’s precisely the problem in supply chain security right now that people like OpenSSF’s Vulnerability Disclosure WG are trying to solve. Currently, the only real solution is for project maintainers to incorporate a supply chain security solution, which will produce mostly noise unless you use something like Semgrep’s reachability analysis 😉.

Taking Advantage of the Problem for CVE Glory

You might be thinking, “Surely not all projects using this vulnerable vm2 package should receive their own CVE”, and depending on who you ask - you may or may not be correct. That said, evidence proves time and time again that using a vulnerable dependency often results in a new CVE. But really, what’s the better solution? I have a few ideas, but I’ll save them for another time.

Here are two quick examples I pulled of CVEs reviewed and approved by a CVE Numbering Authority (CNA), where the vulnerability is simply using a known-bad version of vm2.

• https://github.com/advisories/GHSA-g7rj-q722-245g

• https://github.com/advisories/GHSA-wg6p-jmpc-xjmr

The CNA onboarding docs and relevant procedures are publicly available for those interested. You’ll find that based on procedure, these should be approved as valid CVEs.

So, it’s that easy… If you want a CVE, check the list of over 200,000 dependents for the vm2 project, review how the project uses it, and if it introduces risk, go ahead and submit for a CVE. This would be a nightmare for CNAs, especially if the submissions were largely or entirely automated. 

Extra Credit

Funny enough, there is an entry for this in the Common Weakness Enumeration (CWE) list, which is intended to categorize vulnerabilities.

CWE-1395: Dependency on Vulnerable Third-Party Component

However, according to NVD’s CVE API, there is not a single CVE assigned CWE-1395.

https://services.nvd.nist.gov/rest/json/cves/2.0?cweId=CWE-1395