CVE Blog

The purpose of this blog is to establish a dialogue and get your input on issues and topics important to CVE. Send feedback about this page to cve@mitre.org.

Summary of your feedback about updating info in CVE ID Descriptions

Thank you for your responses to our most recent post "What's your opinion on updating CVE ID Descriptions?" about whether or not CVE ID Descriptions should be updated as new information becomes available, or if we should we reject and recreate the CVE IDs instead.

Updating of CVE ID Descriptions is preferred

The majority of respondents indicated that updating CVE ID Descriptions with new information is preferable to rejecting and issuing new CVE IDs.

The goals of CVE entries are to help people find the information they need about a vulnerability and provide enough information to allow people to be confident they are talking about the same vulnerability. Ensuring that CVE entries contain the most recent information on a vulnerability, either by updating an existing CVE entry or rejecting and issuing a new CVE entry, supports these goals.

Moving forward

As the CVE program continues to develop its policies and practices, we will consider the feedback from the CVE community on the benefits of updating CVE entries versus issuing new CVE entries.

If you have any further comments on the practice of updating CVE descriptions, please let us know. You can offer your feedback through the CVE Request form at https://cveform.mitre.org/ or via email at cve@mitre.org.

Thank you again to all who participated.

- The CVE Team
  February 2, 2017
  cve@mitre.org

What's your opinion on updating CVE ID Descriptions?

Last month, we asked the CVE community how you used CVE ID Descriptions. This month, we are following up on that question, asking about another aspect of how CVE ID Descriptions and their content are used.

Specifically, we would like to hear your thoughts on updating CVE ID Descriptions when new details about the vulnerability become available.

When a CVE ID is published, the Description of the vulnerability includes the details that are available about the vulnerability at that time. But as time goes by, more information may come to light regarding the vulnerability that should be reflected in the Description.

For example, the products or versions of products that are affected by the vulnerability may need to be updated after a vendor releases new information. Also, the CVE ID could change from covering a single product to a library or protocol that affects many products.

To update or not update

When such changes happen, CVE could update existing CVE ID Descriptions with that new information. But is doing so a problem for CVE consumers?

For example, in December, someone may see a new CVE ID describing a vulnerability in version 1.2 of ProductX. They use version 1.3, so they can ignore the vulnerability. But then the following February, ProductX's vendor finds that the vulnerability does affect version 1.3, and CVE updates the CVE ID Description to include that detail. At this point, the consumer may not notice the change, or they find themselves suddenly susceptible to a vulnerability to which they thought they weren't vulnerable.

Alternately, CVE could assign a new CVE ID that includes both version 1.2 and 1.3 and reject the original CVE ID. The scope and affected products of the new CVE ID would be unambiguous, and the new CVE ID would be picked up by the usual vulnerability management processes that an organization might follow. The downside of this methodology is confusion about the state of the original CVE ID, which is still valid but not complete.

One scenario that CVE has seen commonly is as follows: A vendor wants to issue an advisory before they know what the fixed patch version will be. They could include the currently known, affected versions, but this could mistakenly mean that later versions are not affected. Alternatively, they could leave out mentioning any version information in the first place and update the description when they know what is the complete range is.

What do you think?

Should CVE update CVE ID Descriptions as new information becomes available, or should we reject and recreate CVE IDs instead? Is there another practice that you would find more helpful?

Please email us at cve@mitre.org with your thoughts regarding updating CVE ID Descriptions before the end of this month.

All feedback will be collected, aggregated, and posted on this page the first week or so of January. Also, please let us know in your message if you do not want your feedback included in the publicly posted results.

We look forward to hearing from you!

- The CVE Team
  December 15, 2016
  cve@mitre.org

Summary of your feedback about how Descriptions are used in CVE IDs

Thank you for your responses to our CVE blog question "What's your opinion on how Descriptions are used in CVE IDs?". We received five responses from various CVE users, and we look forward to hearing more from across the CVE community.

A business need for Description in CVE IDs

Overall, there appears to be a business need for CVE ID Descriptions. The details provided in the Descriptions strengthen an organization's business case by providing the details required to add credibility to the vulnerability claim and to differentiate between vulnerabilities. CVE ID Descriptions are not dependent on a reference website, improving availability. The Descriptions are searchable, users can track changes, and they can be used in different formats and presentations.

CVE ID Descriptions are often used internally to facilitate the discussion about a vulnerability. A concise CVE ID Description is easier to read on different devices then a linked reference. In addition, linked references are not always available, relevant information is not always evident, and websites do not display properly on different types of devices.

All the information provided in the CVE ID Description is seen as valuable, with the affected product/impacted version being the most important. The priorities of other fields can vary, however the more extensive or expensive the fix, the more all Description fields are important.

Moving forward

In October 2016, other entities were given the ability to write CVE ID Descriptions. Feedback on the quality of CVE ID Descriptions will be very useful for understanding the effects of that change.

If you find the content of CVE ID Descriptions does not match your needs, please let us know through the CVE Request form at https://cveform.mitre.org/ or via email at cve@mitre.org.

Thank you again to all who participated.

- The CVE Team
  December 2, 2016
  cve@mitre.org

What's your opinion on how Descriptions are used in CVE IDs?

Since its inception in 1999, the CVE Program has included IDs, references, and descriptions in CVEs. Descriptions have primarily functioned as a method for the CVE Program to search CVEs, identify duplicates, and perform other similar functions.

We believe that other members of the community use Descriptions as well, but are unsure how they are used today or which parts of Descriptions are considered valuable.

The CVE Team invites you to email us at cve@mitre.org between now and November 17, 2016 to tell us about your experience using Descriptions. All feedback will be collected, aggregated, and posted on this page the week of November 28, 2016. Please let us know in your message if you do not want your feedback included in the publicly posted results.

Any and all feedback about Descriptions in CVE IDs is welcome, but in your response we ask that you please answer these three specific questions:

  1. Do you use or have a business need for Descriptions in CVE IDs as they exist today? If yes, can you explain the use or need? If not, would a CVE ID still be useful to you without the Description (i.e., an ID and one or more references)?
  2. Descriptions include information such as affected products and versions, affected components, attack types, attack vectors, and impact. Do you find all of this information equally valuable? If yes, what information is of most value and can you prioritize it? Is there any information that you would suggest CVE add or include when available (i.e., are Descriptions in CVE IDs missing anything)? Is there information included in a CVE Description that is not valuable to you? Why?
  3. What industry or community do you associate yourself with (e.g., government, vulnerability discloser, security product vendor, security product user, security industry, other)? This will help us identify how valuable descriptions are to CVE Program stakeholders.

We look forward to hearing from you!

- The CVE Team
November 3, 2016
cve@mitre.org

Page Last Updated or Reviewed: February 09, 2017