Google launches dependency API and curated package repository with security metadata

This week, Google launched a free API service that provides software developers with dependency data and security-related information on over 5 million software components across different programming languages. Today, the company also announced the general availability of its Assured Open Source Software (Assured OSS) service, which provides development teams with a Google-curated repository of security-tested packages for Python and Java.

Both services are part of Google’s efforts to reduce the software supply chain risks that exist in the open-source ecosystem by providing extensive security metadata, vulnerability information, and the needed information to build software bills of materials (SBOMs). One of the most common ways in which attackers can introduce malicious code into software projects is by compromising a popular open-source component or one of its many dependencies.

Transitive vulnerabilities inherited from dependencies are also a major problem, as many of them are not even unaccounted for if development teams don’t have good tools to track software advisories in indirect dependencies — multiple layers down in the dependency chain.

Google’s free deps.dev API

Google’s Open Source Insights team has collected security metadata from multiple sources for 5 million packages with 50 million versions found in the Go, Maven (Java), PyPI (Python), npm (JavaScript), and Cargo (Rust) public registries. Support for NuGet (.NET framework) packages is also planned.

The collected metadata includes transitive dependency graphs, license information, security advisory impact reports, and OpenSSF Security Scorecard information. This data is now organized as a BigQuery dataset and is made available for querying and analysis for free through the deps.dev API.

For example, by using this API developers can answer questions like: Which versions are available for a specific package? Which software licenses a particular version uses? How many dependencies does a package have and what are they? What packages and what versions does a particular file correspond to? This can help developers make better informed decisions when assessing risk associated with a package or version they consider consuming as part of their project.

The new API has already been integrated into Graph for Understanding Artifact Composition (GUAC) an open-source tool for building SBOMs, but Google expects more integrations in the future. For example, as a plugin for integrated development environments (IDEs) the API can make dependency and security information immediately available for developers. However, it could also be integrated into CI/CD frameworks to prevent rolling out vulnerable code, into build tools and policy engines for compliance reasons, post-release analysis tools to detect newly reported vulnerabilities in existing code bases, software inventory management tools that can help identify mystery files, and visualization tools to get a better understanding and view of a software program’s dependency graph.

Vulnerabilities like Log4Shell, a critical flaw in the Java log4j component, showed how fragile the software ecosystem is. Many software companies and development teams found themselves slow to determine if their products were affected or not, because while log4j might not have been a direct dependency for their software, it might have been an indirect one — statically included in some other package they used.

In such cases deps.dev API integration could be very useful. For example, the API supports searching by file hash to see which version of a package it belongs to and whether it’s affected by a known vulnerability. A CI/CD tool using the API could immediately alert that a known vulnerability affects the codebase and a visualization tool could rely on the API to show a dependency graph which could indicate which direct dependency has the vulnerable log4j file and initiate efforts to contact that package maintainer to ask for or to contribute a fast patch.

To understand how pervasive and serious the issue of transitive vulnerabilities is, almost one year after Log4Shell was discovered and was widely covered across tech communities, 72% of organizations still had assets vulnerable to it and the number of exploitation attempts for the flaw remained high. One reason was because it wasn’t just log4j directly that was impacted and required a patch. The vulnerable Java class called JndiManager included in Log4j-core was borrowed by 783 other projects and is now found in over 19,000 software components.

The deps.dev API service is globally replicated and highly available using Google’s cloud infrastructure. It is free to use and does not require authentication or an API key. Developers can simply issue API queries over HTTPS and receive query responses formatted as JSON objects.

“Software supply chain security is hard, but it’s in all our interests to make it easier,” members of the Google Open Source Security Team said in a blog post. “Every day, Google works hard to create a safer internet, and we’re proud to be releasing this API to help do just that and make this data universally accessible and useful to everyone.”

Assured OSS at no cost

In addition to the deps.dev API, Google announced the general availability of its Assured OSS service. This is essentially a repository for over 1,000 of the most popular Java and Python packages whose provenance has been verified and that were security tested by Google’s own teams. This service was originally launched in public preview a year ago.

“Available today at no cost, Assured OSS gives any organization that uses open-source software the opportunity to leverage the security and experience Google applies to open-source dependencies by incorporating the same OSS packages that Google secures and uses into their own developer workflows,” Andy Chang, group product manager for security and privacy at Google Cloud, said in a blog post.

All the packages hosted in this repository are compliant with the Supply-chain Levels for Software Artifacts (SLSA) framework and provides three levels of assurance:

• Level 1, built and signed by Google
• Level 2, securely built from vetted sources and attested to all transitive dependencies
• Level 3, including transitive closure of all dependencies and continuously scanned and fuzzed

Packages receive regular vulnerability scanning, analysis and fuzz testing and include data from the Open-Source Vulnerabilities (OSV) database. Package artifacts are also signed and are distributed from a Google-maintained and secured repository. Finally, each package comes with SBOMs and metadata from Cloud Build, Artifact Analysis, package health, and vulnerability impact data in multiple standard formats to be consumed by different tools.

In addition to security testing, Google has a patching team that will quickly patch security issues identified in packages including backporting those patches to older versions that the original maintainer doesn’t support. “There are significant security benefits to Assured OSS adopters and the larger community from the curation process,” Chang said. “Since our Assured OSS team curated the first 278 packages, we have been the first to find 48% of the new vulnerabilities (CVE) — each of these CVEs has been fixed and upstreamed.”

Maintaining copies of commonly used packages inside local repositories instead of always pulling them from public repositories is a practice that many companies engage in. In theory this provides a buffer in case the public version of a popular package is compromised and has malicious code injected into it. However, it could also delay the adoption of security patches. Many studies have shown over the years that organizations commonly use outdated and vulnerable versions of open-source components in their applications.

Google’s Assured OSS aims to address some of the drawbacks of maintaining a private repository by employing a dedicated team of experienced security professionals to manage it and ensure the security quality of the packages inside, which most companies can’t afford to do in house.