The CVE & CVE Management, Explained

Any computer system with vulnerabilities can be exposed to cyberattacks, if that system is connected to the internet or any external network. (Today, that’s pretty much all computers.)

So, any strong security strategy starts with knowledge — knowing where weaknesses in your systems and apps are. That’s where the CVE can help.

The Common Vulnerabilities and Exposures (CVE) is a rich source of knowledge. Knowing the potential weaknesses of your systems means you can evaluate your security measures against them to meet a critical purpose: building a more robust defense mechanism. 

Dig deeper into this article and find out:

• What the CVE is
• How to create a CVE record
• Strategies for managing CVEs in your builds
• Plenty of useful information along the way

What are vulnerabilities & exposures?

Before defining the CVE, let’s first understand vulnerability and exposure. 

A vulnerability is any weakness in a computer system or app that can potentially be exploited to gain unauthorized access (typically by threat actors) A vulnerability can present on different levels, such as hardware, software, network, personal, organizational, etc. Vulnerabilities can be almost anything. Common examples include:

• Lack of authentication
• Input validation errors
• SQL injections

Exposure is any incident that allows attackers to gain advantages over your system's vulnerabilities in order to perform unauthorized activities. Exposure can cause adverse, often serious effects like sensitive data leaks, malware injection, ransomware attacks and many more. 

(Related reading: common vulnerability types &  how vulnerabilities lead to threats and risk.)

What is The CVE? Common Vulnerabilities & Exposures

Short for Common Vulnerabilities & Exposures, the CVE is a list of known, documented, frequently exploited vulnerabilities and exposures in software. The list is public and has become a go-to resource of security analysts around the world.

The objective of the CVE is to build awareness and share information about such security loopholes and the effects these loopholes might have. This helps organizations to:

• Evaluate their cybersecurity strategies and frameworks.
• Find the latest security breach trends.
• Update systems to fight against those security flaws. 

You can find the current list of CVEs at https://www.cve.org/, which is maintained by The MITRE Corporation. As of July 2024, there are 240,830 CVE Records. There is no monetary fee or contract associated with publishing a CVE record. (We’ll cover more of this shortly.)

Importantly, the CVE contains only publicly known exposures and vulnerabilities (here’s another acronym: KEVs). The details about the vulnerability are usually not disclosed there until a disclosed party introduces a fix.

The big caveat here is that the official CVE list does not include an assessment of the severity of each CVE. Other organizations that maintain their own lists of CVEs, most notably NIST’s National Vulnerability Database, assign severity categories (such as “medium,” “high” and “critical”) and/or numerical severity scores to CVEs.

Most frequently exploited CVEs

The CVE publishes its annual report of CVEs in April. The following are some top CVEs from 2023:

CVE-2018-13379, affecting Fortinet SSL VPNs. Routinely exploited in 2020 and 2021. The continued exploitation indicates that many organizations failed to patch software in a timely manner and remain vulnerable to malicious cyber actors.

ProxyShell, including CVE-2021-34473, CVE-2021-31207, CVE-2021-34523 affect Microsoft Exchange email servers. In combination, successful exploitation enables a remote actor to execute arbitrary code. These vulnerabilities reside within the Microsoft Client Access Service (CAS), which typically runs on port 443 in Microsoft Internet Information Services. CAS is commonly exposed to the internet to enable users to access their email via mobile devices and web browsers.

CVE-2021-40539 enables unauthenticated remote code execution (RCE) in Zoho ManageEngine ADSelfService Plus and was linked to the usage of an outdated third-party dependency. Initial exploitation of this vulnerability began in late 2021 and continued throughout 2022.

CVE-2021- 44228, known as Log4Shell, affects Apache’s Log4j library, an open-source logging framework incorporated into thousands of products worldwide. An actor can exploit this vulnerability by submitting a specially crafted request to a vulnerable system, causing the execution of arbitrary code. The request allows a cyber actor to take full control of a system. The actor can then steal information, launch ransomware, or conduct other malicious activity.[1] Malicious cyber actors began exploiting the vulnerability after it was publicly disclosed in December 2021, and continued to show high interest in CVE-2021- 44228 through the first half of 2022.

Recently, CVE-2024-6387 enabled RCE via OpenSSH 8.5p1 to 9.8p1, affecting Linux environments.

(Get more vulnerabilities and threat research from SURGe and the Splunk Threat Research Team.)

Brief history of the CVE

It all began in 1999 when U.S. non-profit The MITRE Corporation launched the CVE system as a reference system to identify and classify common vulnerabilities in exposures in computer systems worldwide. Today, the CVE is maintained by the National Cybersecurity FFRDC, operated by MITRE, and sponsored by the Cybersecurity Infrastructure Security Agency (CISA), housed within the Department of Homeland Security.

