Common Vulnerabilities and Exposures (CVE)

The CVE List is a set of records, each one of which describes a specific vulnerability or exposure. The CVE List is maintained by a large community of trusted entities and individuals that are qualified to identify and describe coding flaws or security misconfigurations that could be exploited by bad actors to compromise a system or data. The key contributors to the CVE List include vendors, researchers, developers and even end-users.

As defined by CVE, a vulnerability is a “...flaw in a software, firmware, hardware, or service component resulting from a weakness that can be exploited, causing a negative impact to the confidentiality, integrity, or availability of an impacted component or components.”

A vulnerability, therefore, provides an attacker with direct unauthorized access to a system or network, often with full privileges to execute commands or access restricted information. An exposure is a code or configuration error through which an attacker can gain indirect and often hard-to-discover access to application data such as customer information.

In this lesson, we describe how the Common Vulnerabilities and Exposures (CVE) program brings standardization and information sharing to the vulnerability management activities of cybersecurity teams.

Each CVE Record is associated with a unique alphanumeric ID and references a single specific vulnerability. The CVE Record includes a brief description of the vulnerability or exposure and at least one public reference. Authorized Data Publishers (ADPs) can then enrich a CVE Record with additional information such as risk scores or lists of affected products. CVE Records are added by CVE Numbering Authorities (CNAs)—organizations that are permitted to assign CVE IDs to vulnerabilities.

The primary CNA is MITRE but there are currently 149 CNAs in 25 countries, all acting within a kind of federated system.

Each CNA has a defined scope of responsibility for identifying and publishing vulnerabilities, often related to their own products. A CNA is issued a block of CVE IDs to attach to new issues as they arise. The list of CNAs includes the likes of Adobe Systems, Advanced Micro Devices (AMD), McAfee, Check Point, Red Hat, Microsoft, and Google, to name but a few. Root CNAs have the authority to recruit, train, and govern other CNAs or ADPs.

In order to be added to the CVE List, a vulnerability or exposure has to be:

• Independently fixable by the end-user.
• Verified, either by the affected vendor or through other documentation, as negatively impacting security.
• Relevant to a single affected codebase or product. A vulnerability that affects more than one product gets separate CVEs.

In addition to their own monitoring activities, there are a number of channels through which CNAs become aware of potential CVEs, including end users, cybersecurity companies, and bug bounty programs. It should be noted that not all CVEs are published immediately to the public CVE List. Sometimes the affected vendor reserves a CVE Record until a fix is ready.

The Common Vulnerability Scoring System (CVSS) is a published standard that uses the CVE List and other sources to produce a numerical score that reflects a vulnerability’s severity. CVSS is used by organizations and services around the globe to prioritize vulnerabilities and assess their vulnerability management processes. CVSS is an excellent example of how the standardized, publicly available CVE List is leveraged by another service to add value to vulnerability management programs.

To promote its integration with other products and services, the CVE List is available in a number of human- and machine-readable formats.

The CVE List plays a vital role in the cybersecurity world as an essential resource around which security products and services can share standardized information. However, the CVE List alone is insufficient for building an effective vulnerability remediation program. Other information sources as well as advanced analytic capabilities are required in order to achieve the risk assessment and actionable remediation guidelines that are the hallmarks of a cutting-edge vulnerability remediation solution.

A good example is the industry-leading Snyk Vulnerability Database, which goes far beyond the CVE List to deliver advanced and accurate insights into open-source vulnerabilities. The Snyk Intel Vulnerability Database is based on a rich ecosystem of sources including:

• Enriched and analyzed data from several vulnerability databases, including CVE (where Snyk is CNA).
• A dedicated in-house security team that curates other severe vulnerabilities through ongoing independent research efforts.
• Tight integration with a wide range of threat intelligence systems, carefully listening to chatter on security bulletins, Github commits, and Jira boards to identify vulnerabilities that have not yet been reported.
• Community members and bug bounties.
• Academic labs with which Snyk exclusively exchanges tools, methods, and data.

The result is remarkably comprehensive security coverage, including many non-CVE vulnerabilities as well as the exposure of many vulnerabilities before they appear in any public database. Snyk’s benchmarks demonstrate that vulnerabilities are identified 25 days faster in the Snyk database compared with the next largest commercial database.

• Find CVEs by using the Snyk Vulnerability Database
• Read our blog post, Security in context: When is a CVE not a CVE?