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
    Vulnerability Report
    Counting Decisions
    Inclusion Decisions

Introduction

The nature and accuracy of the counting process underpins the value of a CVE ID. 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.

Vulnerability Report

The decision trees below 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.
For each bug, continue 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)?
For each bug, continue to CNT2
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? In addition, consultation with the root CNA is recommended when the vulnerability affects software covered by other CNAs.

Yes: Continue to INC1 for the vulnerability in the shared codebase

No: For each product affected by the vulnerability, continue to INC1

Not sure: For each product affected by the vulnerability, 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 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.

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 web site, 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.

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 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

Page Last Updated or Reviewed: August 01, 2017