CVE Blog

The purpose of this blog is to establish a dialogue and get your input on issues and topics important to CVE. Right-click and copy a URL to share a post.

Please use our LinkedIn page, or the CVE Request Web Form by selecting “Other” from the dropdown, to comment on the post below.


What's your opinion on updating CVE ID Descriptions?

Comment on LinkedIn | Share this post

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 contact us through the CVE Request Web Form by selecting “Other” from the dropdown 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 Request Web Form
(select “Other” from dropdown)

Recent Posts

Page Last Updated or Reviewed: August 24, 2020