Researcher Reservation Guidelines, Version 0.1 (Archived)

IMPORTANT : This page has been archived. Please see the Researcher Reservation Guidelines for the most current information.

This document provides information on how to reserve a CVE ID (s) before publicizing a new vulnerability so that CVE IDs can be included in the initial public announcement of the vulnerability and can be used to track vulnerabilities.

Some important things to note:

• The CVE request process reduces the amount of overlap with the work of other entities by identifying which organization(s) should be contacted first.
• The CVE request process is designed to ensure all vulnerability information included in CVE is publicly available. This reduces the risk of accidental disclosure of such information. Details provided in requests will not be released until those details have been made public .
• If a requester does not use and share CVE IDs properly, MITRE and other CVE Numbering Authorities (CNAs) reserve the right to refuse assigning CVE IDs to that requester in the future. Steps 2, 10, 11, and 12 in the list below provide details on proper use and sharing of CVE IDs.

Table of Contents

1. Determine if a CVE ID is needed and appropriate.
2. Contact the affected product vendor directly.
3. Requests to a vendor CNA.
4. Requests to third-party coordinator CNAs or email lists.
5. Requests to MITRE (Primary CNA).
6. Information to provide in the request to MITRE.
7. Confirmation of request.
8. Follow-up information requests from MITRE.
9. Receive a CVE ID (or rationale if not assigned).
10. Sharing the CVE ID with others.
11. Information to include in a vulnerability announcement.
12. Notify the MITRE CVE Assignment Team of publication.

Appendix A: Documents on Disclosure Practices
Appendix B: Determining if CVE IDs Are Needed
Appendix C: PGP Key

The basic process for reserving a CVE ID is as follows:

1. Determine if a CVE ID is needed and appropriate.

CVE IDs are currently only assigned to vulnerabilities that are going to be publicly announced.

1. Determine whether the problem you identified is a vulnerability. A vulnerability in the context of the CVE program is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change, or specification deprecation to mitigate or address.
2. Ensure that the vulnerability for which you are seeking a CVE ID does not already have an assigned CVE ID by performing a keyword search on the CVE List .

2. Contact the affected product vendor directly.

You should make a good faith effort to notify the affected vendor and work with them to ensure that a patch is available prior to publicly disclosing the vulnerability. Information is more accurate and complete when researchers and vendors work together. This practice also reduces the likelihood of a duplicate CVE ID being issued, which can happen when both a researcher and vendor request CVE IDs.

Without independent confirmation or vendor acknowledgement, it may not be possible to determine if the vulnerability is real, which could result in a request for a CVE ID being denied.

There are several documents that provide guidelines on disclosure. See Appendix A: Documents on Disclosure Practices for more details.

In general, you should do the following:

1. Find and notify the appropriate security contact for the vendor. If you cannot find a contact, try technical support.
2. Allow the vendor five business days to respond and acknowledge that they are aware of the problem. An "auto-reply" email or other computer-generated response does not represent vendor awareness.
   

   a) Work with the vendor to explain the problem, conduct further analysis if necessary, test any patches that the vendor proposes, and ensure the accuracy of both your, and the vendor's, advisory.

3. If, after five business days, the vendor is unresponsive, report the problem to a third party "coordinator" such as CERT/CC. These coordinators may have contacts with the vendor, or they may lend credibility to your report.
4.  If an advisory will not be published by the vendor or an established response team (e.g., CERT/CC), you may choose to announce the vulnerability to a public forum that allows others to validate the claims. Currently, those forums include the Bugtraq and Full-Disclosure mailing lists, and sites such as exploit-db and Packet Storm.

When possible, do not announce a vulnerability until the vendor has provided a patch. This could take between one day and six months, depending on the vendor and the nature of the problem. If you believe that the issue is urgent and the vendor is not responding quickly enough, try using a coordinator as described in Step 4 below. Also, you should avoid releasing precise details of the vulnerability until system administrators have time to apply the patch.

