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

Public availability of CMEX


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.

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
Page Last Updated or Reviewed: May 22, 2007