SLSA Framework: The Definitive Guide for Securing Your Software Supply Chain

Software supply chain attacks increased 742% between 2019 and 2022, according to Sonatype research. The SolarWinds breach compromised 18,000+ organizations through a single tampered build. Log4Shell exposed millions of applications through a transitive dependency most teams didn’t know they had.

These aren’t theoretical risks. They’re operational realities that demand a structured response.

SLSA (Supply-chain Levels for Software Artifacts) provides that structure. It’s a security framework that gives you verifiable proof of how your software was built, who built it, and whether it was tampered with along the way.

Certified Software Supply Chain Security Expert

Stop supply chain attacks: SLSA, NIST SDF & dependency confusion defense.

View Course

This guide breaks down SLSA for security professionals, cybersecurity analysts, and AppSec engineers who need to implement it.

What is SLSA?

SLSA (pronounced “salsa”) stands for Supply-chain Levels for Software Artifacts. It’s a security framework that establishes standards and controls to prevent tampering, improve artifact integrity, and secure build infrastructure.

Google originally developed SLSA based on their internal “Binary Authorization for Borg” system, which has been mandatory for all Google production workloads for over 8 years. The framework was contributed to the Open Source Security Foundation (OpenSSF) in 2021 and is now governed by a vendor-neutral steering committee.

Current Version: SLSA v1.1 is the stable release as of 2024, with v1.2 in active development. The framework focuses primarily on the Build Track, with Source Track specifications under development.

What SLSA Provides:

• A common vocabulary for discussing supply chain security maturity
• Verifiable provenance metadata for software artifacts
• Incremental security levels that map to specific threat mitigations
• Alignment with NIST SSDF and EO 14028 requirements

SLSA is not a scanner, a tool, or a product. It’s a specification that defines what “secure” looks like at different maturity levels, and it’s designed to be automatically enforceable through policy engines.

Why SLSA Matters: The Supply Chain Threat Reality

The software supply chain has become the preferred attack vector for sophisticated adversaries. Here’s why:

High-Profile Attacks That Changed Everything

SolarWinds (2020):

Attackers compromised the build system for SolarWinds’ Orion platform and injected the SUNBURST backdoor into legitimate software updates. Over 18,000 organizations, including U.S. government agencies, installed the compromised update. The attack went undetected for months because the malicious code was signed with SolarWinds’ legitimate certificates.

Codecov (2021):

Attackers modified Codecov’s Bash Uploader script to exfiltrate environment variables, including CI/CD secrets and credentials. The compromised script was distributed to thousands of organizations for two months before detection.

JetBrains TeamCity (2023)

Vulnerabilities in TeamCity CI/CD servers allowed attackers to gain administrative control over build infrastructure, potentially compromising any software built through those systems.

Log4Shell (2021):

A critical vulnerability in the Log4j logging library affected millions of applications. Most organizations didn’t know they were using Log4j because it was a transitive dependency buried deep in their dependency trees.

The Attack Surface

According to Wiz, these attacks share a common pattern: they exploit the growing interdependence among software libraries, build tools, and infrastructure. A single compromised component can cascade through thousands of downstream applications.

The attack vectors include:

• Source tampering: Unauthorized modifications to source code
• Build tampering: Malicious code injection during the build process
• Dependency poisoning: Compromised or malicious packages in registries
• Provenance forgery: Fake metadata claiming artifacts came from trusted sources
• Compromised credentials: Stolen signing keys or build service accounts
  

SLSA addresses these vectors by creating verifiable evidence at each stage of the build process.

SLSA Security Levels Explained 

SLSA defines progressive security levels for the Build Track. Each level adds specific controls that mitigate increasingly sophisticated threats.

Level 0: No SLSA

No provenance exists. You have no verifiable evidence of how artifacts were built. This is the default state for most software.

Risk: You cannot detect tampering, verify artifact origin, or respond effectively to supply chain incidents.

Level 1: Provenance Exists

The build process generates provenance metadata describing how the artifact was built. This includes:

