Counting CVEs Was Never Enough

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: 

• Get updates directly from the National Vulnerability Database
• Join CNCF's Cloud Native Live on June 11 for “GUAC 101: Dip into the Delicious World of Software Supply Chain Security”
• Obtain training and learn more about security from the Open Source Security Foundation (OpenSSF)