Google has released its repository of verified open source components

The paid Assured Open Source Software service will offer a repository of open source packages whose code and dependencies have been previously verified.

To address the concerns of developers concerned about the security of the open source software supply chain on which they rely heavily, Google plans to make its own repository of secure open source components available through a paid service. Called Assured Open Source Software (Assured OSS), this service offers standard open source packages built from source code in which the source code and its dependencies are verified, and reviewed and tested for weaknesses. The resulting packages will contain rich metadata, in accordance with the recent SLSA framework (Supply chain Levels for Software Artifacts), and digitally signed by Google.

According to Eric Brewer, vice president of infrastructure at Google Cloud, the company already has several tested open source components for its own development pipeline, so the foundations for the Assured OSS service are already in place. Announced yesterday, it will initially only be available in trial form for select customers and is expected to enter the public beta phase in Q3 2022. Pricing has not yet been decided, but this paid service could ease costs. infrastructure associated with developing and hosting security packages and testing, which includes automated fuzz testing with more than 100,000 cores. Initially, the service will offer a series of approximately 500 Java and Python packages used by Google, but it will be expanded to other programming languages. Customers will also be able to submit any open source building blocks that rely on them to be added and managed through the repository and given the same security guarantee as current packages.

Manage the maintenance of software components locally

Google’s strategy is what all software development companies should do to avoid certain risks in the supply chain, such as keeping local copies of the components they use in their local storage. instead of retrieving them directly from public repositories. This skill will allow them to have a buffer in case one of the packages or its dependencies is compromised and poisoned by malicious code. However, it can also cause patching delays if not managed properly, as internal versions of packages can become obsolete if upstream security patches are not regularly included.

That’s not always easy, if those security patches only affect the latest releases that also bring major feature changes that can damage apps and require significant re-engineering effort. For some time, several studies have shown that enterprise applications use old and weak versions of open-source components in their applications. This is the case, for example, with the critical and highly publicized vulnerability in Log4Shell, which was discovered in December in the widely used Java logging library log4j. Three months later, nearly 40% of log4j2 downloads from the Maven Central repository still delivered vulnerable versions of the library.

Fixes for older versions of open source code

Google plans to fix some of these issues by reverting security fixes to older versions of affected packages, even if the original maintainer doesn’t. “If the package owner made a drastic change to a new release, it wouldn’t be easy for most users to use,” Brewer explains. “In this type of situation, security fixes that can be made to the old version used as well as to the latest version that will be better used in the future, may be of some importance”, he added. That said, there will always be a delay between the release of the recent version and when a verified copy signed by Google is available in the Assured OSS repository, simply because it takes a few hours to run the tests. security modification and code analysis. But Eric Brewer hopes the lag will be shorter and shorter because the process is automated. “It’s part of the service, because it doesn’t provide upstream copy,” he said. “This copy includes some latency and revision, and in some cases the latency can be significant, because we’re not sure what the latest version is. Conversely, if it’s a minimal security patch, we’ll probably try to choose the one with the lowest latency. “

But this process is a two-way street, as Google’s development teams and vulnerability researchers regularly find security flaws in open-source software and make patches for them. In this case, the version of a Google package may receive patches for an internally detected vulnerability prior to official release, as it usually takes some time to receive upstream project patches. Google is one of the largest contributors to open source software projects and its researchers have discovered more than 16,000 vulnerabilities so far. Additionally, Google will partner with security firm developer Snyk. In particular, Assured OSS will be integrated into Snyk’s platform and tools, as well as vendor vulnerability intelligence. Triggered actions and remediation recommendations will be available to joint customers in the Google Cloud software development lifecycle tools.

Leave a Comment