The open source community has proven more resilient than proprietary software owners in overcoming a recent crisis within the US National Vulnerability Database (NVD), the world’s most comprehensive vulnerability database.
Following unknown challenges starting in mid-February 2024, the US National Institute of Standards and Technology (NIST), which runs the NVD, has only analyzed only 4635 of the 17,227 common vulnerabilities and exposures (CVEs) received so far this year.
Brian Fox is co-founder and CTO of Sonatype, a software supply chain management firm exhibiting at Infosecurity Europe from June 4 to 6.
He recently spoke to Infosecurity about how the open source community has been less impacted by the NVD vulnerability backlog than commercial software developers.
He also explained why he thinks the NVD program is no longer relevant and how open source security has helped model the federated vulnerability disclosure system recently introduced by the US National Cybersecurity Federally Funded Research and Development Center (NCF).
Infosecurity Magazine: To what extent did the NVD crisis impact open source software security?
Brian Fox: The issue with the NVD vulnerability backlog is that any tools solely dependent upon the NVD feed became blind.
Nevertheless, I think that in many cases, open source projects might have been less dependent on the database, and thus more agile and able to adapt than commercial tools. For instance, many open source developers have been able to swiftly switch to one of the other feeds, such as what the CVE Numbering Authorities (CNAs) publish through the CVE program [a vulnerability program maintained by the US National Cybersecurity FFRDC (NCF), itself operated by non-profit MITRE Corporation], or on GitHub, which runs its own vulnerability management program.
On the other hand, a company running a commercial tool must change priorities, assign vulnerability detection work and require all its customers to update. All of this can take time. Therefore, I feel like there's a case to be made that open source might be able to adapt to this change faster than commercial tools.
IM: Do you think commercial software products are too reliant on the NVD for vulnerability management?
BF: Yes, I think too many tools depend upon the NVD feed for vulnerability-enriched data. And once they stopped doing it, all those tools effectively became blind to new vulnerabilities.
Read more: NVD Leaves Exploited Vulnerabilities Unchecked
Of course, the number of vulnerabilities being disclosed and the number of pieces of software out there in the world both go up year after year. This means that, as a software developer, you really have this massive scale and breadth problem.
To counter that, the CVE program, run by MITRE and sponsored by the US Cybersecurity and Infrastructure Security Agency (CISA), has been working towards a federated model by introducing CNAs and allowing different organizations to assign numbers directly. This replaced a system in which you had to request a number and do the reporting yourself. I think this federated model has been quite effective at allowing the overall program to scale.
However, the NVD doesn't seem to have taken the same approach. They are still employing contract researchers to effectively research a massively growing space. These people add enriched data themselves, such as the common platform enumerator (CPE) and the severity score (CVSS) and make it available in a singular feed. This system has never been quite adapted to open source security and has now reached its limits.
IM: Why do you think the NVD is not well adapted to open source security?
BF: Essentially, the CPE system isn’t well suited for open source components.
By using a CPE to identify a vulnerability, you can add just a few common fields, such as the project, the producer and the version. This is great if you're considering a commercial product like Microsoft Word, version 2010.
However, that doesn't work for a component like Apache Struts or Spring, where there are 80 to 100 individual components. Assigning a CPE number to a vulnerability within such a complex open source project means you won’t know where exactly the vulnerability lies – which could lead to a massive amount of false positives. It’s not precise enough.
"The NVD program should return to focusing on the list of known vulnerabilities in software that the government is using."Brian Fox, co-founder and CTO, Sonatype
Thankfully, in the latest CVE version recently released, the CVE program introduced a new JSON version allowing the assignment of package URLs (pURLs), which I've been a champion of since the beginning.
IM: In your view, why is the package URL format better than the CPE format for vulnerability management?
BF: It’s much better, especially for open source projects. Because it is much more flexible.
A pURL recognizes that every package has an inherent coordinate system—the coordinate system for Maven is different from the coordinate system for NPM, for instance. The pURL format allows you to define those different coordinates within the same identification number.
One of the criticisms of pURL is that it's hard to assign pURL numbers to proprietary products that do not exist in an open source package repository. However, since pURL is extensible, I’m sure you could add a given proprietary software’s CPE number within a pURL.
Where the CPE fails to have the level of fidelity and precision for open source, the pURL format is exactly designed to solve that problem. So now, CNAs are allowed to assign a CVSS score and a pURL number themselves. When that starts to happen, the NVD essentially becomes irrelevant.
IM: Recently, Tanya Brewer, the NVD program manager, announced that the program could soon accept pURL. Do you think this is useful?
BF: The NVD program might continue to exist; I'm not saying it has no value.
However, if the work of assigning enriched data is done at the CVE and CNA level, which is a federated system, the enrichment work done by the NVD becomes irrelevant.
Instead of trying to be the single source for the entire world, I believe the NVD program should return to focusing on the list of known vulnerabilities in software that the government is using.
People recognize that for the last four months, the NVD hasn't been doing what they need it to do, and has communicated very poorly about the issues it was facing. So, I think that, by now, any of the tools or companies dependent on it probably have found an alternative.
NIST published an update on May 29, announcing it has awarded a contract for additional processing support to include incoming CVEs in the NVD. The Institute also said it is working with CISA to facilitate the addition of unprocessed CVEs to the NVD. "We anticipate that [the] backlog will be cleared by the end of the fiscal year," it added.