What is a CVE?

CVE, short for Common Vulnerabilities and Exposures, is a list of publicly disclosed computer security flaws. When someone refers to a CVE, they mean a security flaw that's been assigned a CVE ID number.

Security advisories issued by vendors and researchers almost always mention at least one CVE ID. CVEs help IT professionals coordinate their efforts to prioritize and address these vulnerabilities to make computer systems more secure.

Don't feel like reading? Here's a short video on CVE, instead.

The CVE program is overseen by the MITRE corporation with funding from the Cybersecurity and Infrastructure Security Agency (CISA), part of the U.S. Department of Homeland Security.

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 recognize unique vulnerabilities and coordinate the development of security tools and solutions. The MITRE corporation maintains the CVE List, but a security flaw that becomes a CVE entry is often submitted by organizations and members of the open source community.

About CVE identifiers

CVE identifiers are assigned by a CVE Numbering Authority (CNA). There are about 100 CNAs, representing major IT vendors—such as Red Hat, IBM, Cisco, Oracle, and Microsoft—as well as security companies and research organizations. MITRE can also issue CVEs directly.

CNAs are issued blocks of CVEs, which are held in reserve to attach to new issues as they are discovered. Thousands of CVE IDs are issued every year. A single complex product, such as an operating system, can accumulate hundreds of CVEs.

CVE reports can come from anywhere. A vendor, a researcher, or just an astute user can discover a flaw and bring it to someone’s attention. Many vendors offer bug bounties to encourage responsible disclosure of security issues. If you find a vulnerability in open source software you should submit it to the community.

One way or another, information about the flaw makes its way to a CNA. The CNA assigns the information a CVE ID, and writes a brief description and includes references. Then the new CVE is posted on the CVE website.

Often, a CVE ID is assigned before a security advisory is made public. It’s common for vendors to keep security flaws secret until a fix has been developed and tested. That reduces opportunities for attackers to exploit unpatched flaws.

Once made public, a CVE entry includes the CVE ID (in the format "CVE-2019-1234567"), a brief description of the security vulnerability or exposure, and references, which can include links to vulnerability reports and advisories.

CVE IDs are assigned to flaws that meet a specific set of criteria. They must be:

1. Independently fixable.

The flaw can be fixed independently of any other bugs.

There are multiple ways to evaluate the severity of a vulnerability. One is the Common Vulnerability Scoring System (CVSS), a set of open standards for assigning a number to a vulnerability to assess its severity. CVSS scores are used by the NVD, CERT and others to assess the impact of vulnerabilities. Scores range from 0.0 to 10.0, with higher numbers representing a higher degree of severity of the vulnerability. Many security vendors have created their own scoring systems, as well.

Three key takeaways 

Know your deployments. Just because a CVE exists doesn’t mean the risk applies to your specific environment and deployment. Be sure to read each CVE and understand if it applies to your environment by validating that it applies (or partially applies) to the operating system, application, modules, and configurations of your unique environment.

Practice vulnerability management. Vulnerability management is a repeatable process to identify, classify, prioritize, remediate, and mitigate vulnerabilities. This means understanding how a risk would apply to your organization so you can properly prioritize any outstanding vulnerabilities that need to be addressed.

Be ready to communicate. CVEs will impact your organization’s systems, both because of the vulnerabilities themselves and any potential downtime required to address them. Communicate and coordinate with your internal customers and share the vulnerabilities with any central risk management function within your organization.

How Red Hat works with CVEs

As a major contributor to open source software, Red Hat is continuously engaged in the security community. Red Hat is a CVE Numbering Authority (CNA) and uses CVE IDs to track security vulnerabilities. Red Hat Security maintains an open and frequently updated database of security updates, which you can view by CVE number.

Red Hat Product Security provides access to raw security data on its Security Data page and in a machine-consumable format with the Security Data API.

In addition to the security reports and metrics which Red Hat produces, customers can use this raw data to produce their own metrics for their own unique situations.

The data provided by the Security Data API includes OVAL (Open Vulnerability and Assessment Language) definitions, Common Vulnerability Reporting Framework (CVRF) documents, and CVE data. Data is available in XML or JSON format.