From SBOM to SLSA: Securing Your Software Supply Chain

Posted: March 27, 2026 to Cybersecurity.

Software Supply Chain Attacks Are Accelerating

The software supply chain has become the highest-leverage attack vector in cybersecurity. When attackers compromise a single widely-used library, build system, or distribution channel, they gain access to every organization that depends on it. The SolarWinds attack (2020) compromised 18,000 organizations through a single tainted software update. The Log4Shell vulnerability (2021) affected virtually every organization using Java. The 3CX supply chain compromise (2023) distributed malware through a legitimate business phone application used by 600,000 organizations.

According to CISA, software supply chain attacks increased 742% between 2019 and 2024. The White House Executive Order 14028 on Improving the Nation's Cybersecurity specifically mandated that federal agencies require SBOMs from software suppliers and that software vendors adopt secure development practices.

Two frameworks have emerged as the essential building blocks for supply chain security: the Software Bill of Materials (SBOM) for transparency and Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") for integrity. Together, they form a comprehensive approach to knowing what is in your software and proving it has not been tampered with.

SBOM: Knowing What Is in Your Software

What Is an SBOM

A Software Bill of Materials is a machine-readable inventory of every component in a piece of software: direct dependencies, transitive dependencies, libraries, frameworks, compilers, and tools used in the build process. Think of it as a nutritional label for software. Just as a food label tells you exactly what ingredients are in a product, an SBOM tells you exactly what code is in your software.

Why SBOMs Matter

When a new vulnerability is disclosed (like Log4Shell), organizations need to answer one question immediately: "Are we affected?" Without an SBOM, answering that question requires manually scanning every application, container, and system in your environment, a process that takes days or weeks. With SBOMs for every deployed application, you can answer in minutes by searching your SBOM inventory for the affected component.

SBOMs enable:

• Vulnerability response: Instantly identify which applications use a vulnerable component
• License compliance: Identify all open-source licenses in your supply chain and flag incompatible licenses before they create legal risk
• Vendor risk assessment: Evaluate the security posture of third-party software before deployment by examining its dependency tree
• Regulatory compliance: Meet federal SBOM requirements (Executive Order 14028) and industry mandates

SBOM Formats

Two SBOM formats have emerged as standards:

• CycloneDX: Developed by OWASP, CycloneDX is designed specifically for security use cases. It supports software components, hardware components, services, vulnerabilities, and license information. Supported in JSON, XML, and Protocol Buffers formats.
• SPDX (Software Package Data Exchange): Developed by the Linux Foundation and recognized as ISO/IEC 5962:2021. SPDX has broader scope covering licensing and provenance information. It is the format specified in many government procurement requirements.

Generating SBOMs

Modern SBOM generation tools integrate into your build pipeline:

• Syft: Open-source tool from Anchore that generates SBOMs from container images, filesystems, and archives in both CycloneDX and SPDX formats
• Trivy: Aqua Security's open-source scanner that generates SBOMs and simultaneously scans for known vulnerabilities
• CycloneDX generators: Language-specific plugins for Maven (Java), npm (JavaScript), pip (Python), and other package managers that generate accurate dependency graphs
• GitHub and GitLab: Both platforms offer built-in dependency graph features that can export SBOMs

SLSA: Proving Software Integrity

What Is SLSA

SLSA (Supply-chain Levels for Software Artifacts) is a security framework developed by Google that provides a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects. While SBOMs tell you what is in your software, SLSA proves that the software was built correctly and has not been tampered with during the build and distribution process.

SLSA Levels

SLSA defines four levels of increasing supply chain security maturity:

• SLSA Level 0 (No guarantees): No provenance information. The typical state of most software today.
• SLSA Level 1 (Provenance exists): The build process generates provenance metadata documenting how the artifact was built (what source, what builder, what build steps). Provenance is available but not necessarily tamper-proof.
• SLSA Level 2 (Hosted build platform): Builds run on a hosted service (like GitHub Actions, Google Cloud Build, or GitLab CI) that generates authenticated, tamper-resistant provenance. The source and build platform are separate to prevent a single compromised system from modifying both code and build output.
• SLSA Level 3 (Hardened builds): The build platform is hardened against tampering. Builds are isolated, reproducible, and parameterless (the build definition is fully declared in source control). Provenance is unforgeable and can be independently verified.

SLSA Provenance

