Software Supply Chain Security: SBOMs, SLSA, and Sigstore in Practice

Modern applications are not built from scratch. They are assembled from open-source packages, internal libraries, container base images, build tools, and cloud services. That convenience creates a supply chain that attackers increasingly target. A single compromised dependency or build runner can inject code into thousands of production systems. This article explains how to build a practical software supply chain security program using SBOMs, SLSA, Sigstore, and policy enforcement.

Why the Software Supply Chain Is a Primary Attack Surface

Traditional security focused on network perimeters and runtime workloads. The supply chain shifts the attack surface left: source repositories, package registries, CI/CD systems, artifact stores, and deployment pipelines. High-profile incidents have shown the impact. SolarWinds involved build system tampering. Log4Shell exposed the reach of a single transitive dependency. Codecov demonstrated how a compromised CI script can exfiltrate secrets. npm protestware and dependency confusion attacks showed that package ecosystems are not inherently trustworthy.

Common attack vectors include dependency confusion, typosquatting, compromised maintainer accounts, build system tampering, artifact registry poisoning, and CI/CD credential theft. Defending against these vectors requires more than vulnerability scanning. It requires verifiable evidence about what is in your software, how it was built, and who signed it.

The Core Building Blocks: SBOM, Provenance, Attestations, and Signatures

Supply chain security uses four related concepts. They are often confused, but each answers a different question.

• SBOM (Software Bill of Materials): An inventory of components, versions, licenses, and hashes. It answers: what is inside this artifact?
• Provenance: A record of how an artifact was built, including source repository, commit, builder identity, and build parameters. It answers: how was this made?
• Attestation: A signed statement about an artifact or build. Provenance is one type of attestation. Others include vulnerability scan results, test outcomes, and code review approvals. It answers: what verifiable claims exist?
• Signature: Cryptographic proof of identity and integrity. It answers: who signed this, and has it changed since?

Together, these allow you to make automated trust decisions. For example, a deployment controller can verify that an image was built by a trusted builder from a specific commit, contains no critical vulnerabilities, and has not been modified since signing.

SBOMs in Depth: Generation, Distribution, and Consumption

An SBOM is necessary but not sufficient. Generating an SBOM at the end of a release cycle is better than nothing, but it is far more useful when generated automatically during the build. The SBOM should include direct and transitive dependencies, exact versions, package URLs, and cryptographic hashes where possible. For container images, the SBOM should cover both the application dependencies and the operating system packages.

Common formats are SPDX and CycloneDX. Both are standardized and supported by a growing ecosystem. Tools such as Syft, Trivy, cdxgen, and vendor-specific SBOM generators can produce them. The choice of format matters less than consistency and automation. Pick one format for internal use, and convert when needed for external consumers.

Distribution is as important as generation. Store the SBOM as an artifact alongside the container image or binary. Sign the SBOM so consumers can verify it came from the same trusted pipeline. Publish it to an artifact registry or a dedicated SBOM store. Use immutable references such as digests, not mutable tags.

Consumption turns SBOMs into operational value. When a new CVE is announced, query your SBOM inventory to find affected services in minutes instead of days. Integrate SBOMs with dependency-track, Grype, or your vulnerability management platform. Map components to owners and criticality. Automate alerts for newly disclosed vulnerabilities that match your inventory.

SBOM quality is a real challenge. Dynamic languages can load dependencies at runtime that static analysis misses. Vendored code may hide third-party components. Binary-only dependencies may not expose metadata. False positives from inaccurate version matching can erode trust. Treat SBOM accuracy as a metric and improve it over time. Start with critical services, then expand.

SLSA: A Framework for Build Integrity

SLSA (Supply-chain Levels for Software Artifacts) provides a common language for build integrity. It is not a product or a checklist. It is a framework that describes increasing levels of assurance about how an artifact was produced. The current SLSA v1.0 specification focuses on build levels 0 through 3.

