Common Vulnerabilities and Exposures (CVE)
Common Vulnerabilities and Exposures (CVE®) is a list of records—each containing an identification number, a description, and at least one public reference—for publicly known cybersecurity vulnerabilities. CVE Records are used in numerous cybersecurity products and services from around the world, including the U.S. National Vulnerability Database (NVD).
CVE stands for Common Vulnerabilities and Exposures. It is a program launched in 1999 by MITRE, a nonprofit that operates research and development centers sponsored by the federal government, to identify and catalog vulnerabilities in software or firmware into a free “dictionary” for organizations to improve their security.The dictionary’s main purpose is to standardize the way each known vulnerability or exposure is identified. Standard IDs allow security administrators to access technical information about a specific threat across multiple CVE-compatible information sources.
CVE entries are brief. They don’t include technical data, or information about risks, impacts, and fixes. Those details appear in other databases, including the U.S. National Vulnerability Database (NVD), the CERT/CC Vulnerability Notes Database, and various lists maintained by vendors and other organizations. Across these different systems, CVE IDs give users a reliable way to tell one unique security flaw from another.
The Goal of CVE
The goal of CVE is to make it easier to share information about known vulnerabilities across organizations.
CVE does this by creating a standardized identifier for a given vulnerability or exposure. CVE identifiers or CVE names allow security professionals to access information about specific cyber threats across multiple information sources using the same common name.
For example, UpGuard is a CVE compatible product and its reports reference CVE IDs. This allows you to find fix information on any CVE compatible vulnerability database.
MITRE Corporation's documentation defines CVE Identifiers (also called "CVE names", "CVE numbers", "CVE-IDs", and "CVEs") as unique, common identifiers for publicly known information-security vulnerabilities in publicly released software packages. Historically, CVE identifiers had a status of "candidate" ("CAN-") and could then be promoted to entries ("CVE-"), however this practice was ended some time ago and all identifiers are now assigned as CVEs. The assignment of a CVE number is not a guarantee that it will become an official CVE entry (e.g. a CVE may be improperly assigned to an issue which is not a security vulnerability, or which duplicates an existing entry).
CVEs are assigned by a CVE Numbering Authority (CNA) there are three primary types of CVE number assignments:
- The Mitre Corporation functions as Editor and Primary CNA
- Various CNAs assign CVE numbers for their own products (e.g. Microsoft, Oracle, HP, Red Hat, etc.)
- A third-party coordinator such as CERT Coordination Center may assign CVE numbers for products not covered by other CNAs
When investigating a vulnerability or potential vulnerability it helps to acquire a CVE number early on. CVE numbers may not appear in the MITRE or NVD CVE databases for some time (days, weeks, months or potentially years) due to issues that are embargoed (the CVE number has been assigned but the issue has not been made public), or in cases where the entry is not researched and written up by MITRE due to resource issues. The benefit of early CVE candidacy is that all future correspondence can refer to the CVE number. Information on getting CVE identifiers for issues with open source projects is available from Red Hat.
CVEs are for software that has been publicly released; this can include betas and other pre-release versions if they are widely used. Commercial software is included in the "publicly released" category, however custom-built software that is not distributed would generally not be given a CVE. Additionally services (e.g. a Web-based email provider) are not assigned CVEs for vulnerabilities found in the service (e.g. an XSS vulnerability) unless the issue exists in an underlying software product that is publicly distributed.