There are many problems to solve industry-wide concerning vulnerability detection, tracking, and response. One low-level problem is that there are many databases and no standard interchange format.

A client that wants to aggregate information from multiple databases must handle each database completely separately. Databases that want to exchange information with each other must also each have their own parser for each format. Systematic tracking of dependencies and collaboration between vulnerability database efforts is hampered by not having a common interchange format.

This document defines a draft of a standard interchange format, as yet unnamed. We hope to define a format that all vulnerability databases can export, to make it easier for users, security researchers, and any other efforts to consume all available databases. Use of this format would also make it easier for the databases themselves to share or cross-check information.

This shared interchange format is not expected to be the internal format for any particular database. We hope only that every vulnerability database will make its entries available in this format to enable interoperability.

Goal: Standard Schema for Vulnerability Databases

Infrastructure and industry standards are needed to track and maintain open source vulnerabilities, understand their consequences, and manage their mitigations. A standard vulnerability schema would allow common tools to work across multiple vulnerability databases and simplify the task of tracking, especially when vulnerabilities touch multiple languages or subsystems.

It was a non-goal to unify the entries in different existing databases into a single entry for a particular vulnerability.

The open issues that remain seem to be pushing toward a new use case, which is to be able to unify the entries in different existing databases into a single entry (for a particular vulnerability). That was a non-goal: the assumption is that there will always be multiple databases, because at the least each ecosystem will have its own database with its own custom metadata that doesn’t really make sense to other databases.

Thank you to all the open source developers who have provided feedback and adopted this format. We’re continuing to work with open source communities to develop this further and earn more widespread adoption in all ecosystems.