In a pre-CVE world, getting information on vulnerabilities and exposures was not easy. A variety of CVE databases with their attributes and own identification systems were siloed and owned by different folks. The CVE system breaks down this barrier, allows data sharing across other databases, and evaluates cyber security tools against a wide list of security flaws. 

How to create a CVE record

Have you IDed a new vulnerability? You can report it to the CVE program via CVE Program Partners. Then, you can request to assign a CVE ID for that vulnerability. This means the CVE record will initially bear the ‘Reserved’ status but not yet publicly disclosed. 

Each vulnerability must have one record in the CVE list. There are certain criteria to be satisfied to assign a CVE ID to a vulnerability:

• The vulnerability should have a negative impact on security.
• The vulnerability can be fixed independently.
• The vulnerability impacts only one product. (It will get a separate CVE ID if it affects more than one.)

Next, the CVE Program Partner provides details about the vulnerability, such as the type of the vulnerability, root cause, the products and version affected by it and finally, the fixed version, with at least one public reference to the vulnerability. 

When the minimum required information is submitted, a CVE record is created and published by the CNA so that anyone can see and download it. Thus, the CVE record now shows as ‘Published.’ If the CVE record cannot be used anymore, it will be placed in the list as ‘Rejected’ so that everyone knows it is invalid.

CVE includes only limited information about any vulnerability. For more details, you can refer to the NIST National Vulnerability Database (NVD), which is fully synchronized with the CVE. You can also read about how Splunk integrates with Known Exploited Vulnerabilities Catalog, from CISA.

Components of a CVE Record

The CVE record consists of the following fields:

• CVE-ID
• Description
• References
• Assigning CNA
• Record created date

Outdated/legacy fields that persist in old records include: 

• Phase
• Votes: Board members vote on whether the record can be accepted as a CVE
• Comments: Comments on the vulnerability
• Proposed: the proposed date of the vulnerability

Let’s take a look at some of these components in detail.

CVE ID

A CVE ID is a unique ID assigned to each vulnerability by one of the CVE Numbering Authorities (CNAs). A CVE ID has the following format:

CVE-Year-Number

In the past, the CVE ID initially had the ‘candidate’ or ‘CAN’ status — this practice was sunset in 2005. Today, all identifiers have the CVE as the prefix. A number is a sequential number, and the year shows the year it was reported. Following is an example of a CVE ID assigned by Microsoft Corporation in 2022 for Windows Terminal Remote Code Execution Vulnerability.

CVE-2022-44702: Windows Terminal Remote Code Execution Vulnerability

Some CVE IDs get nicknames with exposure to a lot of media to make them easier to remember. For example, CVE-2019-0709 - Windows Hyper-V Remote Code Execution Vulnerability later became famous as BlueKeep.

CAN: CVE Numbering Authority

Short for CVE Numbering Authority, a CNA is an organization that has permission to assign a CVE ID to a vulnerability and publish CVE records. They can assign and publish vulnerabilities only within their scope. 

For example, The CNA Cloudfare is responsible only for assigning and creating CVEs in “all Cloudflare products, projects hosted at https://github.com/cloudflare/, and any vulnerabilities discovered by Cloudflare that are not in another CNA’s scope.”  CNAs volunteer their time for their own advantage.

Examples of some famous CNAs include 

• IT vendors like Apache Software Foundation, Microsoft Corporation, Apple Inc, etc.
• Open-source projects like Eclipse Foundation (Eclipse IDE), Docker Inc (Docker maintained open-source projects) 
• National and Industry CERTs like Cybersecurity and Infrastructure Security Agency (CISA) and Industrial Control Systems (ICS)
• Bug bounty services providers like HackerOne and Frappe Technologies Pvt. Ltd.
• Hosted services such as Carrier Global Inc.
• Vulnerability researchers seeking out vulnerabilities in third-party software discovered by IBM X-Force, Meta, Airbus, etc.

The CVE Board

The CVE Board comprises various cyber-security professionals like cybersecurity organizations, academia, research institutions, security experts, government departments and agencies and end-users. Its responsibility is to ensure the standards of the CVE Program. Through an open and collaborative process, the board provides useful inputs to the goals, strategic direction, and many other critical opinions.

You can see the current and past members of the CVE board on the CVE website page CVE Board Character. Also, the public can see the meetings and email discussions in email discussions and meeting archives. 

Now let’s turn an important part of this conversation: what to do when there’s a CVE in your existing product. You might hear the terms “CVE management” or “managing CVE severity” as part of this conversation.

