Counting CVEs Was Never Enough

CVE IDs don't tell you much, but somehow we started using them as a proxy for security

Ben Cotton

June 6, 2024

Since the Common Vulnerabilities and Exposures (CVE) program was launched in 1999, it has given the software industry a way to give vulnerabilities a unique identifier. While the ID by itself doesn’t tell you much, when you say “CVE-2021-44228”, everyone can be sure they’re talking about the same vulnerability. But somewhere along the way, we started using the CVE count as a proxy for security.

Of course, the premise that “software A is more secure because it has fewer CVEs than software B” doesn’t make sense. At best, it just tells us that software A has fewer vulnerabilities that we know about. But not all vulnerabilities are created equal. A remote code execution vulnerability is a lot worse than a vulnerability that requires local access. A vulnerability that can’t be exploited because it’s conditional on an unused configuration option only matters in the academic sense. But the human mind loves to simplify, and we fell into the “CVE count is proportional to security” trap.

A change by the Linux kernel maintainers has made the idea of using CVE count as a security proxy even worse. After becoming a CVE numbering authority — thus being able to self-assign CVE identifiers — in February, the Linux kernel project adopted a policy of issuing a CVE for every bug fix. They reason that “almost any bug might be exploitable to compromise the security of the kernel,” so it’s better to err on the side of caution. Others have called this malicious compliance or an attempt to force fixes to a broken system. Whatever your opinion, this will dramatically increase the count of CVEs in the Linux kernel, and all of the servers, container images, and so on that use it. If you don’t immediately update to the latest kernel (and most people don’t, particularly in production environments), then you have a lot of unfixed CVEs in your software stack.

So what’s a security-conscious developer to do?

Supply chain security starts with supply chain observability — the ability to ingest, analyze, and query the attributes and relationships through the entirety of the supply chain. You don’t only need to know what vulnerabilities might exist. You need to know how severe they are (CVSS scores), whether or not you’re affected (VEX statements), and where the vulnerable packages exist in your supply chain (SBOMs). And you can be proactive, too, by knowing which components have a better security posture (e.g. with OpenSSF Scorecard).

GUAC is a powerful tool for aggregating different sources of information and providing an easy way to query and visualize the state of your software supply chain. This lets you move from mere counting to true supply chain observability.

Additional Resources: 

Like what you read? Share it with others.

Other blog posts 

The latest industry news, interviews, technologies, and resources.

View all posts


No older posts


No newer posts

Want to have a conversation about your software supply chain?

We’d love to hear from you.  Get in touch and we'll get back to you.

Say Hello
By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.