Share
The CVE Program
In case you’re unaware, the Common Vulnerabilities and Exposures (CVE) Program aims to catalog publicly known cybersecurity vulnerabilities and is currently overseen by the MITRE Corporation.
Note the wording “publicly known cybersecurity vulnerabilities.” Did you know that organizations are not expected to submit a CVE for internally discovered vulnerabilities per the CVE Program?
To support this program, there are over 380 current partners, which each fall into one of the following categories:
Top-Level Roots: Report directly to the CVE Board and manage Root CNAs, CNAs, and CNA-LRs; currently, CISA and MITRE.
Roots: Oversee and support a group of CNAs, ensuring adherence to CVE guidelines.
CNAs: A CVE Numbering Authority Assigns CVE IDs and publishes information on vulnerabilities within their scope.
CNA-LRs: A CVE Numbering Authority of Last Resort handles vulnerability reports not covered by any existing CNA.
Read more about the CVE Program Structure or Program Roles and Organization Types
Most of these partners are CVE Numbering Authorities (CNAs), who review vulnerability submissions and determine whether they warrant a CVE identifier. The following sections will detail how the latest changes to their rules may impact vulnerability disclosure and vulnerability management processes.
CNA Rules Update V4.0
The board has approved version 4.0 of the CVE® Numbering Authority (CNA) Rules, which will go into effect on August 8, 2024. For reference, version 3.0 was released in March 2020, and the work to revise these rules began in early 2022, meaning this update has been over two years in the making! What are the notable changes? And how might they impact you?
The Three Biggest Changes
While version 4.0 is a major overhaul, the following three categories summarize the most significant changes.
Right of First Refusal
4.2.1.1: “The CNA with the most appropriate scope MUST be contacted and given the first opportunity to assign. In many cases, this CNA is the Supplier of the Product in question.”
Under the new guidelines (4.2.1.1), the CNA with jurisdiction over the product involved must receive the first opportunity to assign a CVE ID. This ensures that entities most familiar with the product are the primary decision-makers in the disclosure process, streamlining the management of vulnerabilities and enhancing the accuracy of the information reported.
Technology-neutral Assignments
4.2.3: “CNAs MUST NOT consider the type of technology (e.g., cloud, on-premises, artificial intelligence, machine learning) as the sole basis for determining assignment.”
This rule change (4.2.3) emphasizes a technology-agnostic approach in the CVE assignment process. CNAs are now explicitly required to avoid bias towards the technology platform, whether cloud, on-premises, AI, or others. This change aims to ensure a uniform standard in the CVE process across different technological realms, facilitating a more balanced representation of vulnerabilities regardless of the underlying technology.
There has been debate regarding cloud platforms and whether security misconfigurations warrant a CVE assignment. For instance, if an organization has a misconfigured S3 bucket, does that receive a CVE? How about a known-insecure default configuration on a cloud solution? Many have disagreed and feel strongly that they do not deserve CVEs.
The CVE Program treats “vulnerability” as an adaptable term to meet present-day expectations. With this rule update, it is clear that they intend cloud security misconfigurations to be vulnerabilities.
Clarity for CVE Assignments
The criteria for what constitutes a vulnerability worthy of a CVE ID have been clarified. For example:
4.1.8 General purpose deliberately malicious code MUST NOT be determined to be a Vulnerability.
4.1.9 Products that have been modified to become malicious, for example, trojan horses, backdoors, or similar supply chain compromises, MAY be determined to be a Vulnerability.
4.2.2.1 CNAs SHOULD assign a CVE ID if:
the CNA has reasonable evidence to determine the existence of a Vulnerability (4.1), and
the Vulnerability has been or is expected to be Publicly Disclosed, and
the CNA has appropriate scope (3.1).
Is this a vulnerability? Does it warrant a CVE?
There is still much ambiguity concerning vulnerabilities impacting upstream software dependencies, protocols, frameworks, etc. Let’s consider the following updated rules (7.2.4 and 7.2.5 in CNA Rules v3.0):
4.2.13 If multiple Products are affected by the same Independently Fixable Vulnerability, then the CNA:
MUST NOT assign more than one CVE ID if the Products are vulnerable because they share the vulnerable code. The assigned CVE ID will be shared by the vulnerable Products.
SHOULD assign different CVE IDs if the Products do not share vulnerable code.
SHOULD assign different CVE IDs if the CNA is uncertain whether the Products share vulnerable code.
4.2.14 If a Product is affected by a Vulnerability because it uses the functionality or specification of another Product, then a CNA:
MUST assign a CVE ID to each known vulnerable implementation if there is a secure way of using the functionality or specification.
MUST assign a single CVE ID if there is no option to use the functionality or specification in a secure way.
SHOULD assign different CVE IDs to each known vulnerable implementation if the CNA is uncertain whether there is a secure way.
The definition of “Independently Fixable Vulnerability” is too vague, making it useless for real-world applications. For instance, if a vulnerability exists in a protocol used by many products, updating the protocol may resolve it for all affected products, but that may be unrealistic. Therefore, individual fixes may be necessary. Additionally, it’s uncertain what is meant by “if there is a secure way of using the functionality or specification.”
Consider two well-known HTTP/2.0 protocol vulnerabilities that impact many products as a real-world example. Neither vulnerability impacted all protocol usages, and neither was remediated through a single fix.
HTTP/2 CONTINUATION Flood - No CVE was assigned to the HTTP/2.0 Protocol, but dozens of CVEs were assigned to affected products.
HTTP/2 Rapid Reset - One CVE assigned to the HTTP/2.0 Protocol (CVE-2023-44487) despite knowingly impacting many products.
Expected impact of the new rules
As the CNA Rules v4.0 roll out, there's a marked shift toward more conditional language—more "shoulds" than "musts.” This highlights an even greater emphasis on flexibility in the CVE assignment process. This approach aims to widen the net on what may be considered a vulnerability, potentially increasing the number of recognized cybersecurity threats.
It's important to note, however, that the real impact of these changes hinges on their enforcement—a facet of the CVE Program that has historically been less than consistent. As the new rules roll out, the community must remain vigilant and proactive to ensure these guidelines are followed and effectively implemented.
My take: the CVE Program wants more CVE submissions and is likely to approve more submissions thanks to increased CNA flexibility. In 2023, ~29,000 CVEs were approved, up over 15% compared to 2022. Predictions for 2024 suggest a total of ~35,000 CVEs, an increase of over 25%. I wouldn’t be surprised if we exceed 50,000 CVEs per year very soon.
Resources:
About
Semgrep lets security teams partner with developers and shift left organically, without introducing friction. Semgrep gives security teams confidence that they are only surfacing true, actionable issues to developers, and makes it easy for developers to fix these issues in their existing environments.
