CNAs and CVE Counting

A large percentage of newly discovered software or open library vulnerabilities are submitted as potential entries to MITRE's Common Vulnerability and Exposures (CVE) list, and a rigorous process has been established to vet these submissions to ensure that they meet the standards for assigning CVE IDs. After ID assignment and publication, the vulnerabilities undergo analysis by the National Vulnerability Database (NVD) and are then published on the NVD website. The organizations authorized to assign CVE IDs are known as CVE Numbering Authorities (CNAs).

CNAs

In order to become a CNA, a qualified organization must express interest in volunteering its time to distributing CVE IDs to eligible vulnerabilities. CNAs have a well-defined scope for which vulnerabilities they will be assigned for the vetting process. They do not pay any fee or sign any contract, but they are subject to specific rules that help maintain consistency throughout the process. Compared to similar arrangements, these requirements are nominal.

In general, CNAs are vendors or other seasoned organizations with a record of researching vulnerabilities and demonstrating security advisory capabilities. They commonly have an established user base, and their security information is regularly consulted by researchers and vendors. They may also be well-established bug bounty hunters.

An onboarding process has been established to ensure that CNAs meet the standards of the CVE program. Potential CVE analysts and CNA candidates are given strict instructions for vetting vulnerabilities, including a wide range of examples and exercises. Should a CNA demonstrate the appropriate level of expertise and communication required, they are approved and become operational.

CNA Hierarchy

One of the key characteristics of any CNA is its place in the CNA hierarchy. CNAs may be categorized as Program Root at the highest level, followed by Root and Sub-CNAs. Sub-CNAs are overseen by Root CNAs, while Root CNAs are only governed by the Program Root or possibly another Root. Higher level CNAs assign blocks of CVE IDs to their subordinates, which are then reserved for potential assignment. Despite their place in the hierarchy, all CNAs are subject to the same rules. If a higher-level CNA determines that a CNA under its purview is non-compliant, they have the authority to impose sanctions. In order to regain full operating status, the CNA in question must undergo further training and demonstrate a reimplementation of CNA guidelines. The higher-level CNA that made this determination is responsible for administering the remediation process.

Sub-CNAs are the first choice for assigning IDs to vulnerabilities within their scope, but Root CNAs and the Program Root may be consulted later.

General CNA Responsibilities

When a CNA is in a position to consider a reported vulnerability, there is an immediate requirement: an accessible URL must be provided that has information about the vulnerability, and the CVE project must be permitted to link to it on their own site. If this or other basic information is insufficient, the CNA will contact the reporter for additional information. (Malware and closed betas are not eligible for consideration.) Once the CVE is cleared through the vetting process, a CVE ID (or blocks of IDs) will be given to the reporter. A reasonable effort must then be made by the CNA to inform the code's maintainer.

There are two parts to the vetting process: 1) determining how many vulnerabilities are present in a request and 2) whether or not these vulnerabilities are eligible for CVE IDs. The first part of the process is determined by Counting Rules and the latter by an “inclusion decision” process.

Once the vulnerability has been assigned the appropriate IDs, the CNA writes a vulnerability description, adds references, and publishes the appropriate information. CNAs are advised to report the CVE ID's publication upstream within 24 hours. They must also keep superior CNAs informed of which CVE IDs are still reserved after a period of time, and metrics must be regularly tracked and provided.

Root CNAs have similar responsibilities, but they act as adjudicators should issues be escalated to their level. They also maintain a public list of Counting Rules.

Finally, in addition to overseeing and administrating the duties of subordinate CNAs, the Program Root maintains the CVE List, acts as a final resort of appeal for disputes, and serves as the moderator of the CVE board. Metrics that have been gathered by all CNAs are received quarterly by the Program Root. It is imperative that inquiries made by Root or Sub-CNAs are resolved in a timely manner.

CNAs follow disclosure guidelines which may include the US CERT's vulnerability disclosure policy, ENISA Good Practice Guide on Vulnerability Disclosure, ISO/IEC 29147 Vulnerabilty Disclosure, NTIA “early stage” Coordinated Vulnerability Disclosure Template, or the Open Source Responsible Disclosure Framework.

Counting Rules

Once a bug has been identified as a vulnerability, a determination must be made as to whether or not it can be fixed independently of other bugs. If independent remediation is not possible or its status unclear, it is possible to combine this bug with others to meet the criteria. Next, the vendor or maintainer of the code base must acknowledge an adverse impact on its security and confirm that it is a vulnerability. (If the vulnerability itself is a design flaw that violates the security policy that governs it, a CVE ID is not assigned.)

Once the preceding process is complete, potential CVE IDs will be assigned. If the same code affects multiple products, or multiple products are affected but with different code, a potential CVE ID will be issued for each instance.

Inclusion Decision

Once the Counting Process is complete, another screening is conducted. First, as all information in the CVE project is publicly available, the bug must be made public or its existence intended to be made public. If this is not the case, the CVE ID is not assigned. Additionally, a vulnerability may not be confined to an independent server, specific website, or offered through a hosting solution in complete control of the vendor. Finally, the configuration of the software that is affected must generally be available to the public or the vendor's user base.

A final check is made to see if the vulnerability has already been assigned a CVE ID. If not, then a CVE ID is assigned and published in the CVE list.

Rejected requests can be appealed to MITRE or the CNAs.