• Level 0: No guarantees. The build process is undocumented and provenance is unavailable.
• Level 1: Provenance exists. The build process is documented and automated, and provenance is distributed to consumers. This level helps with incident response but does not prevent tampering.
• Level 2: Hosted build platform. The build runs on a hosted platform that generates signed provenance. This prevents tampering after the build and provides a trusted identity for the builder.
• Level 3: Hardened build platform. The build environment is strongly isolated, and provenance is non-falsifiable. This prevents tampering during the build, even by insiders with access to the build system.

SLSA is most useful when you map its requirements to concrete controls. Level 1 means you emit provenance. Level 2 means you use a hosted CI/CD service with OIDC-based identity and signed provenance. Level 3 means you run builds in ephemeral, isolated workers with no persistent credentials and no network access to production. Achieving Level 3 is a significant engineering effort, but incremental progress delivers value.

Do not treat SLSA as a silver bullet. It covers build integrity, not dependency risk or code quality. Combine SLSA with SBOMs, vulnerability scanning, and runtime security. A SLSA Level 3 artifact can still contain a vulnerable dependency if the source code included it.

Sigstore: Keyless Signing for the Masses

Signing artifacts has historically been painful. Long-lived private keys must be generated, stored, rotated, and protected. Sigstore changes that model with keyless signing. Instead of managing a private key, a developer or CI job authenticates with an OpenID Connect (OIDC) identity provider such as GitHub, Google, or Microsoft. Sigstore issues a short-lived certificate that binds the signing event to that identity. The signature and certificate are recorded in a transparency log called Rekor.

The main Sigstore components are Cosign, Fulcio, and Rekor. Cosign is the command-line tool for signing and verifying containers and other artifacts. Fulcio is the certificate authority that issues short-lived certificates. Rekor is the immutable transparency log that records signing events. Together they provide a verifiable record of who signed what and when.

Keyless signing removes the burden of long-lived keys, but it introduces new considerations. You must trust the OIDC provider. You must verify the certificate identity and issuer during policy checks. You should monitor the transparency log for unexpected signing events. For environments that cannot use keyless signing, Sigstore also supports hardware-backed keys and KMS-backed keys.

A typical verification policy might require that an image was signed by the GitHub Actions workflow in the organization’s repository, on the main branch, using a specific workflow file. This is much stronger than checking a mutable tag. It ties the artifact to a specific source and build process.

Putting It Together: A Reference Pipeline

A practical supply chain security pipeline combines the building blocks into a series of gates. The following reference architecture works for containerized workloads, but the same principles apply to binaries, packages, and infrastructure as code.

1. Source: Enforce branch protection, require signed commits where practical, enable 2FA for maintainers, and use dependency review on pull requests. Pin GitHub Actions or CI plugins to full commit digests.
2. Build: Use hosted, ephemeral runners. Lock dependencies with lockfiles. Generate an SBOM and provenance during the build. Run tests and vulnerability scans. Produce an attestation that includes the results.
3. Sign: Sign the artifact, SBOM, and attestations with Sigstore keyless signing or a KMS-backed key. Use a consistent identity policy that maps to your organization and repository.
4. Store: Publish to an artifact registry with immutable tags and digest-based references. Retain SBOMs and attestations for at least the lifetime of the artifact.
5. Verify: Use admission controllers such as Kyverno, OPA/Gatekeeper, or Sigstore policy-controller to verify signatures and attestations before deployment. Reject artifacts that do not meet policy.
6. Monitor: Continuously scan SBOMs for new vulnerabilities. Monitor Rekor and your artifact registry for unexpected signing or publishing events. Alert on policy violations.

This pipeline does not require every service to reach SLSA Level 3 on day one. It does require that every artifact has some verifiable evidence, and that high-risk services have stronger controls.

Policy Enforcement: Turning Evidence into Gates

Evidence without enforcement is documentation. Policy as code turns evidence into automated decisions. Policies can be evaluated at build time, at admission time, or continuously at runtime.

Examples of supply chain policies include:

