Developers across the enterprise space are concerned about the security of the open-source software supply chain which they heavily depend on for their application development. In response, Google plans to make its own security-hardened internal open-source component repository available as a new paid service called Assured Open Source Software (Assured OSS).
The service will contain common open-source packages that have been built from source code after the code’s provenance and that of its dependencies has been vetted and the code has been reviewed and tested for vulnerabilities. The resulting packages will contain rich metadata that’s compliant with the new Supply chain Levels for Software Artifacts (SLSA) framework and will be digitally signed by Google.
According to Eric Brewer, Google Cloud’s vice president of infrastructure, the company already maintains its own internal security-tested versions of many open-source packages for its own software development pipeline, so the basics for the new service were already there.
Announced today, the new service will only be available to select customers for early access testing and is expected to enter a public preview stage in Q3 2022. Pricing is not yet decided, though it will be a paid service to offload the infrastructure costs associated with building and hosting the packages as well as the security testing, which includes automated fuzz-testing with over 100,000 cores.
The service will start out with a collection of around 500 Java and Python packages that Google uses, but it will be expanded in the future to cover other programming languages. Customers will also be able to submit any open-source packages they rely on to be added and managed through the repository and receive the same security assurance treatment as the existing ones.
Maintaining local software components not easy
Google’s approach is what all organizations that develop software should be doing already to address some of the supply-chain risks, which are to maintain local copies of the components they use in their local repositories instead of pulling them directly from the public repositories. This would give them a buffer in case one of the packages or its dependencies is compromised and poisoned with malicious code.
However, this practice can also lead to patching delays if not managed properly, as the internal package versions can become stale if upstream security fixes are not regularly pulled in. This is not always easy if those security patches are only included in new versions that also come with major functionality changes that could break applications and require significant reengineering efforts.
Many studies have found over the years that enterprise applications use outdated and vulnerable versions of open-source components in their applications. Take, for example, the critical and highly publicized Log4Shell vulnerability that was discovered in December in the widely used log4j Java logging library. Three months later, almost 40% of log4j2 downloads from the Maven Central repository continued to be for vulnerable versions of the library.
Patching older open-source code versions
Google plans to address some of those issues by backporting security patches to older versions of affected packages even if the original maintainer doesn’t do it.
“When a package owner makes a breaking change, for a new version, I think it is not that easy for most consumers to just adopt,” Brewer tells CSO. “And in those cases, it would probably be important to make security patches both to the old version that we use and the new version that is the preferred version going forward.”
That said, there will be a delay between when a new version is released and when a Google-audited and signed copy of it appears in the Assured OSS repository. That’s because it takes some time to do the security testing and review the code changes, but Brewer says he hopes this time window will get shorter and shorter as more of the process gets automated.
“This is part of the service, as you’re not getting the upstream copy,” he said. “You’re getting it with some latency and some review and, in some cases it might be noticeable latency because we are unsure about the new version. Conversely, if it’s a security patch, and it’s small, we will probably try to pick that one with low latency.”
But this is a two-way street, as Google’s development teams and vulnerability researchers regularly find security vulnerabilities in open-source software and create patches for them. In such cases, Google’s version of a package might get patches for an internally discovered vulnerability earlier than the official versions, as it usually takes some time to get the patches accepted by the upstream project. Google is one of the largest contributors to open-source projects and its researchers have already uncovered over 16,000 vulnerabilities until now.
In addition, Google will partner with developer-security firm Snyk, where Assured OSS will be integrated into Snyk’s platform and tools and Snyk’s vulnerability intelligence. Triggered actions and remediation recommendations will become available to joint customers in Google Cloud software development life cycle tools.
Copyright © 2022 IDG Communications, Inc.
