5 Myths about CVEs

Anyone who works in the software industry knows that stigma can be attached to CVEs, or “common vulnerabilities and exposures” assignments. This is driven by misconceptions that can make vendors and open source maintainers reluctant to request a CVE, which reduces transparency and ultimately puts software security at risk.

Reluctance is understandable, as mere mention of the term CVE can inspire fear, uncertainty and doubt. Will this give my project a bad reputation? Is the issue bad enough to justify the effort of getting an assignment? How should I work with the security researcher who submitted the vulnerability?

However, every CVE doesn’t need to cause that level of anxiety. After all, they’re nothing more than unique identifiers or tracking numbers assigned to a specific vulnerability. So why are vendors and open source maintainers hesitant to request CVEs, even if the vulnerability is minor?

Over the years, a series of myths have emerged about CVEs that give them a bad reputation, which spawns hesitation to report and increases the odds that vulnerabilities will go undetected and unpatched. Debunking these misconceptions is critical, as CVEs are essential to ensuring the kind of transparency that ultimately makes software more trustworthy and secure. Here is a brief analysis of the five main misconceptions about CVEs that can be detrimental to progress in software security if not addressed.

1. A CVE is always a very serious problem. That’s not always true because severity cannot be inferred from the existence of a CVE identifier. Responsible vendors and maintainers, as a matter of practice, request CVEs and publish advisories, even for minor vulnerabilities.
2. CVEs are bad for the reputation of the software and its vendor or maintainer. Quite the contrary. Being transparent about potential vulnerabilities shows that vendors and maintainers take security seriously and increases trust in their projects. Meanwhile, ignoring a potential problem could have dire reputational consequences.
3. Low severity vulnerabilities do not need a CVE. Untrue. Advisories should describe technical details so users can make their own decisions about the vulnerability. If vendors and maintainers think the vulnerability is minor, they can explain that in the severity scoring and the advisory itself.
4. A CVE is a trophy for the security researcher who found the bug to collect. CVEs are all about transparency and giving users the opportunity to make informed decisions; they are not low-quality trophies to be collected in mass quantity or “gotcha!” moments. A researcher seeking a CVE for their reported issue is part of a healthy security practice. Plus, CVEs can be contested if they’re deemed unfair or incorrect.
5. Obtaining a CVE is a painful months-long process. Not so. In fact, it’s not uncommon for CVE numbering authorities, or CNAs, to assign CVEs within a matter of days. Some provide editorial services that ensure requests comply with program rules, and even write summaries that can be shared with other CVE databases.

Clearly, the idea that a CVE will derail a project is incorrect, whereas staying silent about a vulnerability and hoping for the best could lead to reputational consequences. Maintainers can request CVEs through a CVE Numbering Authority (CNA). For example, GitHub acts as a CNA for any open source project on the platform that leverages GitHub Security Advisories (GHSA). Through a GHSA, maintainers can notify their project’s community of a vulnerability so users can update package dependencies and research the effect of the security vulnerability. (Disclosure: I am a GitHub employee.)

CVEs are important elements of building trust in a project and are the best way to ensure that vulnerability information is widely accessible and accurate, which allows users to make their own assessment of the risk based on facts. In overcoming these five misconceptions, vendors and maintainers can shift their focus to building and maintaining transparency and trust around their software projects.