Google Shares Format for Open Source Vulnerability Data
Google, in collaboration with several open source communities, today unveiled a schema for describing vulnerabilities in open source software that will make it easier to for developers to track security issues that impact their applications.
Dan Lorenc, a staff software engineer for Google, said the vulnerability interchange schema defines a standard format that all vulnerability databases can export. Ultimately, the goal is to make it easier for developers to be made aware of vulnerability issues in addition to laying a foundation upon which remediation of those issues can be more easily automated, added Lorenc.
The format will make it simpler to enforce version specifications that precisely matche naming and versioning schemes used in actual open source package ecosystems. Matching a vulnerability to a package name and set of versions in a package manager is difficult to automate without having a standard format for describing vulnerabilities, noted Lorenc.
Public vulnerability databases today that already support the new format include:
- Go vulnerability database for Go packages
- Rust advisory database for Cargo packages
- Python advisory database for PyPI packages
- DWF database for vulnerabilities in the Linux kernel and other popular software
- OSS-Fuzz database for vulnerabilities in C/C++ software found by OSS-Fuzz
Google also revealed today it has aggregated all those vulnerability databases within an Open Source Vulnerabilities (OSV) database it made available earlier this year. That database can be accessed via a user interface or programmatically via a set of application programming interfaces (APIs) that Google has exposed.
The vulnerability schema specification has already gone through several iterations, but Lorenc said Google is continuing to invite further feedback as the specification gets finalized.
One of the reasons so many known open source software vulnerabilities are not remediated in production environments comes down to the inability to determine what subset of code taken from a given project has actually been packaged in an application. In fact, some security alerts are ignored by developers, as they are not always sure whether the subset of code they might have employed is actually impacted by a newly discovered vulnerability.
Lorenc said a standard format, combined with the OSV database, and other initiatives seeking to standardize, for example, the way a software bill of materials (SBOM) describes the elements of a software package, will go a long way to address growing concerns over software supply chains that have emerged in the wake of some recent high-profile breaches.
Of course, developers, in theory, are assuming more responsibility for securing applications as part of an overall shift left of control over IT environments. The issue is that most developers don’t yet have much cybersecurity expertise, much less the tooling required to remediate applications after they have been deployed in a production environment. Unless they are assigned to remediate a specific vulnerability that has been packaged within a specific subset of an application, it’s challenging to determine what to prioritize. That’s especially problematic when the people that hire those developers ask them to focus their time on building more applications rather than removing vulnerabilities from software that has already been deployed.
One way or another, however, more attention is being paid to application security now that the Biden administration has recognized how much of a threat to national security the issue has become.
