Publication of CVE in CVRF Format

All,

The Common Vulnerability Reporting Framework (CVRF, www.icasi.org/cvrf) version 1.1 was released back in May 2012, with significant improvements compared to the previous version.  We have been requested to publish CVE in CVRF format, and we have finished 90% of the implementation to do this (mostly during “down time” in long meetings where heavy-thinking CVE content production was not feasible ;-)

Over the past 10 years or so, there have been several attempts to provide a common, machine-parseable advisory format, but none of the proposals were widely adopted.  However, CVRF is supported by some major vendors, including Red Hat, Cisco, Oracle, and Microsoft.  And this isn't just lip service or “plans” to adopt in the future – most or all of these vendors publish their advisories in CVRF format today.

For CVE content production, we scrape many web pages for advisory information, and these web changes can change, forcing us to make frequent code changes to our parsers.  Encouraging the use of CVRF will ultimately help CVE (and many other vulnerability information consumers) to reduce the effort needed to support the wide variety of advisory formats that are currently in use.  For example, at SOURCE Boston a couple years ago, I heard a person from a major Internet company complain about all the time that was lost trying to collate advisories from diverse sources.

In addition, various features of CVRF indirectly encourage an advisory structure that can simplify CVE analysis.  For example, many custom-built advisories do not clearly delineate multiple vulnerabilities, or they do not clearly specify which CVE goes with which vulnerability, which can contribute to errors or omissions due to poor formatting.  Thus, more widespread adoption of CVRF could further improve the actual quality of some advisories, benefiting the general public and not just CVE.

And while we don't know where the upcoming GVR discussions will head in the coming years, it seems likely that if truly global vulnerability information sharing takes place, there will be a greater need for a common format to facilitate sharing.

So, we believe that the time has come for CVE to support CVRF - to make it easier for CVE consumers to access CVE content instead of having to learn our custom format, to ultimately make our own analytical work easier and more efficient, and to further encourage others in the security community to pursue machine-readable vulnerability information sharing.

We still have some work to do, such as updating the web site and preparing an announcement, but the underlying technical implementation is nearly ready, and all of our CVE output validates properly (with enough memory, good ol’ XML ;-))  We plan to roll out the CVRF format and make a formal public announcement soon, maybe in late November.  We will still support the current formats and may consider additional formats in the future.

If anybody who speaks CVRF wants to help beta-test our CVE outputs, please let me know.

Thanks,

Steve