Common Vulnerabilities and Exposures (CVE)

Common Vulnerabilities and Exposures (CVE) is a list of publicly known vulnerabilities and security weaknesses.

The CVE mission is to identify, define and catalog publicly disclosed cybersecurity vulnerabilities. The list was created to unify the vulnerability IDs and to register detected security weaknesses. CVE allows cybersecurity professionals, vulnerability detection tools and vulnerability databases to receive and share information about specific weaknesses. This enables to ensure that the same issue is considered.

CVE is created and supported by MITRE. The MITRE Corporation is an American not-for-profit organization that specializes in systems engineering. The organization supports projects in various fields such as space security, health informatics, cybersecurity and others. MITRE also supports the CWE (Common Weakness Enumeration) classification system of security flaws.

CVE is not meant to be a vulnerability database — it is rather just a list of them, a "dictionary" that allows you to compare data from various sources. CVE is a list of records. Each of them describes one common vulnerability. Each vulnerability record includes the following descriptive data: CVE ID, Reference, and Description. The CVE ID includes the CVE-prefix, the year in which the vulnerability was reported, and the number provided by CNA (CVE Numbering Authorities).

CNAs are software vendors, Bug Bounty service providers, and other organizations that search for vulnerabilities — they are authorized to add new records to CVE.

A vulnerability listed in CVE is usually described as follows: an <issue> in the <product> <version> is causing the <impact> as a result of the <attack>.

Each record provides at least one reference to vulnerability reports, vendor recommendations, or other information resources.

For a vulnerability to be included in CVE, it must meet the following criteria:

• The vulnerability must be fixed;
• The developer in whose product the vulnerability is found must accept a negative security consequence;
• The vulnerability affects only one codebase. In cases of open-source libraries, protocols or standards, each product with this vulnerability gets a separate CVE. The exception is if there's no way to use the shared code without being vulnerable.

The lifecycle of new CVE Record consists of the following steps:

• A person or organization discovers a new vulnerability.
• The discoverer reports a vulnerability to CNA Program participants. To request a CVE ID for the found vulnerability, they need to fill in the form.
• The CVE Program participant requests a CVE ID for the vulnerability.
• The CVE ID is now reserved. This means that CVE stakeholders are using the CVE ID for early-stage vulnerability coordination and management, but the CNA is not yet ready to publicly disclose the vulnerability.
• The CVE Program participant submits the details about the vulnerability. Details include affected product version, vulnerability type and impact, and at least one public reference to vulnerability reports.
• Once the minimum required data elements are included in the CVE Record, it is published to the CVE List by the responsible CNA.

The CVE record can be marked as RESERVED, DISPUTED, REJECT. The RESERVED mark is set for a record whose ID is reserved by a CNA or security discoverer, but the details of which have not yet been disclosed. When researchers disagree with each other on whether a particular problem is a vulnerability or not, the CVE record is marked as DISPUTED. In such cases, the CVE program does not determine which part is right, but draws attention to this dispute and tries to provide any references to inform about the problem better. A record marked as REJECT hasn't been accepted as a CVE record. Most often, the reason why the record was rejected is given in the description.

CVE records are short and do not contain technical details or vulnerability risk assessments. Therefore, CVE data is used to build vulnerability databases that expand and complement it. There is NVD (National Vulnerability Database) that supplements CVE data. In addition to the data available from CVE, NVD provides CVSS (Common Vulnerability Scoring System) scores, weaknesses listed in CWE, and vulnerable platforms listed in CPE (Common Platform Enumeration).

You can find a CVE record by keywords on their official website. The NVD database provides an enhanced search for vulnerability records, for example, by OS, vendor name, product name or version, vulnerability type, severity and impact.

In addition to NVD, CVE is also used in other vulnerability databases, for example, Vulners and VulDB.

Vulners is an aggregator and search engine that helps working with security data. It allows you to search for news and articles about vulnerabilities, patches, exploits, and much more.

VulDB is a vulnerability database that provides information about vulnerability management and incident response. It also provides analytics on information security trends. This helps information security specialists predict future threats and prepare for them.

CVE is free to use in third-party databases, security guidelines, and other products. It can be used to search and analyze vulnerabilities. Developers can also distribute it for free without altering the original records. A copy of the CVE list is available on the downloads page.

0

0

0

0

SHARE

We can email you a selection of our best articles once a month