The core of SLSA is the provenance attestation: a signed document that records what source code was used, what build platform and builder identity were used, what build command or configuration was invoked, what dependencies were resolved, and what artifact was produced. Provenance enables consumers to verify that an artifact was built from the expected source code using the expected process. If an attacker modifies the source, compromises the build system, or tampers with the output, the provenance will not match and the tampering is detectable.

Implementing SBOM and SLSA Together

Step 1: Inventory Your Current State

Before implementing supply chain security controls, understand your current posture. Identify all software your organization develops and deploys. Map the build and deployment pipeline for each application. Identify existing dependency management practices. Assess your vulnerability scanning and response capabilities.

Step 2: Implement SBOM Generation in CI/CD

Add SBOM generation to your continuous integration pipeline. Generate an SBOM for every build, not just releases. Store SBOMs alongside the artifacts they describe. Include SBOMs in your artifact registry (container registry, package repository). Automate SBOM ingestion into a vulnerability management platform that alerts when new CVEs affect your components.

Step 3: Achieve SLSA Level 1 (Provenance)

Configure your CI/CD pipeline to generate provenance metadata for every build. If you use GitHub Actions, the SLSA GitHub generator automatically produces SLSA provenance attestations. For other platforms, use the in-toto framework to generate provenance during the build process.

Step 4: Achieve SLSA Level 2 (Hosted Builds)

Ensure all builds run on a hosted platform rather than developer workstations. Separate source control from build execution so no single system controls both. Configure the build platform to generate authenticated provenance signed with the platform's identity.

Step 5: Achieve SLSA Level 3 (Hardened Builds)

Harden your build platform by running builds in ephemeral, isolated environments, eliminating build parameters that could inject malicious content, ensuring builds are fully defined by source control configuration, and implementing reproducible builds where the same source always produces the same output.

Step 6: Continuous Monitoring and Response

Supply chain security is not a one-time implementation. Continuously monitor for new vulnerabilities in your dependency tree via SBOM-based scanning. Verify provenance for all artifacts before deployment. Monitor for dependency confusion and typosquatting attacks on your package registries. Track SBOM drift between builds to identify unexpected dependency changes. Establish a response playbook for supply chain compromise scenarios.

Supply Chain Security for Compliance

Multiple compliance frameworks now incorporate software supply chain requirements:

• CMMC: NIST SP 800-171 controls SA-4, SR-3, and SR-4 address supply chain risk management
• FedRAMP: Federal agencies increasingly require SBOMs from cloud service providers
• NIST SSDF: The Secure Software Development Framework (SP 800-218) provides detailed practices for secure development
• PCI DSS v4.0: Requirement 6 strengthened software development security practices
• EU Cyber Resilience Act: Requires SBOMs for products sold in the European Union

Regulatory Landscape for Software Supply Chain Security

The regulatory environment around software supply chain security has evolved rapidly since 2020, driven by high-profile attacks and government recognition that software supply chain vulnerabilities pose national security risks.

US Federal Requirements

Executive Order 14028 (May 2021) directed NIST to develop guidelines for software supply chain security, resulting in the Secure Software Development Framework (SSDF, SP 800-218) and updated guidance on SBOMs. Federal agencies are now required to obtain SBOMs from software vendors for critical software and to verify that vendors follow SSDF practices. The Office of Management and Budget (OMB) issued memoranda M-22-18 and M-23-16 requiring federal agencies to collect self-attestation forms from software producers confirming adherence to SSDF practices. For software classified as critical, third-party assessment may be required.

International Regulations

The European Union's Cyber Resilience Act (CRA), expected to take full effect by 2027, requires SBOM delivery for products with digital elements sold in the EU. The act applies broadly to software and connected devices, meaning US software companies selling to European customers will need SBOM generation capabilities. The EU NIS2 Directive also includes supply chain security requirements for entities operating in critical sectors.

Notable Supply Chain Attacks and Lessons Learned

Understanding real-world supply chain attacks illustrates why SBOM and SLSA are necessary and what they would have prevented.

SolarWinds Orion (2020)

Russian intelligence operatives compromised SolarWinds' build system and injected malicious code into the Orion IT monitoring platform. The trojanized update was distributed to approximately 18,000 organizations including multiple US government agencies. The attack was possible because there was no build integrity verification (SLSA Level 2+ would have detected the unauthorized build modification), no SBOM tracking that could have revealed the injected component, and the build system was not hardened or isolated from other systems.

Codecov (2021)

