DevSecOps SLSA

Supply-chain Levels for Software Artifacts, or SLSA ("salsa")

It’s a security framework, a checklist of values and constraints to prevent interfering, improve integrity, and secure packages and infrastructure. It enables you to be as resilient as possible, at any link in the supply chain.

Overview

SLSA is a set of standards for supply chain security, recognized by engineering agreement. The requirement set by SLSA is useful for both software creators and customers: creators can follow SLSA’s strategies to make their software supply chain more protected, and customers can use SLSA to make choices about whether to trust a software package.

What it provides

• A general terminology to talk about software supply chain security.
• A way to protect your incoming supply chain by calculating the credibility of the items you use.
• An work sheet to expand your own software’s security.
• A way to gage your attempts toward accordance with imminent Executive Order standards in the Secure Software Development Framework (SSDF)

Need for SLSA

SLSA is designed to support automation that tracks code handling from source to binary, protecting against tampering regardless of the complexity of the software supply chain. As a result, SLSA increases trust that the analysis and review performed on source code can be assumed to still apply to the binary consumed after the build and distribution process.
Security techniques for vulnerability detection and analysis of source code are essential but are not enough on their own. Even after fuzzing or vulnerability scanning is completed, changes to code can happen, whether unintentionally or from insider threats or compromised accounts. Risk for code modification exists at each link in a typical software supply chain, from source to build through packaging and distribution. Any weaknesses in the supply chain undermine confidence in whether the code that you run is the code that you scanned.

The SLSA framework provides this trust with guidelines and tamper-resistant evidence for securing each step of the software production process.

SLSA helps protect against the risk of:

• Code modification (by adding a tamper-evident “seal” to code after source control)
• Uploaded artifacts that were not built by the expected CI/CD platform (by marking artifacts with a factory “stamp” that shows which build platform created it)
• Threats against the build platform (by providing “manufacturing facility” best practices for build platform services)
• For more exploration of this analogy, see the blog post-SLSA + SBOM: Accelerating SBOM success with the help of SLSA.

Target Audience

Everyone involved in producing and consuming software or providing infrastructure for software.

• Software producers, such as an open-source project, a software vendor, or a team writing first-party code for use within the same company. SLSA gives you protection against tampering along the supply chain to your consumers, both reducing insider risk and increasing confidence that the software you produce reaches your consumers as you intended.
• Software consumers, such as a development team using open-source packages, a government agency using vendor software, or a CISO judging organizational risk. SLSA gives you a way to judge the security practices of the software you rely on and be sure that what you receive is what you expect.
• Infrastructure providers, provide infrastructure such as an ecosystem package manager, build platform, or CI/CD platform. As the bridge between the producers and consumers, your adoption of SLSA enables a secure software supply chain between them.

Working

We talk about SLSA in terms of tracks and levels. A SLSA track focuses on a particular aspect of a supply chain, such as the Build Track. SLSA v1.0 consists of only a single track (Build), but future versions of SLSA will add tracks that cover other parts of the software supply chain, such as how source code is managed.

Within each track, ascending levels indicate increasingly hardened security practices. Higher levels provide better guarantees against supply chain threats but come at higher implementation costs. Lower SLSA levels are designed to be easier to adopt but with only modest security guarantees. SLSA 0 is sometimes used to refer to software that doesn’t yet meet any SLSA level. Currently, the SLSA Build Track encompasses Levels 1 through 3, but we envision higher levels to be possible in future revisions.

The combination of tracks and levels offers an easy way to discuss whether the software meets a specific set of requirements. By referring to an artifact as meeting SLSA Build Level 3, for example, you’re indicating in one phrase that the software artifact was built following a set of security practices that industry leaders agree to protect against supply chain compromises.

Ref: https://slsa.dev