Securing the software development lifecycle with Cloud Build and SLSA

One of the biggest challenges for software developers is the need to make informed choices about the external software and products they use in their own software systems. Evaluating whether a given system is appropriately secured can be challenging, especially if it’s external or owned by a third party.

This so-called software supply chain has been under increasing scrutiny in recent years, with attacks on software systems being responsible for damages to both public and private interests. In collaboration with the OpenSSF, Google has proposed Supply-chain Levels for Software Artifacts (SLSA). The new SLSA framework formalizes criteria around software supply chain integrity, to help the industry and open-source ecosystem secure the software development lifecycle.

Secure your own software development lifecycle

SLSA is not just for the public software supply chain. You can also apply these same levels, originally inspired by Google’s internal framework for secure software delivery, to your own software development life cycle.

Each level of SLSA represents an incremental step towards a more secure software supply chain, adding additional security guidelines to address the most common threats to source and build integrity. Nor are these guidelines Google-specific: they are developed by the security extended community and established by consensus to be adopted amongst the wider industry.

Although SLSA is a new framework, many of the security guidelines it advocates for are already available for and adopted by consumers today.

Understanding SLSA

The SLSA framework introduces a number of new tools and concepts for securing the software development lifecycle:

• Artifact - any file produced as the result of a build pipeline, such as container images, language packages, compiled binaries, etc.

• Provenance - metadata about how an artifact was built, including the build process, top-level source, and dependencies

• Digest - the result of a cryptographic hash function which produces a fixed-size value uniquely identifying an artifact, such as a SHA-256 hash of a container image

• Attestation - a cryptographically signed file recording the provenance of the build pipeline at the time a specific artifact or set of artifacts was produced

• Attestor - any system or process that produces an attestation, often included as part of a build pipeline after artifact creation and prior to deployment

• Immutable references - an identifier, such as a URL, that is guaranteed to always point to the same, immutable artifact, such as a specific container image or language package

• Build integrity - the verification of the output of a build pipeline via attestations

When used in combination, these represent a build pipeline that adheres to the standards set by the SLSA framework.

Cloud Build supports SLSA 1

If you use Cloud Build, Google Cloud’s hosted CI/CD platform, you are likely already operating a software development lifecycle at SLSA 1, the first step in securing your software delivery pipeline. That’s because by default, Cloud Build allows you to create an automated build pipeline, and because any Cloud Build pipeline automatically generates provenance. While provenance for Cloud Build has been available for quite some time, it hasn’t been widely used to verify build pipelines.

Having a software supply chain at SLSA 1 does not entirely protect against tampering, but it does offer a basic level of code source identification and may aid in vulnerability management, protecting against software delivery that is not a product of the CI/CD system. At the same time, Cloud Build represents a foundation for a hosted software build system upon which you can reach higher SLSA levels, using techniques like verifiable source control, automatically verified provenance, and tools like Binary Authorization.   

You can start now

By creating a build process that’s fully automated, mandating the use of a build system for production workflows, and by building your software pipeline with Cloud Build, you can have a SLSA 1 supply chain right from the start. 

To get started today, you can follow the Cloud Build quickstart for building a Docker image and pushing the image to Artifact Registry, followed by the quickstart for deploying that containerized application to Cloud Run.

For more details on SLSA, you can read more here:

• SLSA: Supply-chain Levels for Software Artifacts
• Introducing SLSA, an End-to-End Framework for Supply Chain Integrity

Want to learn more about how you as a developer can help improve the security of your software? Today, we’re hosting Building trust in your software supply chain, which explores this topic in depth. Click here to register for the live event or to watch it on demand.