How to respond to CVEs in builds

In a-near perfect world, you would instantly fix your application every time a relevant CVE was issued. But in the real world, reacting to CVEs requires a careful calculation. You need to assess whether each CVE is serious enough to warrant the rejection of a build and a delay of a release. That’s a careful balancing act — on the one hand, you don’t want to release code with serious known vulnerabilities, but on the other, you want to avoid constant delays caused by unexpected CVE announcements.

While there’s no one-size-fits-all answer about how to decide which CVEs are serious enough to warrant the rejection of a build, there are some key considerations that can help you make this decision. Keep reading for an overview of how to assess CVE severity.

Managing CVEs

Many tools can automatically monitor and scan your application code, dependencies or environments in an effort to detect components that are subject to known CVEs. Thus, it’s relatively easy to find CVEs that are relevant to an application you develop or manage.

The harder task is what to do when you discover a CVE that impacts your application. As noted above, it’s not always practical to delay the release of your application until the CVE is addressed. Importantly, though, patches to correct CVEs sometimes appear almost as quickly as a CVE is announced. In some cases, it can take months or longer before a CVE solution becomes available (and it’s not always clear how long it’s going to take for a fix to arrive).

You may not be able to wait that long.

Also, you may simply get so many CVE alerts that delaying a release in response to each one is not feasible. If your application is complex and has lots of dependencies, you could get multiple CVE alerts each week. Delaying your release pipeline in response to each one would create a lot of confusion and impact your ability to deliver continuously.

So, how should you react when a CVE is announced? Let’s look at the three most common approaches:

• Policy-based CVE management
• Case-by-case CVE management
• The hybrid approach

A conservative approach: Policy-based CVE management

The first approach to CVE management is to maintain a consistent policy where, based on a CVE’s severity rating, you always handle a CVE announcement in the same way. For example, you could enforce a rule where any CVE with a severity ranking of medium or greater means your delivery pipeline will be put on hold until the issue is addressed.

This approach is conservative: you’re applying a blanket policy to all CVEs. You assume that every CVE of a certain type is serious until proven otherwise. The upside of this approach:

• It’s consistent and therefore easy to automate.
• It allows you to err on the side of prioritizing security over delivery speed, which may be desirable if you’re particularly risk averse.

The downside to strict policy-based CVE management is that you’ll likely end up delaying your releases in response to CVE announcements that don’t have an actual impact you.

Remember that the severity assessments from NIST and other organizations are useful but they’re also generic and subjective. Just because a given CVE is deemed critical, for example, doesn’t mean it’s critical for your unique configuration.

A flexible approach: Case-by-case CVE management

The other CVE management strategy is to assess each CVE on a case-by-case basis, then determine a course of action. This strategy is more flexible — and it also involves taking more risks. This strategy can’t really be automated. It requires your security engineers to:

1. Read each relevant CVE alert, no matter the time of day or night.
2. Make a decision about whether it’s serious enough to delay a release.

This approach may also be inconsistent. On the other hand, a case-by-case approach is more flexible and provides the ability to maintain release speed even in the face of recurring CVEs.

The hybrid approach

Importantly, the two strategies described above don’t have to be an either/or proposition. You can combine them to develop a hybrid CVE management strategy. For example, you could…

• Use both approaches. Use a policy-based approach where you delay the release for all CVEs with a critical severity ranking, and then a use case-by-case assessment to make determinations about those that fall between medium and critical.
• Provisionally delay releases in response to all CVEs with a severity ranking of medium or higher, and then assess them individually in order to decide what you want to do on a case-by-case basis.

Best practices

At the end of the day, your team must manage CVEs in their own way. There’s no universal advice about which of the strategies described above works best. However, considering these factors can help you determine your most appropriate approach.

How serious is a security issue for you? If you’re developing a finance app, for example, you’ll probably need to be more conservative in the way you handle CVEs than you would if your vertical is less regulated.

How easily can you roll back a release? If you can roll back quickly and easily, you may be able to take more risks when it comes to CVEs because you have a greater ability to pull a release quickly in the event a CVE you chose to ignore turns out to be serious.

How much in-house security expertise do you have? Not everyone is equally qualified to interpret the severity of a CVE. With the right expertise, a case-by-case approach may be best. But if your team isn’t set up for this, maybe the conservative approach of equal treatment is right.

Sometimes, CVEs can be tolerated

CVEs are serious business. But just how serious a CVE is for your team and project can range widely. Having a healthy perspective on your ability to tolerate CVE-related delays is critical for ensuring you successfully navigate the straits separating CVE obsessiveness from a fundamentally insecure CVE policy.