[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200208272258.SAA22923@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: Re: HP Full Disclosure Story
choose.a.lusername@...hmail.com said:
>Steven, instead of beating this draft to death at every possible
>opportunity, could you focus on the CVE database?
In the long term, better disclosure practices would produce better
vulnerability information, which would improve the quality of CVE.
For example, many CVE candidates may not receive enough votes to
become official entries, and one of the major reasons for this is the
lack of vendor acknowledgement. The primary causes of duplicate
issues in CVE are (a) lack of coordination between researcher and
vendor (where the researcher describes the attack, and the vendor
describes the vulnerability), or (b) vague vendor advisories or other
acknowledgment, which makes it difficult to know which issue was truly
fixed by the vendor.
Moving a little off topic...
>Have a section [in CVE] for "this weeks" candidates and "this weeks
>approved entries (i forget what its called). Thanks.
Each new CVE version has a report that states which candidates were
promoted to entries: http://cve.mitre.org/cve/versions/. CVE versions
are updated quarterly (which provides stability to content providers
who have to keep their mappings up-to-date, a resource-intensive
process).
The CVE Change Logs, offered by Purdue CERIAS, allows you to monitor
changes on a daily or monthly basis. See:
https://cassandra.cerias.purdue.edu/CVE_changes/
Finally, while many people try to use CVE as a vulnerability database,
it is not. Unfortunately, this can reduce its utility to those
people. See http://cve.mitre.org/about/faq.html#A5
- Steve
Powered by blists - more mailing lists