CVE Counting Rules
The information on this page is excerpted from “Appendix C: Common Vulnerabilities and Exposures (CVE) Counting Rules” of the “CVE Numbering Authorities (CNA) Rules” document, and includes discussion of the topics below.
Introduction
The nature and accuracy of the counting process underpins the value of a CVE Entry. Correct counting reduces the likelihood of duplicate CVE IDs being assigned to a single vulnerability. Also, some reports of vulnerabilities may confuse or conflate multiple, separate software problems, and the counting process helps to differentiate between those vulnerabilities that are unique.
CVE IDs can be assigned to vulnerabilities in any code-based entity or standards upon which code-based entities are designed. This can include software, shared codebases, libraries, protocols, standards, hardware (e.g., firmware or microcode), hardware platforms, file formats, or data encodings.
Vulnerability Report
The following decision trees should be used when receiving a report for a single or multiple vulnerabilities. The decision trees are meant to be used together and are to be followed from top to bottom.
Counting Decisions
Use the following decision tree to determine how many vulnerabilities there are in a report.
NOTE: It is intended that one of CNT2.1 or CNT2.2 be completed, but not both (i.e., A CNA has the flexibility and choice to use the claim-based or security model-based inclusion decision).
| Counting Decision | Description | Action |
| CNT1 | Independently Fixable: For each reported bug, determine if it can be fixed independently of the other bugs (i.e., a code fix can be created to fix only the bug in question)? A common indicator of independently fixable would be that the vulnerability affects a different version of the product than the other reported vulnerabilities. Note that this does not mean that the bugs are fixed independently; only that if the vendor chose to the bugs could be fixed independently. |
If a vulnerability can be fixed independently from the others: Go to CNT2 If the vulnerabilities cannot be fixed independently: Group the bugs together and go to CNT2 If it is not clear whether the vulnerabilities can be fixed independently: Group the bugs together and go to CNT2 |
| CNT2 | Vulnerability: For each bug, apply the following decisions to determine if it is a vulnerability. If the bug does not meet the criteria, can you combine it with one or more other bugs to meet the following criteria (e.g., combine a permissions issue with predictable file name and a race condition to generate a symbolic link attack)? |
See: CNT2.1, CNT2.2A, CNT2.2B |
| CNT2.1 | Vendor Acknowledgment: Does the affected vendor acknowledge the bug as a vulnerability and does it also acknowledge a negative impact on security? Examples of negative impact could include; code execution, providing the attacker with extra privileges or information, causing a denial of service, etc. (i.e., see the definition of a vulnerability as defined by the CVE Program). |
Yes: Continue to CNT3 No: Continue to CNT2.2A or CNT2.2B Not sure: Continue to CNT2.2A or CNT2.2B |
| CNT2.2A | Claim-Based: Does the vulnerability report provide a demonstrated negative impact for the bug? Examples of negative impact could include; code execution, providing the attacker with extra privileges or information, causing a denial of service, etc. (i.e., see the definition of a vulnerability as defined by the CVE Program). |
Yes: Continue to CNT3 No: Do not assign a CVE ID Not sure: Continue to CNT3 |
| CNT2.2B | Security Model-Based: Does the vulnerability report provide evidence of a mistake or design oversight in software that violates the security policy of the system? |
Yes: Continue to CNT3 No: Do not assign a CVE ID Not sure: Continue to CNT3 |
| CNT3 | Shared Codebase, Library, Protocol: Does the vulnerability affect a shared codebase, library, or protocol implementation issue? NOTE: Consultation with the Root CNA is recommended when the vulnerability affects software covered by other CNAs. |
See: “For Shared Codebase” and “For Libraries, Protocols, or Standards” |
| CNT3 | For Shared Codebase: |
Affects a single product: Assign one CVE ID and continue to INC1 Affects the same code in multiple products: Assign a CVE ID to each affected codebase and continue to INC1 Affects multiple products but with different code: Assign a CVE ID to each product and continue to INC1 Not sure or undefined: Assign a CVE ID to each product and continue to INC1 |
| CNT3 | For Libraries, Protocols, or Standards: |
If there is a way to use the library, protocol, or standard without being vulnerable: Assign a CVE ID to each affected codebase or product and continue to INC1 If the using the library, protocol, or standard requires the product to be vulnerable: Assign a single CVE ID and continue to INC1 Not sure: Assign a CVE ID to each affected codebase and continue to INC1 |
Inclusion Decisions
Use this decision tree to determine if a vulnerability should be assigned a CVE ID (i.e., Does vulnerability meet the CVE inclusion decisions?). When multiple vulnerabilities are reported, this decision tree will need to be repeated for each issue.
NOTE: The Inclusion Decisions table describes an order to the inclusion decisions. However, so long as the vulnerability meets all of the conditions, it does not matter which order the decisions are executed in.
| Counting Decision | Description | Action |
| INC1 | In Scope of Authority: Does the vulnerability report fall into the scope of authority for the CNA. CNAs can only assign CVE IDs to vulnerabilities that are within their scope of authority as defined by their root CNA. |
Yes: Continue to INC2 No: DEFER to appropriate CNA or Root CNA Not sure: CONSULT Root CNA |
| INC2 | Intended to be Public: Is the vulnerability report or the issue described currently published publicly or intended to be published to a publicly available location in the future? CVE IDs are intended to be public information and are not assigned to vulnerabilities that are intended to be private. See Section 2.1 of the CVE Numbering Authorities (CNA) Rules for a description of what is considered “public.” |
Yes: Continue to INC3 No: Do not assign a CVE ID |
| INC3 | Installable/Customer-Controlled Software: Is the vulnerability site-specific? Is it only in an online service (software-as-a-service), on a specific website, or only offered through hosting solutions that are under the full control of the vendor? CVE IDs are assigned to products that are customer-controlled or customer-installable. |
Yes: Do not assign a CVE ID No: Continue to INC4 Not sure: Continue to INC4 |
| INC4 | Generally Available and Licensed Product: Does the vulnerability affect software that is licensed and made generally available to the public? If the vulnerability only affects a version of software that was never made generally available to the publisher's or vendor's customers, the bug should not be assigned a CVE ID. CVE IDs are not assigned to bugs in malware, closed betas, commits that were fixed before a new release is issued, applications used only within a single organization (such as a unique, custom-built system). |
Yes: Continue to INC5 No: Do not assign a CVE ID Not sure: Continue to INC5 |
| INC5 | Duplicate: Has the vulnerability already been assigned a CVE ID by you or does it already exist in the CVE List? |
Yes: USE the existing CVE ID No: ASSIGN a CVE ID Not sure: ASSIGN a CVE ID |
