[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
RE: CVE Current States
> 1. When we're ready, publicly document states, including a state
> transition diagram. A colleague of mine started one but it's not
> quite ready to share.
Great idea, and please share when ready. This also very much applies to
the other email in regards to how the REJECT state is used.
>> STATE:UNASSIGNED: A CVE that has never been RESERVED. The CVE master
>> list provides an error message in the case that someone >>attempts
>> to view this CVE ID.
> This is the default state, correct? This state should never appear
> in a CVE data record?
It would never appear in a record that is used, but my feeling was that
we should give it a name. As well, there may be an unseen use for it in
the future.
>> STATE:RESERVED: A CVE Identifier (CVE ID) is marked as "RESERVED"
>> when it has been reserved for use by a CVE Numbering Authority
>> >>(CNA) or security researcher, but the details of it are not yet
>> populated.
>> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-1253
>> STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to
>> a
>> CNA STATE_DETAIL:ASSIGNED - assigned to a vulnerability
> Are these finite state details? If reserved, must also be
> cna_allocated or assigned, state detail can't be empty?
My current opinion is that the state detail would be required, though
it raises the question of what happens when something doesn't fit.
Should we always have an "Other" state detail? Same for the following
comment. In regards to the state description being required, my current
thought would be no since it would be difficult to enforce the prose
around it. Open to thoughts on this for sure.
>> STATE:POPULATED: The CVE entry has been published with at least a
>> minimum amount of detail and at least one public reference.
>> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0002
>> STATE_DETAIL:N/A (I don't believe it would ever be needed)
>There is currently a PUBLIC state I think. Is populated replacing
>public?
I don't believe that we have used terms for this or the previous
UNASSIGNED. However, I believe there used to be a CVE status that
included public way back in the day (2004 being that last occurrence I
think). We should be fine using PUBLIC if that is what others feel has
been used and is more appropriate.
Chris
-----Original Message-----
From: Art Manion [mailto:amanion@cert.org]
Sent: Wednesday, June 14, 2017 11:09 AM
To: Coffin, Chris <ccoffin@mitre.org>; kseifried@redhat.com; Beverly
Finch <beverlyfinch@lenovo.com>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: CVE Current States
On 2017-06-14 10:25, Coffin, Chris wrote:
> Here is what I think we are driving to in this thread. We can discuss
> more on the call today if needed.
I won't make the call today, here's some input.
1. When we're ready, publicly document states, including a state
transition diagram. A colleague of mine started one but it's not quite
ready to share.
> STATE:UNASSIGNED: A CVE that has never been RESERVED. The CVE master
> list provides an error message in the case that someone attempts to
> view this CVE ID.
> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2001-10000
> STATE_DETAIL:N/A (I don't believe it would ever be needed)
This is the default state, correct? This state should never appear in
a CVE data record?
> STATE:RESERVED: A CVE Identifier (CVE ID) is marked as "RESERVED"
> when it has been reserved for use by a CVE Numbering Authority (CNA)
> or security researcher, but the details of it are not yet populated.
> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-1253
> STATE_DETAIL:CNA_ALLOCATED - Provided as part of a block request to a
> CNA STATE_DETAIL:ASSIGNED - assigned to a vulnerability
Are these finite state details? If reserved, must also be
cna_allocated or assigned, state detail can't be empty?
> STATE:REJECT: A CVE ID listed as "REJECT" is a CVE ID that is not
> accepted as a CVE ID. The reason a CVE ID is marked REJECT will most
> often be stated in the description of the CVE ID.
> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8784
> STATE_DETAIL:DUPLICATE_ASSIGNMENT
> STATE_DETAIL:DUPLICATE_RESERVATION
> STATE_DETAIL:DUPLICATE_TYPO_SEQ_OR_YEAR
> STATE_DETAIL:MIXED_ISSUES_OR_DUAL_USE
> STATE_DETAIL:MERGED
> STATE_DETAIL:WITHDRAWN
> STATE_DETAIL:EXPIRED
> STATE_DESCRIPTION: // probably the only STATE where this is required
Again, is state detail required?
If duplicate or merged, must description note the other IDs involved?
> STATE:POPULATED: The CVE entry has been published with at least a
> minimum amount of detail and at least one public reference.
> Example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0002
> STATE_DETAIL:N/A (I don't believe it would ever be needed)
There is currently a PUBLIC state I think. Is populated replacing
public?
Regards,
- Art