• Digest/hash of the output artifact
• Source repository and commit hash
• Build platform identity
• Dependencies used during build
• Timestamp

Requirements:

• Build process must be fully scripted (no manual steps)
• Provenance must be automatically generated by the build platform
• Provenance must be available to consumers

What It Protects Against: Accidental distribution of wrong packages, basic traceability for incident response.

Limitations: Provenance is not signed. Attackers with access to artifact metadata can forge it. Level 1 assumes the build platform is trustworthy but doesn’t validate that assumption.

Level 2: Signed Provenance + Hosted Build

Provenance is cryptographically signed by the build platform, and builds run on dedicated infrastructure rather than developer workstations.

Requirements:

• Build platform must automatically generate AND sign provenance
• Builds must run on a hosted build service
• Consumers must be able to verify provenance authenticity

What It Protects Against: Provenance forgery after the build completes, builds from compromised developer machines.

Limitations: Doesn’t prevent tampering DURING the build. Doesn’t address insider threats. No build isolation between projects.

Level 3: Hardened Builds

The build platform implements controls that prevent tampering during the build process itself.

Requirements:

• Isolated build environments (each build runs independently)
• Ephemeral environments (provisioned fresh for each build)
• Signing secrets inaccessible to user-defined build steps
• Provenance cannot be falsified by build service users

What It Protects Against: Cross-build contamination, insider threats, compromised credentials, tampering during build execution.

According to JFrog, Level 3 makes forging provenance extremely difficult because the signing keys are isolated from the build steps that users control.

Note: SLSA v1.0+ consolidated the previous Level 4 requirements. Hermetic builds and reproducibility are now recommended practices rather than strict requirements.

How SLSA Works: Provenance and Attestations

Provenance is the central concept in SLSA. It’s tamper-evident metadata that answers three questions:

1. Who built the artifact?
2. What sources and dependencies were used?
3. How was it built?

Provenance Structure

SLSA provenance follows the in-toto attestation format. A typical provenance document includes:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "my-artifact",
    "digest": {"sha256": "abc123..."}
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/slsa-framework/slsa-github-generator",
      "externalParameters": {
        "repository": "https://github.com/org/repo",
        "ref": "refs/heads/main"
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml"
      }
    }
  }
}

Cryptographic Signing with Sigstore

Sigstore is the standard toolchain for SLSA signing. It includes:

• Cosign: Signs and verifies container images and artifacts
• Fulcio: Issues short-lived certificates based on OIDC identity
• Rekor: Transparency log that records all signing events

Sigstore enables “keyless” signing. Instead of managing long-lived signing keys, developers authenticate via OIDC (GitHub, Google, etc.), and Fulcio issues a certificate tied to that identity. The signing event is recorded in Rekor’s immutable log.

Verification Workflow

1. Consumer downloads artifact and provenance
2. Verify provenance signature against Sigstore’s certificate transparency log
3. Check that builder identity matches expected trusted builders
4. Verify artifact digest matches the digest in provenance
5. Validate source repository and commit match expectations
6. The policy engine approves or rejects based on organizational rules

Real-World Attack Prevention: SLSA in Action

How SLSA Level 3 Would Have Stopped SolarWinds

The SolarWinds attack succeeded because:

1. Attackers gained access to the build environment
2. They injected malicious code during the build process
3. The compromised artifact was signed with legitimate credentials
4. No verification mechanism detected the tampering

With SLSA Level 3:

• Isolated builds would have prevented attackers from persisting in the build environment
• Ephemeral environments would have been destroyed after each build
• Provenance signing keys would have been inaccessible to the compromised build steps
• Provenance verification would have detected that the artifact didn’t match expected source commits.
  

Dependency Confusion Mitigation

Dependency confusion attacks exploit package managers that check public registries before private ones. Attackers publish malicious packages with the same names as internal packages.

SLSA provenance verification can detect this:

• Provenance shows which registry the dependency came from
• Policy engines can reject artifacts built with dependencies from unexpected sources
• Builder identity verification confirms the package came from a trusted build system

