Google and the Linux Foundation separately debuted new tools to improve supply chain security, with a specific focus on open source software, as federal agencies work on software-related standards and guidelines called for in President Biden’s recent cybersecurity executive order.

Google launched Supply chain Levels for Software Artifacts or SLSA, pronounced “salsa.” It’s a framework for ensuring the integrity of software artifacts throughout the software supply chain. The cloud giant also included SLSA in its proposed recommendations to the National Institute of Standards and Technology (NIST), which called on organizations to submit solutions for boosting supply chain security.

Additionally, the Linux Foundation rolled out software bill of materials (SBOM) tools and training as it pushes its open source Software Package Data Exchange (SPDX) project as the de-facto open standard for communicating SBOM information including open source software components, licenses, and known security vulnerabilities.

The National Telecommunications and Information Administration (NTIA) also recently asked for feedback as it works to define a minimum SBOM, per Biden’s executive order. And the Linux Foundation, in its NTIA submission, highlighted how the SPDX project — which major corporations including Sony, Intel, Volkswagen, Snyk, and Synopsys already used and currently is in the final stages of review to be an ISO standard — already meets the requirements of the executive order for SBOMs.

An SBOM is a list of all the components, libraries, and modules that are required to build a piece of software. It includes both closed and open source code, and details the supply chain relationships between the components to enable software transparency and security analysis.

“About 90% of a product today is built on open source, so if we don’t solve the problem for open source, it’s too heavy a lift for the commercial vendors and they’re going to react,” said Kate Stewart, VP of dependable embedded systems at the Linux Foundation.

SBOMs in general and SPDX specifically accounts for the open source software components contained in an application and details their quality, license, and security attributes. This makes it easier for developers and commercial vendors to know what comprises their software supply chains and proactively identify issues and risks.

“When you’ve got this huge, long list of dependency trees, which is what most modern software is about, you can see ones you immediately depend on, but the ones that they depend on, and then the ones that the lower ones depend — these huge chains emerge when you start off tracking it all back,” Stewart said. “And most of that huge chain is open source projects.”

An SBOM makes it “very easy to see” these dependencies “for a project at a point in time, and then how it’s interacting with other projects,” she added.

Developers from hundreds of companies have contributed to SPDX over the past decade, and the Linux Foundation says it is the “most robust, mature, and adopted SBOM in the market today.” This “software list of ingredients” also includes tracking timestamps, which ensures developers use the latest version of the code, as well as data licenses in metadata.

Also this week, the Linux Foundation released the SPDX SBOM generator, which uses a command-line interface (CLI) to generate SBOM information including components, licenses, copyrights, and security references of an application using SPDX v2.2 specification and aligning with the current known minimum elements from NTIA. Currently, the CLI supports GoMod (go), Cargo (Rust), Composer (PHP), DotNet (.NET), Maven (Java), NPM (Node.js), Yarn (Node.js), PIP (Python), Pipenv (Python), and Gems (Ruby).

Developers can embed it in automated processes such as continuous integration (CI) pipelines, and it is available for Windows, macOS, and Linux.

Additionally, the foundation will offer a free online training course on how to generate an SBOM. And next week the Linux Foundation will conduct an SBOM Readiness Survey with questions address tooling, security measures, and industries leading in producing and consuming SBOMs, among other topics. The Linux Foundation will use information gleaned from the survey to develop future SBOM training.

Google this week also ramped up its supply chain security efforts in what Stewart described as “complimentary” to SBOM efforts. “It’s a very promising piece of technology, and it’s being looked at quite seriously,” she said about Google’s SLSA.

Google, a founding member of the Linux Foundation’s Open Source Security Foundation (OpenSSF), based its SLSA efforts on its internal Binary Authorization for Borg, which has been in use for the past eight years and is mandatory for all of Google's production workloads.

“It is largely inspired by what we do internally at Google to help prevent insider-risk type attacks, and to give us a way to audit the supply chain within our internal workflow. So what SLSA is: It’s a leveling system where each incremental level gives you more trustworthiness for the software artifacts” throughout the supply chain, said Kim Lewandowski, Google Open Source Security Team project manager. Lewandowski also helped develop Google’s open source Tekton project.

With SLSA, Google aims to “take some of our ideas and our inspiration and try to push it out there and work with the industry together on this to give us a framework to then talk about supply chain integrity,” she added. “Because no one can really solve this problem by themselves. We need to lift the entire industry up to higher security standards.”

This has become especially urgent lately in light of major supply chain attacks such as SolarWinds.

In a blog post about SLSA, Lewandowski details eight different threats — for example, a compromised build platform like with the SolarWinds breach — and how the SLSA framework could have prevented them, or at least made them a lot more difficult for attackers to exploit.

Currently, SLSA consists of four levels of adoptable security guidelines with SLSA 4 being the highest level of security. The lower levels represent incremental milestones and integrity guarantees.

“In its final form, SLSA will differ from a list of best practices in its enforceability. It will support the automatic creation of auditable metadata that can be fed into policy engines to give ‘SLSA certification’ to a particular package or build platform,” the blog explains.

Google also released a proof of concept for SLSA 1 provenance generator. The company hopes that the larger community will contribute to SLSA, and one way to do so is to join the SLSA discussions happening in the OpenSSF Digital Identity Attestation Working Group.

“The end goal is if we can get wide adoption of SLSA levels, then we all will have this industry understanding of what is the security posture for the these different software artifacts along the supply chain and how they were produced,” Lewandowski said.