Introducing SLSA 1.0: Securing the Code You Import & Build

Supply chain Levels for Software Artifacts (SLSA) is an emerging Secure Software Development Framework (SSDF), which can help ensure that all the code you import into your organization and/or build within your organization is done in a secure manner. As such, SLSA is a key linchpin within any organization’s journey toward securing their software supply chain. 

The SLSA specification will hit the 1.0 milestone this month, with community feedback closing on March 24 and the specification set for release by end of month. 

But why should you care? After all, there are multiple SSDFs out there that are far more mature, and adopting anything “1.0” is always inherently risky. But there are some key reasons to consider SLSA, including:

• Verifiable Controls – traditional SSDFs focus on standards and best practices, and SLSA is no different here. But SLSA also generates verifiable controls that prevent tampering with, and ensure the integrity of the software artifacts you build and work with.
• Supply Chain Focus – traditional SSDFs promote secure software by implementing best practices throughout the Software Development LifeCycle (SDLC), and have only recently moved to retrofit supply chain security which is the raison d’être for SLSA. 
• Compliance – US government software vendors must comply with key supply chain security requirements, including providing software attestations. While there are other ways to create them, SLSA generates far more comprehensive attestations as an output of the framework. 

Most telling is the fact that traditional SSDFs have been with us for decades, but software vendors both big and small (from Solarwinds to Kaseya to most recently CircleCI) were still blindsided by the rising tide of software supply chain attacks over the past three years:

Source: https://blog.sonatype.com/8th-annual-state-of-the-software-supply-chain-report

In fact, it’s come to the point where governments worldwide have begun legislating software supply chain security in an effort to decrease the risk of national infrastructure and intelligence data being compromised. 

While we certainly don’t advocate abandoning any SSDF standards you may have already implemented, you will need to add software supply chain security best practices if you hope to avoid the growing tsunami of supply chain attacks, as well as ensure you can comply with US government supplier requirements.

We also don’t recommend starting from scratch, but rather taking advantage of the ActiveState Platform, which can be integrated with your existing SDLC in a matter of days to provide SLSA Level 3 software artifacts, including programmatically generated software attestations and SBOMs.

How to Comply with SLSA 1.0

The SLSA 1.0 specification defines three build tracks (beyond Build Level 0, which indicates no SLSA implementation is present):

• Build Level 1: Provenance – any code, library or open source package imported into the organization must have a type of software attestation known as a “provenance attestation” that shows where the code was sourced from and how the package was built:
  • Who built the package (person or system)
  • What process/command was used
  • What the input artifacts (e.g., dependencies) were

A downstream system automatically verifies that packages were built as expected. 

• Build Level 2: Build Service + Signing – introduces a build service that includes signing of the provenance attestation. Signing ensures that packages were not tampered with after being built. A downstream service verifies the authenticity of the signature.
• Build Level 3: Hardened Builds – specifies a number of controls that harden the organization’s build service, including:
  • Pre-scripted, parameterless builds to ensure bad actors can’t get access to/edit build scripts.
  • Build environments that are ephemeral, isolated, and hermetically sealed (i.e., no access to the internet) ensure against bad actors compromising the build process.
  • Isolated signing service to ensure against bad actors accessing secrets used to sign the provenance.

Implementing (and maintaining) each Build Level is a non-trivial exercise that requires significant time and resources. While you could work toward a Level 3 implementation over a number of quarters, keep in mind that the SLSA specification is only at v1.0 and will evolve over time. Keeping up may be out of the reach of all but the largest enterprises. 

SLSA Compliance & ActiveState Platform 

The ActiveState Platform can provide you with SLSA Build Level 3 for your open source runtime environments. In fact, ActiveState goes a step further by ensuring reproducible builds, as well as providing a wide range of signed software attestations, including: 

• Provenance Attestations – specifies the origination (source) of all artifacts, along with how it was built, which includes all the artifacts that went into building it (and where they originated from), and finally where to retrieve the built artifact from.
  • Benefit: understand whether the source of all artifacts comply with your organization’s guidelines. For example, you may not be able to work with prebuilt artifacts or code sourced from sourceforge. 
• Verification Summary Attestations (VSA) – includes a summary of the SLSA level for each dependency (as well as for each transitive dependency) that went into building the artifact, as well as the SLSA level for the final artifact created.
  • Benefit: understand the risk associated with each software artifact given their SLSA level.
• Common Vulnerabilities and Exposures (CVE) Attestation – shows any known vulnerabilities associated with an artifact, as well as all known vulnerabilities for each of the artifact’s dependencies. 
  • Benefit: tell at a glance how many vulnerabilities (and their severity level) that any software artifact will expose your organization to when run.

The ActiveState Platform regularly pulls in and vets source code from open source repositories like PyPI, CPAN, RubyGems, etc, and then automatically builds them using our hardened build service. The output includes signed SBOMs (both JSON and SPDX), signed attestations (Provenance, VSA and CVE), and securely-built runtime environments (for Windows, Linux and macOS) that comply with SLSA Level 3.  

Conclusions – SLSA Secures the Software Supply Chain

SLSA represents a sea change in addressing software supply chain security. Long used by Google, it has now been turned over to the Open Source Software Foundation (OSSF) to bring to fruition in conjunction with a consortium of industry collaborators who all recognize the need to adopt a standard secure supply chain implementation – before their government legislates one. 

Every open source ecosystem is different. To date, organizations concerned with the security of the packages they were importing had to create processes and controls specific to each one. This represents an enormous drag on any organization’s resources since they typically work with more than one open source language/ecosystem. SLSA gives everyone a standard way to ensure the third-party code they work with is secure. 

By integrating your existing SDLC with the ActiveState Platform you can gain SLSA compliance in a matter of days (not months), and benefit from an organization dedicated to keeping up with the evolving SLSA specification, freeing up your developers to work on what matters most: creating features and functionality.

Read Similar Stories