Insider Threat Protection

SLSA Level 3’s requirement for isolated signing secrets means that even a malicious insider with access to the build configuration cannot forge provenance. The signing keys are controlled by the build platform, not by users.

Certified Software Supply Chain Security Expert

Stop supply chain attacks: SLSA, NIST SDF & dependency confusion defense.

View Course

SLSA Implementation by Role

Implementation Roadmap and Best Practices

Phase 1: Foundation (Weeks 1-4)

Goal: Achieve SLSA Level 1

Actions:

• Audit existing build processes for manual steps
• Script all builds completely (no human intervention)
• Implement basic provenance generation
• Store provenance alongside artifacts

Tools: Any CI system, basic logging

Effort: Low. This is documentation and process standardization.

Phase 2: Signing (Weeks 5-12)

Goal: Achieve SLSA Level 2

Actions:

• Migrate builds to hosted CI/CD platforms
• Implement cryptographic signing with Sigstore
• Configure provenance verification in staging environments
• Establish trusted builder identities

Tools: Sigstore (Cosign), GitHub Actions, or Google Cloud Build

Effort: Medium. Requires tooling changes and key management decisions.

Phase 3: Hardening (Months 3-6)

Goal: Achieve SLSA Level 3

Actions:

• Implement isolated build environments
• Configure ephemeral build runners
• Protect signing secrets from build steps
• Enforce provenance verification in production deployments

Tools: Tekton Chains, Kyverno/OPA, Binary Authorization

Effort: High. Requires infrastructure changes and policy enforcement.

Common Mistakes to Avoid

1. Skipping Level 1: Don’t jump straight to Level 3. The incremental approach exists for a reason.
2. Ignoring verification: Generating provenance is useless if you don’t verify it at deployment time.
3. Hardcoding trust: Don’t hardcode trusted builder identities. Use policy-as-code that can be audited and updated.
4. Forgetting dependencies: Your artifact’s SLSA level is independent of your dependencies’ levels. Verify dependency provenance separately.

Manual exceptions: Every manual override weakens the system. Automate exception handling or eliminate the need for exceptions.

SLSA Limitations and What It Doesn’t Cover

SLSA is powerful but not complete. According to Wiz, organizations should be aware of these limitations:

What SLSA Doesn’t Address

1. Code quality: SLSA doesn’t tell you if the source code has vulnerabilities. It only verifies that the artifact was built from that source.
2. Runtime security: SLSA covers build-time integrity, not runtime protection. You still need container security, network policies, and runtime monitoring.
3. Third-party dependency verification: SLSA verifies YOUR build process. It doesn’t guarantee that your dependencies were built securely unless they also provide SLSA provenance.
4. Malicious producers: SLSA doesn’t protect against organizations that intentionally produce malicious software. It assumes you trust the source.
5. Vulnerability management: SLSA doesn’t scan for CVEs. Pair it with SCA tools and vulnerability scanners.

Conclusion

SLSA provides a structured, incremental approach to software supply chain security. It’s not a silver bullet, but it addresses a critical gap: verifiable proof of build integrity.

Start with Level 1 to establish provenance. Move to Level 2 for signed attestations. Target Level 3 for your most critical applications.

The tooling exists. The specifications are mature. The regulatory pressure is real. The question isn’t whether to implement SLSA. It’s how fast you can get there.

Ready to go deeper? The Certified Software Supply Chain Security Expert (CSSCE) course covers SLSA implementation end-to-end with hands-on labs and real-world scenarios.

Certified Software Supply Chain Security Expert

Stop supply chain attacks: SLSA, NIST SDF & dependency confusion defense.

View Course

FAQs

Sources:

• SLSA Official Documentation
• OpenSSF SLSA Project
• Wiz SLSA Framework Guide
• JFrog SLSA Framework
• Cycode Google SLSA Takeaways
• CBT Nuggets SLSA for CI/CD
• Petronella Tech Supply Chain Trifecta
• GitGuardian Supply Chain Security
• Chainguard Academy SLSA Introduction