Attackers modified a Docker image used in Codecov's CI pipeline, injecting a credential harvester that collected environment variables (including secrets) from every Codecov customer's CI builds. The modified image went undetected for two months because there was no provenance verification for the Docker image used in the pipeline, no integrity checking to detect that the image had been modified after publication, and the build process pulled the latest image without pinning to a verified digest.

XZ Utils Backdoor (2024)

A sophisticated social engineering campaign placed a backdoor in the XZ compression library, a foundational component used by virtually every Linux distribution. The attacker gained maintainer trust over two years before introducing malicious build scripts. The backdoor was discovered by accident when a developer noticed unusual SSH latency. This attack highlights that even trusted open-source maintainers can be compromised, SBOM-based monitoring would have flagged the affected XZ versions across all consuming projects, and SLSA Level 3 reproducible builds would have made the build-time injection detectable by independent verification.

Building an SBOM Management Program

Generating SBOMs is the first step. Managing them effectively at organizational scale requires a structured program.

SBOM Inventory and Storage

Every software artifact you build, deploy, or consume should have an associated SBOM. Store SBOMs in a centralized repository alongside the artifacts they describe. Container registries like Harbor support SBOM attachment to container images. For non-containerized software, maintain an SBOM database indexed by application name, version, and deployment environment. Retention policies should keep SBOMs for at least the lifetime of the software version they describe, plus any regulatory retention period.

Vulnerability Monitoring Pipeline

SBOMs become actionable when connected to a vulnerability monitoring pipeline. The pipeline works as follows: new SBOMs are generated with each build and stored in the repository. A vulnerability scanner continuously cross-references SBOM components against the National Vulnerability Database (NVD), GitHub Advisory Database, and vendor-specific advisories. When a new CVE is published that affects a component in any active SBOM, the system generates an alert with the affected applications, component version, vulnerability severity, and available patches or mitigations. The security team triages alerts, prioritizes remediation based on exploitability and business impact, and tracks remediation to completion.

SBOM Sharing with Customers and Partners

If you are a software vendor, sharing SBOMs with customers demonstrates transparency and meets emerging regulatory requirements. Establish a process for customers to request SBOMs, distribute them through your security documentation portal, and update them with each release. For government customers, SBOM delivery may be a contractual requirement under Executive Order 14028 and subsequent guidance from NIST and CISA.

Practical SLSA Implementation with GitHub Actions

For organizations using GitHub Actions for CI/CD, achieving SLSA Level 3 is straightforward using the official SLSA generator. Here is how the implementation works:

Step 1: Configure the SLSA GitHub Generator

The SLSA project maintains a GitHub Action that generates SLSA provenance attestations for your builds. You add a workflow step that runs after your build step, which generates a signed provenance document recording the source repository, commit hash, builder identity (GitHub Actions), build command, and output artifact hash. The provenance is signed using GitHub's OIDC identity, making it cryptographically verifiable.

Step 2: Publish Provenance with Artifacts

Attach the provenance attestation to your release artifacts. For container images, provenance can be attached using cosign and stored in the container registry alongside the image. For binary releases, publish the provenance file alongside the release artifact in your GitHub Release or distribution channel.

Step 3: Verify Provenance in Your Deployment Pipeline

Before deploying any artifact to production, add a verification step that checks the provenance attestation using the slsa-verifier tool. The verifier confirms the attestation signature is valid and was signed by the expected builder identity, the source repository matches your expected repository, and the artifact hash in the provenance matches the artifact being deployed. If verification fails, the deployment is blocked, preventing tampered artifacts from reaching production.

Supply Chain Security Beyond SBOM and SLSA

A comprehensive supply chain security program includes additional controls beyond SBOM and SLSA:

• Dependency pinning: Pin dependency versions in your build files rather than using version ranges. This prevents automatic pulling of compromised versions.
• Private package registries: Mirror approved packages in a private registry (Artifactory, Nexus, GitHub Packages) rather than pulling directly from public registries. This provides a control point for security scanning and approval.
• Dependency review automation: Automatically flag new dependencies and dependency version changes in pull requests for security review before they merge.
• Code signing: Sign your release artifacts with a code signing certificate so consumers can verify the publisher identity.
• Reproducible builds: Configure your build process so that building the same source code always produces the same output. This allows independent verification that a binary was built from its claimed source code.
• Vendor security requirements: Require your software vendors to provide SBOMs, SLSA provenance, and evidence of secure development practices as conditions of procurement.

Frequently Asked Questions