CVE Assignment Information Format

The information on this page is excerpted from “Appendix B: CVE Information Format” of the “CVE Numbering Authorities (CNA) Rules” document, and provides the required Format, a Correctly Formatted Example, and information about the JSON Submission and Storage Format.

Format

CVE Numbering Authorities (CNAs) must provide CVE assignment information to the CNA level above them using the following format. The use of this format facilitates the automation of CVE assignment.

1. The preferred format for submitting CVE assignment information is using the JSON schema.
2. In a flat file, use this format:
   

   [CVEID]:

   [PRODUCT]:

   [VERSION]:

   [PROBLEMTYPE]:

   [REFERENCES]:

   [DESCRIPTION]:

   [ASSIGNINGCNA]:

3. In a Comma Separated Values (CSV) file, each row should include each of these columns with CVE ID as a primary key.

There are no format limitations on the actual data, which allows for flexibility across products that may have unusual versioning or differing definitions, such as what a “problem type” means. The only exception to this is that references must be URLs. With or without this technical standard, the information referenced by each field is required for assigning a CVE ID. In all cases, the content included in CVE Entry submission must be germane to the vulnerability. The Primary CNA reserves the right to modify or reject content included in CVE assignment if it is deemed inappropriate by the Primary CNA. Any information submitted as part of a CVE Entry must be submitted in English, though CVE Entries may reference content in any language.

Where applicable, make use of industry standards when describing vulnerabilities.

[PRODUCT]

As a general guideline, [PRODUCT] should include the vendor, developer, or project name as well as the name of the actual software or hardware in which the vulnerability exists.

[VERSION]

[VERSION] should include the version, date of release, or whatever indicator that is used by vendors, developers, or projects to differentiate between releases. [VERSION] can be described with specific version numbers, ranges of versions, or “all versions before/after” a version number or date.

[PROBLEMTYPE]

As mentioned above, [PROBLEMTYPE] can include an arbitrary summary of the problem, though Common Weakness Enumerations (CWEs) are an excellent standard to use in this field.

[REFERENCES]

[REFERENCES] should be URLs pointing to a world-wide-web-based resource. For CSV and flat-file formats, they should be separated by a space. References should point to content that is relevant to the vulnerability and include at least all the details included in the CVE entry. Ideally, references should point to content that includes the CVE ID itself whenever possible. References must also be publicly available, as described in Section 2.1.1 of the CVE Numbering Authorities (CNA) Rules.

[DESCRIPTION]

The [DESCRIPTION] field is a plain language field that should describe the vulnerability with sufficient detail as to demonstrate that the vulnerability is unique. The required information listed above should be included in the [DESCRIPTION], as well as other details the author feels are relevant or necessary to show uniqueness.

Specifically, the [DESCRIPTION] field could also include:

• An explanation of an attack type using the vulnerability;
• The impact of the vulnerability;
• The software components within a software product that are affected by the vulnerability; and
• Any attack vectors that can make use of the vulnerability.

Descriptions often follow this template:

     [PROBLEM TYPE] in [PRODUCT/VERSION] causes [IMPACT] when [ATTACK]

where impact and attack are arbitrary terms that should be relevant to the nature of the vulnerability.

[ASSIGNINGCNA]

The [ASSIGNINGCNA] field should include the name of the assigning CNA. CNAs should use a consistent name to facilitate searches for CVE IDs that originate from them.

Correctly Formatted Example

Following is an example of the reporting format in use. In this case, the Sub-CNA “BigCompanySoft” is assigning a CVE ID to versions of their product.

JSON Submission and Storage Format

The JSON schema will be reviewed periodically. The review cycle will follow a schedule similar to this example:

First 30 days (September)

• Open comment period including CVE Board and CNAs.
• One or two Automation WG calls specifically set aside for discussion of proposed changes.
• At the end of this period, no additional suggestions will be included in the revision cycle.

Next 30 days (October)

• The community will work in one-week sprints (WG meetings and mailing list discussions) with a subset of the proposed revisions discussed during each sprint. Each subset is only to be discussed during that sprint.
• There will be four total sprints (making this part a four-week process).
• At the end of a sprint, if something was not resolved or discussed, it will not be included in the revision.
• When something is resolved, any changes based on it are included within the development branch at that time.
• At the end of all sprints, the JSON format will be finalized and sent to the Board for approval.

Next 60 days (November and December)

• CNAs can use the development branch for testing new features and changes.

New JSON Format in Effect (January)

• The new JSON format would take effect on January 1 of the next year. This would give CNAs two months to implement any changes to their processes that become needed after the JSON format revised.