Supply chain security represents a complex challenge for organizations across industries, but it might be getting just a bit easier today with the release of the SLSA (pronounced salsa) 1.0 specification.

The supply chain levels for software artifacts (SLSA) project got its start as a Google-led effort in 2021 and is now managed as a multi-stakeholder initiative under the direction of the Linux Foundation's OpenSSF (software security foundation). SLSA is a framework that aims to help define and ensure the integrity of software artifacts throughout the software supply chain.

For any given application or service, there are multiple components, or artifacts, that are used to help build and deliver an offering. The SLSA framework provides several levels of conformance that outline escalating levels of security rigor. The goal of the SLSA framework is to provide assurance that software has not been tampered with and can be traced back to its source with a high degree of security.

"Technology like this, which is about tracing the provenance of artifacts and the degree of rigor that's been put into the the build processes around it, really cannot be done just at the tail end of a supply chain or by one party in a supply chain," Brian Behlendorf, general manager of the OpenSSF, told SDxCentral. "It really is only meaningful if it's done by everybody participating in that supply chain and so it needed to become an open specification."

There are multiple aspects of supply chain security including building, delivering and updating software over time. Behlendorf said that SLSA 1.0 has a focus on the build track for software development.

The SLSA 1.0 specification defines three levels of conformance for software development builds SLSA level 1, requires that the organization show some form of provenance for how a specific software package was built. The basic goal with level one is to have documentation around the build process.

SLSA level 2 conformance goes a step further, with a requirement for signed provenance to help prove the authenticity of the build. The goal with level 2 is to provide further assurance that there has been no tampering with a build after it has been developed.

With SLSA level 3 there is a requirement to have a hardened build platform. The focus of level 3 is to provide assurance that there has been no tampering with code during the build process itself.

A related concept to the SLSA in the supply chain security world is that of the software bill of materials, commonly referred to by the acronym SBOM. An SBOM identifies all the components that are part of an application.

Behlendorf commented that while the concepts are closely related, the SLSA 1.0 specification doesn't specifically call out SBOMs. Rather he explained that SLSA defines a vocabulary that could be worked into an SBOM document that accompanies a software artifact.

The open source Sigstore project, for cryptographically signing and verifying software is also related to the SLSA effort. Overall, Behlendorf emphasized that supply chain security isn't about any one technology or specification, but rather about a combination of them.

The effort to define a comprehensive model for supply chain security using open specifications and tools, is still a work in progress.

"We're not quite at the point where you've articulated that vision clearly yet or what those pieces are or how we get there," Behlendorf said.   But we have the makings of this and that is both within the OpenSSF as well as in adjacent efforts."