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

Re: Public availability of CMEX

On Fri, May 14, 1999 at 02:56:04PM -0400, Steven M. Christey wrote:
> 
> Elias said:
> 
> >If we are going to add candidate numbers as a reference it should be
> >in the CMX where it wont be available to the public.
> 
> Granted, I sputtered a bit when the topic of CMEX being public came up
> during Sunday's meeting, but I think that the CMEX (or at least a
> portion) may need to be public, or at least available to entities who
> are directly using the CVE (e.g. to produce mappings or to populate a
> database).  I don't think there's any sensitive data in CMEX (at this
> moment anyway) that needs to be private.

Its not any private information that may be a problem. Its the fact
that CMEX is becoming a vulnerability database which will compete with
other vulnerability dbs, which means those people are not as likely
to contribute or use the CVE.

> The creation or modification date is useful to anyone who's looking at
> how the CVE has changed over time.  The references can be a
> significant help to someone who's looking up a CVE name (maybe an "end
> user"), or someone who's doing a mapping.  The keywords don't have to
> be visible to the end user, but they would be utilized in any search.
> At least some portions of the thesaurus recognize the inconsistencies
> in terminology ("buffer overflow" and "buffer overrun" for example)
> and could serve "the public" in terms of standardizing on such
> terminology.  The category is not particularly useful to the end user,
> but helps the mapper understand the content decisions surrounding that
> entry.  Granted, CMEX won't be useful to the end user, but it will be
> useful to other entities besides the input forum members.
> 
> Another piece of CMEX information that's not in there yet, but will
> be, is the "status" of the vulnerability (e.g. if it's been rendered
> obsolete, a duplicate, merged into others, etc.).  This information
> definitely needs to be public since it appears we're agreed that we
> should never "delete" CVE vulnerabilities.
> 
> - Steve
> 

-- 
Aleph One / aleph1@underground.org
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01
Page Last Updated or Reviewed: May 22, 2007