Google extends open source vulnerabilities database to Python, Rust, Go, and DWF

Google today announced that it has extended its Open Source Vulnerabilities (OSV) database to incorporate data from additional open source projects, using a unified schema “for describing vulnerabilities precisely.”

The benefits of open source software are widely understood, but vulnerabilities is one concern that frequently rears its head. The vast majority of codebases contain at least one known open source vulnerability, while a report this week concluded that more often that not, developers don’t update third-party libraries after including them in their software. That same report also noted that 92% of open source library flaws could be easily fixed with a simple update.

Open source software impacts pretty much everyone, everywhere — small startups all the way through to major enterprises rely on community-driven components in most of their applications. Thus, it is in everyone’s interests to ensure that open source software is properly maintained.

Vulnerability triage

Back in February, Google launched the Open Source Vulnerabilities database, which it said was its “first step towards improving vulnerability triage” for developers and other open source consumers. Vulnerability triage is the process of assessing and ranking known flaws in software components in order of the risk they pose to an application that uses it.

The OSV serves data on where a vulnerability first emerged and where it got fixed, so that developers can better understand how they are impacted. At launch, the OSV included data from “fuzzing” (a technique to find software programming errors) vulnerabilities gleaned from the Google-led OSS-Fuzz service, which integrates with hundreds of open source projects.

Today Google is extending OSV to include vulnerability databases from major open source projects including Python, Rust, Go, and DWF.

One of the major challenges of aggregating data from multiple open source databases is that they often adhere to different formats, often created uniquely by an individual organization.  This distributed model makes it more difficult to unify and describe vulnerabilities in a common vernacular. Thus Google, in conjunction with the wider open source community, have been working on a “vulnerability interchange schema” to describe vulnerabilities across open source projects in a format that can be used by both humans and automation tools.

Given that collaboration is the core tenet of open source software, to expand the OSV to include other open source ecosystems required active participation from all maintainers involved.

“Their feedback helped to iterate, improve and generalize the format,” Google software engineer Oliver Chang told VentureBeat. “After the format was in stable state, they made some changes in their existing vulnerability data sets to match the OSV schema format. This allowed aggregation of their data sets in the OSV service, which anyone could use to query for vulnerabilities in their open source dependencies.”

Doubling down

Google has seemingly doubled down on its open source security investments of late. Last week it proposed a new “end-to-end framework for supply chain integrity” called Supply Chain Levels for Software Artifacts (SLSA), which designates security certification levels to different software packages. The internet giant was also a founding member of a new Linux Foundation project called Sigstore, which is setting out to help software developers confirm the origin and authenticity of software. And back in February, Google revealed it would underwrite the salaries of two Linux Kernel developers to help improve security.

With Google still awaiting further feedback from the open source community, the new vulnerability schema specification is not yet finalized. However, OSS-Fuzz, Python, Rust, Go, and DWF are all now exporting this format, and the OSV has combined all these vulnerability databases into a public portal, which can also be queried using a single command via the existing APIs.