[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CVE numbering

I agree, too.
As the owner of a vulnerability database, I don't really care what the numbers are, except for 2 criteria:
1) they should not change once assigned.
2) Having them only increase (and not go back and "fill in") after a certain "release" point in time makes it easier to compare lists and add only new entries to my own database.  

The CVE would be something entirely internal to most of our databases, and should carry as little meaning as possible.  Chronology, grouping by categories, etc. are things that each CVE user can assign.  

Andy

At 02:46 PM 5/4/99 -0700, Huger, Alfred wrote:
>
>
>
>> - 'Reserving' arbitrary blocks of numbers for backfill or middlefill.
>> - Difficult to insert CVE indexes in the event that some information
>> source
>> is unearthed in the future.
>> - Adds little or no value as to the relative time of discovery, as in the
>> example where one knowledge base reports the discovery date as several
>> months different from another site.
>> - May require reindexing at a future date, thereby requiring version
>> control
>> and violating the integrity of the index numbers (CVE-1 may not always be
>> CVE-1).
>> - May delay entry of information pending authoritative determination of
>> discovery date.
>> 
>> 
>> 
>	I would have to agree with Andre, given this is a post-event effort
>it makes more sense to apply the numbers in the current format with the
>given disclaimers Andre mentioned. The value (at least where Scanner
>customers are concerned) is not to chronologically arrange the
>vulnerabilities but to properly categorize them to help people get a better
>handle on what a given product checks for. 
>
>	This IMO will help alleviate the 'check magic' or creative math that
>vendors are applying to their vulnerability counts in their Scanner or ID
>products. Note, I am not pointing fingers, it is my opinion that we *all* do
>it to some degree or another.
>
>	-Al Huger
>
>
Page Last Updated or Reviewed: May 22, 2007