Common Vulnerability Reporting Framework updated
The Industry Consortium for Advancement of Security on the Internet (ICASI) announced Common Vulnerability Reporting Framework (CVRF), Version 1.1. Enhancements offer users a more comprehensive and flexible format, while reducing duplication and the possibility of errors.
CVRF is an XML-based framework that enables stakeholders across different organizations to share critical vulnerability-related information in an open and common machine-readable format.
CVRF replaces the many nonstandard reporting formats previously in use, thus speeding up information exchange and processing.
“CVRF 1.1 is a significant step forward in our efforts to broaden awareness of security vulnerabilities and simplify their reporting,” said Russell Smoak, president of ICASI and director and general manager of Security Research and Operations at Cisco Systems. “The new features and enhancements make CVRF both more user-friendly and more applicable to a broader set of requirements. We are grateful to the project team members who have worked so conscientiously to develop these additions and improvements.”
Key changes in CVRF 1.1 include:
- A completely revamped method for specifying products in a hierarchical manner, dubbed the “Product Tree,” has been created. It has been separated from the vulnerability section, which reduces the duplication of XML, and it is much more flexible, powerful, and machine readable
- The Product Tree supports the construction of logical groups to further cut down on redundant XML by allowing logical groups to be referenced using a single identifier
- When possible, a consistent type/value construct has been implemented across CVRF. Given that type is an enumerated list, this enables future updates or modifications without much change to CVRF parsers. Using a more generic construct also reduces the overall number of elements, by combining existing (similar) containers into one
- CVRF has been made less vendor-centric: it is now friendlier to the research and coordination community
- To ensure a consistent look and feel, many of the optional meta-containers that use a plural term as the top-level identifier (e.g., Threats) are now followed by a container that uses the singular version of the same identifier (e.g., Threat)
- More constraints ensure that it is harder to build invalid documents
- A better use of optional elements makes CVRF more flexible for different document producers
- Whenever possible, elements that were similar and existed in several areas of the document have been aligned (e.g., Note, Acknowledgement, Reference, etc.)