Google pushes bug databases to get on the same page for open-source security

Chocolate Factory proposes common interchange format for vulnerability data

Google on Thursday introduced a unified vulnerability schema for open source projects, continuing its current campaign to shore up the security of open source software.

A schema defines the structure of a database. It's a blueprint for the objects within the database and it informs how data can be queried and exchanged.

The as-yet-unnamed vulnerability interchange schema aspires to bridge gaps that make it difficult to connect current, fragmented vulnerability databases by providing a common interchange format. It aims to enforce software version specification in a way that matches the naming and versioning conventions that open source package ecosystems actually use.

As Google describes it, existing naming systems like the CPE Product Dictionary don't provide an easy way to automatically map a CVE vulnerability listing to a package name and a set of versions in a package manager.

"With this schema we hope to define a format that all vulnerability databases can export," explained software engineer Oliver Chang, and principal engineer Russ Cox, in a blog post provided to The Register in advance of publication.

"A unified format means that vulnerability databases, open source users, and security researchers can easily share tooling and consume vulnerabilities across all of open source."

In so doing, Google is trying to provide a more comprehensive view of vulnerabilities in open source than existing approaches and to promote faster remediation via automation – which is critical for responding to problems in a timely fashion.

The schema is currently defined thus:

{
        "id": string,
        "modified": string,
        "published": string,
        "withdrawn": string,
        "aliases": [ string ],
        "related": [ string ],
        "package": {
                "ecosystem": string,
                "name": string,
                "purl": string,
        },
        "summary": string,
        "details": string,
        "affects": [ {
                "ranges": [ {
                        "type": string,
                        "repo": string,
                        "introduced": string,
                        "fixed": string
                } ],
                "versions": [ string ]
        } ],
        "references": [ {
                "type": string,
                "url": string
        } ],
        "ecosystem_specific": { see spec },
        "database_specific": { see spec },
}

This is a JSON-based encoding format for database entries, which might be stored in different formats. The intention is not to mandate a single format but to standardize data exchange conventions.

Back in February, the tech giant released an Open Source Vulnerabilities (OSV) database to allow developers to query vulnerabilities in the open source frameworks, libraries, and projects that they use. Simultaneously, the biz proposed a framework dubbed “Know, Prevent, Fix” by which companies can take action to fix open source software flaws in a consistent, cohesive way.

In keeping with these goals, Google last week launched "SLSA," a software supply chain defense project.

Go, Rust, Python, DWF, and OSS-Fuzz now support the OSV format for vulnerability records. NPM, GitHub, and Ruby currently rely on different vulnerability record formats, but may choose to adapt.

The OSV service offers an aggregated view of these vulnerability databases, visible via its web interface or API.

Google's assorted security initiatives arrive in the wake of a series of serious attacks on the software supply chain and on US IT infrastructure. Chang and Cox note that the company's efforts align with the recent US Executive Order on Improving the Nation’s Cybersecurity, which called for improved sharing of threat data. ®