Debunking these 5 CVE myths will improve software security

GitHub

By Madison Oliver

Anyone who works in the software industry knows there can be a stigma attached to CVEs. 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. However, every CVE doesn’t need to cause that level of anxiety. CVEs are simply unique identifiers or tracking numbers assigned to a specific vulnerability. So why are so many vendors and open source maintainers hesitant to request CVEs, even if the vulnerability is minor?

A series of myths have emerged around CVEs, thereby increasing the odds that vulnerabilities will go undetected and unpatched. Debunking these misconceptions is critical, as reporting CVEs is essential to ensuring the kind of transparency that makes software more trustworthy and secure. Here are five key misconceptions about CVEs:

1. A CVE is always a very serious problem. Not always true. 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 maintainer. 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 enough technical details so that users can make their own decisions about the vulnerability. If maintainers think the vulnerability is minor, they can explain that in the severity scoring and the advisory.
4. A CVE is a trophy to collect for the security researcher who found the bug. CVEs are all about transparency and giving users the opportunity to make informed decisions. 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 incorrect.
5. Obtaining a CVE is a painful, long process. It’s not uncommon for CVE numbering authorities (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.

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 from a CNA, like GitHub. GitHub acts as a CNA for any open source project 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 impact of the security vulnerability.

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.

Madison Oliver is a senior security analyst at GitHub. She previously served as an adjunct professor at Duquesne University, and was a member of the technical staff of the CERT Division at the Software Engineering Institute. She has a Master’s degree in information security policy and management from Carnegie Mellon University, and a B.S. in security and risk analysis from Pennsylvania State University.