3. Requests to a vendor CNA.

Software vendors participating as CNAs assign CVE IDs for their own products.

If the vulnerability is related to a CNA product, contact the appropriate CNA organization directly. If the request is accepted, the organization will assign a CVE ID for the issue and include it in its initial public announcement.

4. Requests to third-party coordinator CNAs or email lists.

If a CVE ID cannot be requested through a CNA, consider contacting a third party coordinator such as an emergency response or vulnerability analysis team (e.g., CERT/CC), especially when there are problems in contacting the affected vendor.

5. Requests to MITRE (Primary CNA).

If you are unable to obtain a CVE ID via the methods cited above, you may request a CVE ID directly from MITRE using MITRE's CVE Request web form (view guidance ). Complete the "Request a CVE ID" web form.

Determine if the affected product is within the scope of MITRE as a CNA by checking Products Covered . If a product is not within scope, it may not be issued a CVE ID by the MITRE CVE Assignment Team.

As an exception, the MITRE CVE Assignment Team assigns CVE IDs for products that have been packaged by a Linux distribution on our Product List, such as Debian or Fedora. It is not necessary for the specific product name to be listed on the Product List.

CVE IDs are not assigned by the MITRE CVE Assignment Team for software that may be optionally added to a listed product, such as a third-party plugin or module. For example, CVE IDs are assigned for the WordPress core product, but not for any WordPress plugin. CVE IDs are also not assigned for Android or iOS apps unless the app's author is a listed vendor.

In addition, the MITRE CVE Assignment Team assigns CVE IDs for a number of programming languages including Python and PHP, but not for all code written in those languages. As an example, CVE IDs are not assigned for a web application written in PHP, unless the product or vendor is separately listed.

6. Information to provide in the request to MITRE.

The "Request a CVE ID" selection on MITRE's CVE Request web form requires the following information:

• The type of request;
• The e-mail address of the requester;
• The number of IDs being requested;
• The type of vulnerability for each CVE ID requested;
• The affected vendor for each vulnerability; and
• The affected product and version for each vulnerability (a generic name can be used if the vulnerability has not been made public).

The required information is the minimum information required to request a CVE ID. However, you can also provide optional information which can be used to provide additional detail for your CVE ID request and may be valuable to creating the CVE entry as well as for downstream consumers.

Optional information includes:

• Attack type;
• Impact;
• Affected component;
• Attack vector;
• Discoverer;
• References; and
• Any additional information.

7. Confirmation of request.

Upon completion of the CVE Request web form, the requestor will receive a confirmation email that the request was received and a reference number. If you need to communicate with MITRE about this request, reply to the confirmation email without changing the subject line, as it contains the reference number associated with your request.

If you do not seem to have received a confirmation email, please check your spam folder.

8. Follow-up information requests from MITRE.

If MITRE requires any additional clarification, they will contact the requester via email, referencing the confirmation number for the submitted CVE Request.

9. Receive a CVE ID (or rationale if not assigned).

Once there is enough information to confirm the vulnerability exists and that it affects a covered product, the MITRE CVE Assignment Team will reply to the requester with a CVE ID. The CVE ID is considered "reserved" at this stage. Descriptions with details of the vulnerability will only be added when the vulnerability is made public (see step 12).

If the vulnerability is not confirmed, or if it is not in a covered product, a CVE ID request may be rejected. In this case, the requester will receive a response from the MITRE CVE Assignment Team notifying them of the decision.

10. Sharing the CVE ID with others.

Once a CVE ID is obtained, provide it to all affected vendors and other parties (such as CERT/CC) with whom you are communicating. This makes it easier to share information about the vulnerability and reduces the risk that different parties may assign different CVE IDs to the same vulnerability.

11. Information to include in a vulnerability announcement.

