CVE (Common Vulnerabilities and Exposures) — What is it and how to understand it
What is the Common Vulnerabilities and Exposures glossary (CVE)?
The Common Vulnerabilities and Exposures glossary (CVE) is a security project focused on publicly released software, funded by the US Division of Homeland Security and maintained by the MITRE Corporation. The CVE glossary uses Security Content Automation Protocol (SCAP) to collect information about security vulnerabilities and exposures, cataloging them according to various identifiers and providing them with unique IDs.
Once documented, MITRE provides each vulnerability with a unique ID. Several days after publication in the Mitre vulnerability database, the National Vulnerability Database (NVD) publishes the CVE with a corresponding security analysis.
The CVE list is defined by MITRE as a glossary or dictionary of publicly available cybersecurity vulnerabilities and exposures, rather than a database, and as such is intended to serve as an industry baseline for communicating and dialoguing around a given vulnerability. According the MITRE’s vision, CVE documentation is the industry standard by which disparate security advisories, bug trackers and databases can obtain a uniform baseline with which to “speak” to each other, communicating and deliberating about the same vulnerability in a “common language”.
CVE Identifiers
Every new CVE entry receives a unique ID following this formula:
CVE numbers are given to each new CVE issue by MITRE. However, it is worthwhile noting that MITRE is not the only one. CVEs may receive their numeric ID from commercial numbering authorities (non-governmental) who will number vulnerabilities and exposures found in their own products. As of December 2018, 93 commercial entities are authorized to act as CVE Numbering Authorities (CNA), including Adobe, Apple, Cisco, Linux, Google, HP, IBM, Microsoft, Mozilla, Oracle, and Red Hat. The third and final numbering authority is the emergency response team known as CERT Coordination Center which is also certified to assign CVE numbers.
Beyond their unique ID, each CVE receives an entry date indicating when it was created by MITRE, followed by an individual description field and a reference field. If the vulnerability was not directly reported by MITRE but rather was first assigned by a different bug tracker or advisory board, the reference field will include URL links to the bug tracker or advisory board which first submitted the vulnerability. Other links that may appear in this field are to the product pages affected by the CVE.
Reporting a CVE
Reporting a CVE requires contacting any one of the CVE Numbering Authorities (CNA), mostly likely MITRE which is the primary contributor to its own vulnerability database.
According to some developers forums, it is possible to post a vulnerability alert on a mailing list such as Bugtraq instead of contacting a CNA with a request for a CVE. MITRE will respond within a few days with a published CVE.
It is important to remember that though providing a vital service to the software community, new CVE entries may take time to appear in the MITRE database (anywhere from days to months). Bans and embragos related to commercial censorships must receive clearance prior to publicizing new CVEs and may cause delays from the time a CVE is given its ID to the time it is made public. Lack of resources at MITRE to write up new CVEs has also been known to cause setbacks in publishing. MITRE explains their handling delays as resulting from a constantly growing influx of vulnerabilities reported to the organization.
CVE Severity Analysis
Each CVE receives a CVSS score from the NVD, indicating its security severity. The NVD’s security severity ranking helps responders including developers, DevSecOps and security teams determine how to approach the vulnerability and when. Remediation resources are allocated based on severity prioritization.
The CVSS score follows a formula made up of several security metrics. The metrics involved in determining the severity of a vulnerability include its access vector, the attack complexity, the confidentiality of data processed by the system containing the vulnerability, the integrity of the exploited system, to name a few.
CVE-less Vulnerabilities
Some vulnerabilities don’t make it into the MITRE database, therefore never receiving a CVE number. This will happen if the discovering entity didn’t contact MITRE or any other CNA to request a CVE identifier, or if a CNA such as MITRE decided not to include the vulnerability in the system.
According to Mend’s 2018 Annual Report on the State of Open Source Vulnerabilities Management, only 86% of all reported open source vulnerabilities make it into MITRE’s CVE list. This means that another 14% of vulnerabilities are reported elsewhere outside of MITRE’s vulnerability glossary.
According to recent research we did on the top programming languages, we found that nearly 30% of JavaScript open source vulnerabilities are not reported to the CVE database. Similarly, CVE-less vulnerabilities make up just over 20% of the total vulnerabilities reported in Ruby.
Mend’s monthly review of the top 5 monthly open source vulnerabilities features at two vulnerabilities on average without a CVE designation every month, which was reported on independent advisories or bug trackers. This represents 40% of the total top open source vulnerabilities listed each month.
Unreported vulnerabilities remain hidden away in security advisory boards or issues trackers, where their discovering entity first published them. These vulnerabilities are “off the radar” for many developers who usually scout the main vulnerability databases and therefore are less likely to become known and properly patched even if patches or new version are available .
MITRE Glossary Vs. NVD Database
If the MITRE Corporation’s CVE dictionary consists of a list of entries, each documenting a unique publicly available vulnerability and attributed an ID number, then the National Vulnerability Database (NVD) is an elaborate vulnerability database offering security analysis of vulnerabilities.
While the NVD and MITRE’s CVE list are two separate entities, they are fully in synch so that any update, change and new entry made to the MITRE list will immediately show up on the NVD database.
The CVE list will offer a leaner entry of the vulnerability and will assign it an ID. The NVD will then build on this information, and offer broader information about the vulnerability, including fix information, search options, and impact ratings.
Both the CVE glossary and the NVD operate under the office of Cybersecurity and Communications at the U.S. Department of Homeland Security, and both are publically available and free.
CVE Vulnerabilities Still Maintain a Stronghold on the Industry
Security flaws are a wide and varied mix, reported in various databases, advisory boards and bug trackers and consisting of a diverse set of features and qualities. Yet of this assorted mix, CVE vulnerabilities remain the most popular vulnerability type and MITRE remains the foremost list for the documentation of security vulnerabilities in publicly released software.
See Our Additional Guides on Key Cybersecurity Topics
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of Cybersecurity
Docker Security
Learn about Docker Security, the practice of securing Docker containers, applications running within them, and host computers from attacks.
- Docker Container Security: Challenges and Best Practices
- What Are Docker Containers, and Should Your Company Adopt It?
- Docker Image Security Sca
IoT Security
Learn about IoT security, the practice of securing internet of things (IoT) devices and related infrastructure from cyber attacks.
- A Guide to Ransomware, Open Source and IoT
- IoT Application Security
- IoT Attacks – Rise of the Machines
Serverless Security
Learn about serverless security, the practice of securing serverless runtimes such as AWS Lambda and serverless functions from attacks.
- 6 Reason Serverless Computing Can Take the Cloud to the Next Level
- Shift Left Testing and Its Benefits
Cyber Attacks
Understand recent cyber attacks that caused catastrophic damage to organizations, and the lessons learned from them.
- The Equifax Breach: Who’s to Blame?
- Using Java? This is The Next Heartbleed You Should Be Worried About
- The Equifax Hack: 6 Months Later, What Did We Learn?
OWASP Top 10
Learn about the Open Web Application Security Project (OWASP) Top 10 cyber threats facing web applications.
- What OWASP Got Wrong on the 2017 Top 10 Application Security Risks List
- OWASP Dependency Check: How Does It Work?
API Security
Learn about API security, the practice of securing application programming interfaces (APIs) and the sensitive data they enable access to.
- Application Lifecycle Management – 5 Common Pitfalls to Avoid
- 12 API Security Best Practices You Must Know
- GraphQL Testing: Components to Test and 5 Security Testing Tips
Software Supply Chain
Learn about the software supply chain and the critical risk of security breaches involving third party vendors and suppliers.
- Using Zero Trust to Mitigate Supply Chain Risks
- Software Supply Chain Attacks
- Supply Chain Security – 10 Tips That Won’t Slow Development Down