• Deny images without valid SLSA Level 2 provenance.
• Deny dependencies with critical CVEs or prohibited licenses.
• Require an SBOM to be attached and signed.
• Require the build to originate from a trusted builder identity.
• Require attestations for security scans and code review.

Tools such as OPA/Gatekeeper, Kyverno, Sigstore policy-controller, and in-toto provide policy enforcement. Start in audit mode to understand the impact. Fix the pipeline and exception process. Then move to enforce mode for high-risk namespaces or services. A phased rollout reduces friction and prevents developers from bypassing controls.

Threat Modeling the Supply Chain

Map threats to controls. This helps prioritize work and avoid buying tools that do not address your actual risks.

• Dependency confusion: Use namespace scoping, private registries, and allowlists. Configure package managers to prefer internal registries.
• Typosquatting: Use dependency review, lockfiles, and automated pull request checks. Educate developers about package name verification.
• Compromised maintainer: Require 2FA, signed releases, and provenance. Prefer dependencies with active maintenance and transparent governance.
• Build tampering: Use ephemeral isolated runners, SLSA Level 3, and no long-lived credentials. Restrict network access during builds.
• Artifact tampering: Use signatures, immutable registries, and digest pinning. Verify before deployment.
• CI/CD credential theft: Use OIDC and short-lived tokens. Apply least privilege to CI jobs. Never store long-lived cloud keys in repositories.

Practical Implementation Roadmap

A 30-60-90 day plan can move an organization from ad hoc supply chain security to automated verification.

• Days 0-30: Inventory critical services and dependencies. Generate SBOMs for container images and binaries. Enable dependency scanning and Dependabot or Renovate. Enforce MFA for source control and package registries. Pin CI actions by digest.
• Days 31-60: Add provenance generation to CI. Sign artifacts and SBOMs with Sigstore. Deploy verification in audit mode. Establish an exception process with expiration dates. Train teams on reading provenance and SBOM reports.
• Days 61-90: Enforce policy for high-risk services. Move builds to hosted isolated runners. Monitor transparency logs. Run an incident response game day using SBOM data to simulate a new CVE. Measure coverage and time to remediate.

Common Pitfalls and How to Avoid Them

• SBOM theater: Generating SBOMs but never using them. Integrate SBOMs with vulnerability management and incident response.
• Ignoring transitive dependencies: Most risk is indirect. Use lockfiles and SBOM tools that include the full dependency graph.
• Long-lived signing keys: Use keyless signing or hardware-backed keys with rotation. Avoid shared keys in CI secrets.
• No verification at deploy: Signatures only matter if they are checked. Enforce at admission and in deployment pipelines.
• Overly strict policies: Policies that block too much create bypasses. Start in audit mode and iterate with developers.
• Assuming SLSA is enough: SLSA covers build integrity, not dependency vulnerabilities or malicious code. Combine it with SBOMs and scanning.
• Neglecting the source: A secure build cannot fix a compromised source repository. Protect branches, reviews, and maintainer accounts.

Future Directions

Supply chain security is moving from best practice to regulatory requirement. The EU Cyber Resilience Act, US executive orders, and industry standards are pushing for SBOMs, provenance, and vulnerability disclosure. At the same time, AI-generated code and autonomous agents will introduce new provenance questions. Who wrote this code? Which model generated it? Which dependencies did it introduce? Expect attestations to expand beyond build integrity to include AI model cards, training data provenance, and human review records.

Open-source ecosystems are also evolving. Package registries are adding signing and provenance features. Build platforms are making OIDC and ephemeral runners the default. The tooling will improve, but the core principles remain: verify what you consume, verify how it was built, and verify who signed it.

Conclusion

Software supply chain security is a layered practice. SBOMs provide visibility into components. Provenance and SLSA provide assurance about build integrity. Sigstore provides verifiable signatures without the operational burden of long-lived keys. Policy enforcement turns that evidence into automated gates. Start with critical services, automate evidence generation, and enforce incrementally. The goal is not zero risk, but making compromise expensive, detectable, and recoverable.