Software supply chain attacks have become one of the most significant threats in cybersecurity. The SolarWinds breach, the Log4Shell vulnerability, the event-stream npm package compromise, and the xz utils backdoor demonstrated that attackers are increasingly targeting the software supply chain rather than individual applications. When a single compromised dependency can affect thousands of downstream projects, the security of the open source ecosystem becomes everyone's problem.
Three technologies have emerged as the foundational pillars of supply chain security: Software Bills of Materials (SBOMs), Sigstore for artifact signing, and SLSA for build integrity. This guide explains what each technology does, how they work together, and how to implement them in your projects.
The Supply Chain Threat Landscape
A software supply chain attack targets the tools, processes, and dependencies used to build software rather than the software itself. Understanding the attack surface helps explain why multiple defenses are necessary.
Common Attack Vectors
- Dependency confusion: An attacker publishes a malicious package with the same name as an internal package to a public registry. Build systems that check public registries first may download the malicious version.
- Typosquatting: Publishing packages with names similar to popular packages (e.g., "reqeusts" instead of "requests") and waiting for developers to make typos.
- Account takeover: Compromising a maintainer's registry account and publishing a malicious update to a legitimate package.
- Build system compromise: Injecting malicious code during the build process so the distributed artifact contains code that does not exist in the source repository.
- Upstream compromise: Contributing malicious code to an upstream dependency, either through social engineering (as in the xz utils case) or by compromising development infrastructure.
Software Bills of Materials (SBOMs)
An SBOM is a comprehensive inventory of all components, libraries, and dependencies in a software product. It is analogous to an ingredient list on food packaging: it tells you exactly what is inside the software you are running.
Why SBOMs Matter
When the Log4Shell vulnerability was disclosed in December 2021, organizations scrambled to determine whether they were affected. Many could not answer a basic question: "Do we use Log4j, and if so, where?" An SBOM would have answered this question instantly.
SBOM Formats
- SPDX (Software Package Data Exchange): An ISO/IEC standard (ISO/IEC 5962:2021) created by the Linux Foundation. SPDX is comprehensive and supports detailed license information.
- CycloneDX: An OWASP standard designed specifically for security use cases. It is lighter-weight than SPDX and includes built-in support for vulnerability references and risk scoring.
Generating SBOMs
SBOMs can be generated at different stages of the development lifecycle. Source SBOMs analyze source code and dependency manifests (package.json, requirements.txt, go.mod). Build SBOMs capture the actual dependencies resolved during the build process. Runtime SBOMs inventory the components present in a deployed container or system.
Tools like Syft (by Anchore), Trivy (by Aqua Security), and cdxgen can automatically generate SBOMs from source code, container images, and file systems. These tools support both SPDX and CycloneDX formats.
Using SBOMs for Vulnerability Management
Once you have an SBOM, you can continuously check its contents against vulnerability databases like the National Vulnerability Database (NVD), GitHub Advisory Database, and OSV (Open Source Vulnerabilities). Tools like Grype (by Anchore) and OSV-Scanner (by Google) automate this process, alerting you when a component in your SBOM has a known vulnerability.
Sigstore: Making Signing Easy
Code signing is not new, but historically it has been so difficult that most open source projects did not do it. Sigstore, a Linux Foundation project, dramatically simplifies artifact signing by eliminating the need to manage long-lived signing keys.
The Problem with Traditional Signing
Traditional code signing requires generating a key pair, securely storing the private key, managing key rotation, and distributing the public key to verifiers. For individual open source maintainers, this overhead is prohibitive. Compromised signing keys (as happened with the APT repository signing key leak) can be as dangerous as the attacks they are meant to prevent.
How Sigstore Works
Sigstore uses three components that work together.
- Cosign: A tool for signing and verifying container images, blobs, and other artifacts. Cosign supports "keyless" signing using short-lived certificates tied to your identity (e.g., your GitHub or Google account).
- Fulcio: A certificate authority that issues short-lived certificates based on OIDC identity. When you sign an artifact with Cosign, Fulcio verifies your identity through an OIDC provider and issues a certificate that is valid for just 10 minutes.
- Rekor: A transparency log that records all signing events. When an artifact is signed, the signing event is recorded in Rekor's immutable, append-only log. Anyone can verify that a signature exists and when it was created.
Keyless Signing in Practice
With Sigstore, signing a container image requires a single command. Cosign authenticates you through your identity provider, obtains a short-lived certificate from Fulcio, signs the artifact, and records the event in Rekor. No long-lived keys to manage, no key distribution problem, and a public transparency log that provides accountability.
SLSA: Build Integrity
SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a framework for ensuring that software artifacts were built from the expected source code by the expected build process. It addresses the gap between source code and distributed artifact: even if the source code is secure, the build process could be compromised to inject malicious code.
SLSA Levels
- SLSA Build Level 1: The build process is documented and produces provenance metadata describing how the artifact was built.
- SLSA Build Level 2: The build runs on a hosted build service, and the provenance is signed by the build service (not the developer).
- SLSA Build Level 3: The build service is hardened against tampering. The build environment is isolated, ephemeral, and parameterless (the build process cannot be influenced by user-defined parameters that could inject malicious code).
Build Provenance
SLSA provenance is a signed document that answers three questions: What source code was used? What build process was followed? What artifact was produced? This information allows consumers to verify that a published artifact actually corresponds to the source code they can inspect.
SLSA in GitHub Actions
The SLSA framework provides GitHub Actions workflows that generate SLSA Level 3 provenance for common artifact types (container images, Go binaries, npm packages). These workflows run in isolated environments and produce provenance that can be verified using the slsa-verifier tool.
Putting It All Together
These three technologies form layers of defense. SBOMs provide transparency about what components are in your software. Sigstore provides assurance about who produced the artifact. SLSA provides assurance about how the artifact was produced.
A Complete Supply Chain Security Pipeline
- Build: Use a SLSA-compliant build service that generates signed provenance.
- Sign: Sign the resulting artifacts (container images, packages) using Sigstore/Cosign.
- Inventory: Generate an SBOM and attach it to the artifact.
- Verify: Before deploying, verify the artifact's signature, check the SLSA provenance, and scan the SBOM against vulnerability databases.
- Monitor: Continuously scan SBOMs for newly disclosed vulnerabilities.
No single tool solves supply chain security. But the combination of SBOMs, Sigstore, and SLSA provides a practical, incrementally adoptable framework that addresses the most critical supply chain threats facing the open source ecosystem today.
