Supply-chain Levels for Software Artifacts (SLSA)

Supply-chain Levels for Software Artifacts, or SLSA (pronounced “salsa”), is a security framework—a check-list of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects.

What is SLSA?

SLSA is a set of incrementally adoptable security guidelines established by industry experts to step-change the security of the software supply chain. It provides a common language for software producers and consumers to communicate about the security posture of software artifacts.

The framework is organized into “levels” that provide increasing software supply chain security guarantees. This helps organizations defend against common attacks, such as source code manipulation or unauthorized build modifications.

Why Should Companies Focus on SLSA?

As software supply chain attacks (like the SolarWinds or Log4j incidents) become more frequent, companies must prove that their software hasn’t been tampered with. SLSA provides a roadmap for securing the build process from source to deployment.

By following SLSA, companies can automate the generation of “provenance”—metadata that proves where, when, and how a piece of software was built. This builds trust with customers and partners who want to ensure the software they are installing is authentic.

Key Features of SLSA

• Levels (1-4): A graduated approach where Level 1 provides basic build documentation and Level 4 provides the highest level of confidence and tamper-resistance.
• Provenance: Verifiable metadata about how an artifact was built.
• Isolated Builds: Ensuring the build environment is secure and doesn’t have “memory” of previous builds.
• Common Vocabulary: A shared standard for developers, security professionals, and consumers.
• Tamper-proof Evidence: Cryptographically signed records of the build process.

When to Implement SLSA

Securing the supply chain is an ongoing effort that should be integrated into your CI/CD strategy:

• During Build Setup: When configuring your build pipelines, aim for SLSA Level 1 by ensuring the build process is scripted and produces provenance.
• Before Choosing Dependencies: Use SLSA levels to evaluate the security of third-party libraries you are integrating into your product.
• When Scaling Infrastructure: As your build farm grows, implement isolated and ephemeral build environments to reach higher SLSA levels.
• During Security Audits: Use the SLSA framework as a benchmark to identify gaps in your software delivery pipeline.

Strengthen your software supply chain by accelerating secure builds with Incredibuild.