Business author and expert, H. James Harrington, once said, “If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.” He was right. And Google is following this advice by introducing a new way to strengthen open-source security by introducing a vulnerability interchange schema for describing vulnerabilities across open-source ecosystems.
That’s very important. One low-level problem is that there are many security vulnerability databases, there’s no standard interchange format. If you want to aggregate information from multiple databases you must handle each one completely separately. That’s a real waste of time and energy. At the very least you must create parsers for each database format to merge their data. All this makes systematic tracking of dependencies and collaboration between vulnerability databases much harder than it should be.
So, Google built on the work it’s already done on the Open Source Vulnerabilities (OSV) database and the OSS-Fuzz dataset of security vulnerabilities. The Google Open Source Security team, Go team, and the broader open-source community all helped create this simple vulnerability interchange schema. While working on the schema, they could communicate precise vulnerability data for hundreds of critical open-source projects.
Now the OSV and the schema has been expanded to several new key open-source ecosystems: Go, Rust, Python, and DWF. This expansion unites and aggregates their vulnerability databases. This gives developers a better way to track and remediate their security issues.
This new vulnerability schema aims to address some key problems with managing open-source vulnerabilities. It:
Enforces version specification that precisely matches naming and versioning schemes used in actual open-source package ecosystems. For instance, matching a vulnerability such as a CVE to a package name and set of versions in a package manager is difficult to do in an automated way using existing mechanisms such as CPEs. Can describe vulnerabilities in any open source ecosystem, while not requiring ecosystem-dependent logic to process them. Is easy to use by both automated systems and humans.
In short, as Abhishek Arya, the Google Open Source Security Team Manager, put in a note on the specification manuscript, “The intent is to create a simple schema format that contains precise vulnerability metadata, the necessary details needed to fix the bug and is a low burden on the resource-constrained open source ecosystem.”
The hope is that with this schema, developers can define a format that all vulnerability databases can export. Such a unified format would mean that programmers and security researchers can easily share tooling and vulnerability data across all open-source projects.
The vulnerability schema spec has gone through several iterations, but it’s not completed yet. Google and friends are inviting further feedback as it gets closer to being finalized. A number of public vulnerability databases today are already exporting this format, with more in the pipeline:
The OSV service has also aggregated all of these vulnerability databases, which are viewable at the project’s web UI. The databases can also be queried with a single command via its existing APIs.
In addition to OSV’s existing automation, Google has built more automation tools for vulnerability database maintenance and used these tools to bootstrap the community Python advisory database. This automation takes existing feeds, accurately matches them to packages, and generates entries containing precise, validated version ranges with minimal human intervention. Google plans to extend this tooling to other ecosystems for which there is no existing vulnerability database or little support for ongoing database maintenance.
This effort also aligns with the recent US Executive Order on Improving the Nation’s Cybersecurity, which emphasized the need to remove barriers to sharing threat information in order to strengthen national infrastructure. This expanded shared vulnerability database marks an important step toward creating a more secure open-source environment for all users.
Want to get involved? You should. This promises to make open-source software, no matter what your project, much easier to secure.