When publishing a vulnerability with an associated CVE ID, include the CVE ID in the announcement. Announcements containing multiple CVE IDs should delineate which CVE ID is associated with which vulnerability.

The following information may be contained in the vulnerability announcement:

• The Common Vulnerabilities and Exposures (CVE) project has assigned the ID CVE-YYYY-NNNN to this issue. This is an entry on the CVE List , which standardizes names for security problems.
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-NNNN
• CVE ID: CVE- YYYY-NNNN

Some tips:

1. When announcing more than one CVE ID, associate each CVE ID with the vulnerability it is assigned to, so that people can easily identify which CVE ID is related to each issue. For example:

• CVE-yyyy-nnnn - buffer overflow in product
• CVE-yyyy-mmmm - format string

2. OSVDB offers additional suggestions about other content in the announcement:

• https://blog.osvdb.org/2013/01/15/researcher-security-advisory-writing-guidelines

12. Notify the MITRE CVE Assignment Team of publication.

After your announcement has been publicized, contact the MITRE CVE Assignment Team by either replying to the original email discussion or via the CVE Request web form . If you submit a new form, select "Notify CVE about a publication" and provide the following information:

• The CVE ID(s) assigned to the vulnerabilities being publicly announced.
• Links to the public forum(s) or advisories where the announcements can be found.

Until this information is provided to MITRE, only a reserved CVE entry may be recorded on the CVE web site. No description or details of the vulnerability will be made available in the CVE entry until the vulnerability has been publicized.

When notified of a publication, MITRE will then populate the CVE entry with a description and references. This information will be made available on the CVE List .

The CVE information will also be updated in the U.S. National Vulnerability Database (NVD) .

Appendix A: Documents on Disclosure Practices

The following documents describe processes and provide guidelines for coordinated vulnerability disclosure practices.

1. "Guidelines for Security Vulnerability Reporting and Response," Organization for Internet Safety. Version 2.0, 01 September 2004.
   https://www.oisafety.org/ │ http://www.symantec.com/security/OIS_Guidelines%20for%20responsible%20disclosure.pdf
2. "Responsible Vulnerability Disclosure Process," IETF draft document, Christey/Wysopal. February 2002.
   https://tools.ietf.org/html/draft-christey-wysopal-vuln-disclosure-00

Appendix B: Determining if CVE IDs Are Needed

There are several factors to consider to determine whether one or more vulnerabilities require a CVE ID when providing information to MITRE:

A. Duplicates

Duplicates may be found by searching the MITRE CVE website and also by general web searches. Also, if a researcher previously contacted another organization on the CNA list about a vulnerability, a CVE ID assignment may already exist. The vulnerability should not be duplicated by the assignment of two CVE IDs.

B. Origination

CVE IDs are assigned to issues for which the primary method of addressing the vulnerability is for the vendor to take an action to remediate the vulnerability in their product. CVE IDs are not for cases in which the primary method of addressing the vulnerability is for an action to be taken by the operator of a single website or online service.

C. Establishing a policy violation

CVE IDs are needed when the vendor agrees that the observed product behavior violates a security policy, such as an unintended loss of confidentiality, integrity, or availability. CVE IDs are not for cases in which a reporter unilaterally believes that product hardening is desirable, such as a different approach to abuse prevention, or a different display of security-relevant data.

D. Establishing whether the vulnerabilities differ

In cases of multiple findings reported at the same time for a single product, separate CVE IDs are sometimes needed when there is a difference in the primary vulnerability types or affected versions.

E. Cross-vendor coordination

Separate CVE IDs are not assigned solely because vulnerable code is shipped in more than one product. Particularly in the case of open-source software, it is common for multiple vendors to use the same CVE ID in any scenario in which they have bundled, repackaged, or copied a piece of vulnerable code.

Appendix C: PGP Key

You may encrypt any post-web form communications using PGP or GnuPG (gpg), with the Primary CNA's PGP key , which can be downloaded from various PGP key servers.