Open source software and software supply chain security risks continue to be a primary concern for developers and organizations. According to a 2022 study by electronic design and automation company Synopsys, 84% of open source software codebases contained at least one known vulnerability — a nearly 4% increase from last year — and 48% contained a high-risk vulnerability.
In response to the threats hidden in open source software, Google Cloud is making its Assured Open Source Software service for Java and Python ecosystems available to all at no cost. The free Assured OSS gives any organization access to Google-vetted codebase packages that Google uses in its workflows.
The move comes on the heels of Google Cloud’s decision to offer its Project Shield distributed denial-of-service (DDoS) defense to government sites, news and independent journalists, sites related to elections and voting and sites that cover human rights — a response to the rise in politically motivated DDoS attacks.
SEE: What DevSecOps means for securing the software lifecycle.
Assured OSS, a walled garden for open-source codebases
Google launched Assured OSS in May of 2022 in part to address the rapid growth in cyberattacks aimed at open source suppliers, according to Andy Chang, group product manager, security and privacy at Google. He cited industry sources reporting a 650% surge in software supply chain attacks in 2021, when the use of OSS increased dramatically.
He told TechRepublic that since the company first announced and launched Assured OSS, it intended that the service be able to meet DevSecOps teams and developers where they are today with the pipeline and tooling they already use and leverage daily.
“Software supply chain attacks targeting open source continue to increase. Secure ingest of open source packages is a widespread challenge for organizations and developers wherever they choose to build code,” he said. “Google is uniquely positioned to help in this area as we are a long time contributor, maintainer, user of open source software and have developed a robust set of technology, processes, security capabilities and controls.”
He articulated four key elements behind the increase in attacks:
- OSS proliferation
- The increasing pace of deployments, especially with the trend driving containers, microservices and an increasing number of cloud data services.
- Many attack vectors attacking all layers of the stack: hardware, infrastructure systems, operating systems, middleware, app services, APIs and — the most vulnerable point of entry — humans.
- Gaps in standardization around tooling needed to holistically manage the product cycle and in security and risk information (Figure A).
Figure A
Mike McGuire, senior software solutions manager at Synopsys, explained that Google has a direct interest in the open source community being as secure as possible.
“The open source community really is just that — a ‘community’ that best operates when its members don’t just take, but also contribute, and Google has always supported that with their actions,” he said. “Google clearly has many tools, processes and frameworks in place to ensure the integrity of their dependencies and development pipeline, so they are simply sharing the fruit of those efforts out to the broader community.”
He added that Google is working to build up their cloud-native application development platform, “And that platform is all the more valuable when using it means having to worry less about complicated software supply chain threats.”
Features of Assured OSS
Google said the code packages that are available as part of Google’s Assured OSS program:
- Are regularly scanned, analyzed, and fuzz-tested for vulnerabilities.
- Have corresponding enriched metadata incorporating Container/Artifact Analysis data.
- Are built with Cloud Build, including evidence of verifiable SLSA-compliance.
- Are verifiably signed by Google.
- Are distributed from an Artifact Registry secured and protected by Google.
Securing codebases from fuzz testing to SLSA compliance
Securing codebases means addressing potential ports of entry for attackers and also crash testing software for so-called corner cases, or weaknesses in unexpected areas.
McGuire said Google has rigorous standards when it comes to which packages they trust, and for those that they do, they are essentially endorsing them to the public and providing proof of their efforts in vetting these components.
“Assured OSS clearly provides value to organizations looking for guidance on which packages are trustworthy within the sprawling open source universe,” he said. “But it’s important that they also have the tools in place to keep problematic components from entering their development pipeline, as well as continuously monitor previously trustworthy components for any newly discovered issues.” (Figure B)
Figure B
Fuzz testing
Chang explained that fuzz testing, aka “fuzzing,” uses invalid, unexpected or random inputs to expose irregular behavior such as memory leaks, crashes or undocumented functionality.
Salsa for software
The SLSA — “supply chain levels for software artifacts,” pronounced “salsa” — framework adds a level of assurance to the software development lifecycle. “Today, software developers are challenged to make informed decisions about the external software they bring into their own systems,” said Chang. “Especially if it is owned and operated by a third party.”
He said SLSA formalizes the criteria around software supply chain integrity and helps businesses take incremental steps toward a more secure software supply chain by adding more security guidelines to address the most common threats across the landscape today.
“When software is provided at an assured and attested SLSA level, customers know upfront which risks have already been mitigated by the provider,” he explained.
“Simply put, SLSA is a framework introduced by Google that can be used to assess the security of both software packages and the development lifecycles that built and delivered them,” added McGuire. “As it pertains to Assured OSS, the packages that Google supports as part of this program have been built, evaluated and delivered in alignment with the SLSA standard, which aims to assure the community of the integrity of the packages,” he said.
Enriched metadata
According to Chang, enriched metadata that incorporates container analysis data is critical because, “The more you know about the open source software being used, the better choices DevSecOps teams have related to policy enforcement and risk.”
He offered examples of how customers can use enriched metadata with Assured OSS packages:
- Reviewing the provided lists of transitive dependencies to understand what else may be impacted.
- Reviewing the SLSA level to help guide the admission and guard rail policies they set for packages to progress in their pipeline.
- Reviewing the VEX — or vulnerability, exploitability and exchange — data to better understand which are the most impactful vulnerabilities in the open source components.
- Understanding the provided license file data so that customers can apply policies as needed to ensure they meet their internal open source program office policies.
Signatures for software
Like a signed check, the verifiable signing Assured OSS provides for both its binaries and metadata enable customers to easily verify that the binaries and metadata come from Google and have not been tampered with during distribution, according to Chang.
“In addition, because the metadata is signed, customers can have confidence that the details contained in the metadata — including how the package is built, the build steps, which build tools touched the code and which security scan tools were run on the code — are all as they were when Google created them,” he said.
SEE: DevSecOps is more than shifting left.
Focus on Java and Python packages
Google said the Assured OSS program will make it possible for organizations to get OSS packages from a vetted source and know what the software comprises because it includes Google’s software bill of materials, generally known as SBOMs. The company said the Assured OSS project includes 1,000 Java and Python packages and reduces the need for DevOps teams to establish and operate their own OSS security workflows.
“Using methods such as fuzz testing, and including metadata of container or artifact analysis results, serves to attest to the security efforts performed,” said McGuire. “As a matter of fact, being able to perform this type of security testing on dependencies, and provide this level of information, might be a sign of what’s to come in the near future for software producers, especially for those doing business in highly regulated industries.”
SEE: Why supply chain security should be part of your 2023 DevOps plan.
Massive growth in OSS, and OSS vulnerabilities
Synopsys’ 8th annual Open Source Security & Risk Analysis (OSSRA) report, based on 1,700 audits across 17 industries, found:
- 163% increase in use of OSS by the EdTech sector.
- 97% increase in OSS use by aerospace, aviation, automotive, transportation and logistics sectors, with a 232% increase in high-risk vulnerabilities.
- 74% growth in OSS use by the manufacturing and robotics sectors.
- 557% growth in high-risk vulnerabilities in the retail and eCommerce sector since 2019.
- 89% of the total code being open source, and a 130% increase in high-risk vulnerabilities in the same period.
- 31% of codebases are using open source with no discernable license or with customized licenses.