Software Supply Chain Security: How to Implement SBOM, SLSA, and Sigstore in 2026

Software supply chain security is the practice of protecting every artifact your engineering team produces — from source code and open-source dependencies through build pipelines, artifact registries, and deployment targets. In 2025, supply chain attacks more than doubled globally, with over 70 percent of enterprises reporting at least one incident linked to third-party software. Attackers have learned that the build system is a far softer target than the application itself — and in 2026, teams that harden their application perimeter but leave their pipeline unguarded are defending the wrong surface. If your team already has CI/CD security tooling in place, our DevSecOps pipeline guide covers the shift-left baseline; this post covers the layer above it: artifact provenance, dependency transparency, and cryptographic trust.

Three standards have converged as the enterprise baseline for software supply chain security in 2026: SBOM (Software Bill of Materials), SLSA (Supply-chain Levels for Software Artifacts), and Sigstore. Each answers a distinct question. SBOM answers: what is in your software? SLSA answers: how was it built, and can you prove it? Sigstore answers: is this artifact the same one that was built and signed — untampered, from a known identity? Together they close the three gaps that supply chain attackers exploit: opaque dependency trees, unverified build origins, and unsigned artifacts.

This guide covers all three standards in depth — what each does, how they complement each other, the tools to implement them, and a phased enterprise roadmap from zero visibility to SLSA Level 3. It also covers the regulatory landscape: the EU Cyber Resilience Act and U.S. Executive Order 14028 have made SBOM practices a compliance requirement for organizations shipping or procuring enterprise software, and the implementation clock is running.

What Is Software Supply Chain Security?

Software supply chain security is the set of practices that protects the integrity of every component in your software's path from source to production. The supply chain is not a metaphor — it is a literal sequence of systems: the source repository where code is committed, the dependency registry where packages are fetched, the CI/CD build system that compiles and tests, the artifact registry where images and binaries are stored, and the deployment system that ships them to production. An attack at any point in that chain can introduce malicious code without touching a single line of your own source.

• →Source code attacks: adversaries compromise developer accounts or merge malicious pull requests to inject backdoors directly into the codebase — targeting the repository before the build even runs
• →Dependency confusion and typosquatting: malicious packages published with names close to internal packages, tricking automated installers into pulling attacker-controlled code from public registries instead of private ones
• →Build system compromise: attackers gain access to CI/CD infrastructure and inject malicious steps into the build process — the code looks clean in source control, but the compiled binary is not what was reviewed
• →Artifact tampering: a legitimate artifact is replaced in a registry with a modified version after it was built — without cryptographic verification at deploy time, the swap is invisible to the deployment pipeline
• →Malicious maintainer attacks: legitimate open-source maintainers turn malicious or have their accounts compromised, allowing poisoned package updates to flow through normal update channels to thousands of downstream consumers

Why Software Supply Chain Attacks Are Accelerating

Sonatype identified over 454,600 new malicious packages in 2025 alone, bringing the cumulative total past 1.2 million. Supply chain attacks are now the fastest-growing vector in enterprise breaches because economics favor the attacker: compromise a widely used library once and you get code execution in thousands of downstream applications simultaneously. The XZ Utils backdoor in 2024 — a two-year social engineering campaign that nearly inserted a cryptographic backdoor into the SSH daemon of every major Linux distribution — demonstrated both the sophistication and the scale of what targeted supply chain attacks can achieve.

• →Supply chain attacks more than doubled globally in 2025 — over 70% of organizations reported at least one incident linked to third-party software or build infrastructure
• →The average enterprise application imports over 500 direct and transitive open-source dependencies — each is a potential attack surface that the team did not write, review, or control
• →AI-generated code accelerates the exposure: AI coding assistants frequently suggest deprecated or vulnerable packages, and AI-assisted commits introduce hardcoded credentials at twice the rate of human-only code
• →Regulatory urgency is forcing action: the EU Cyber Resilience Act requires SBOMs for connected products sold in the EU by 2027; U.S. Executive Order 14028 requires SBOMs from federal government software vendors now
• →Attacks increasingly target CI/CD infrastructure rather than applications directly — a pipeline compromise is quieter, more persistent, and harder to detect than a runtime application vulnerability

SBOM: Know What Is in Every Artifact You Ship

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component, library, and dependency inside a software artifact — including version numbers, origins, licenses, and hash identifiers. It is the ingredient list for your software. Without one, you cannot answer the question a new CVE forces on every engineering team: which of our production applications is affected? With an SBOM, you can query your entire artifact inventory in minutes and identify exposed systems before an attacker does.

• →Generate SBOMs at build time, not after deployment — at build time, the full dependency graph is resolved and captured accurately; post-deployment generation misses transitive dependencies and fails on compiled artifacts where source is no longer available
• →SPDX and CycloneDX are the two standard SBOM formats — SPDX is the ISO standard (ISO/IEC 5962:2021) preferred in regulatory contexts; CycloneDX is more widely adopted in tooling and preferred for security use cases with richer vulnerability metadata support
• →Syft (Anchore) is the most widely deployed SBOM generator in 2026 — a single command generates a complete SBOM for any container image, filesystem, or binary in SPDX or CycloneDX format
• →Trivy (Aqua Security) generates SBOMs as part of its container and filesystem scanning workflow — useful when you want SBOM generation and vulnerability scanning in a single pipeline step without adding a separate tool
• →Store SBOMs in your artifact registry alongside the artifact they describe — OCI-compliant registries (ECR, GCR, GitHub Container Registry) support SBOM attachment as OCI artifacts, keeping the inventory and the artifact co-located
• →Grype (Anchore) matches SBOM components against NVD, GitHub Advisories, and OS vendor databases — run it in CI to block builds with critical CVEs and as a scheduled job to surface new vulnerabilities in already-deployed artifacts when new advisories are published

SLSA: Cryptographic Proof of How Your Software Was Built

SBOM tells you what is in your software. SLSA (Supply-chain Levels for Software Artifacts, pronounced 'salsa') tells you how it was built — and provides cryptographic proof that the build process was authorized and unmodified. SLSA is a framework from the Open Source Security Foundation (OpenSSF) that defines build integrity guarantees in three levels. Each level closes a specific attack vector in the build pipeline that the level below it leaves open.

• →SLSA Build Level 1: the build process generates a provenance document describing what was built, from which source commit, by which build system. The document is unsigned and self-attested — it raises the cost of undetected tampering but provides no cryptographic guarantee against a determined attacker who controls the build
• →SLSA Build Level 2: the provenance is signed by the build service using its own cryptographic key, not the developer's. An attacker cannot forge a Level 2 provenance without compromising the build service itself — which is a far harder target than a developer machine or repository secret. Achievable in days for most teams using GitHub Actions with the slsa-github-generator action
• →SLSA Build Level 3: the build runs in an isolated, ephemeral, hardened environment; network access during builds is restricted to prevent exfiltration of source or injection of external code; the provenance is non-falsifiable because the signing key is held exclusively by the build platform and never accessible to the build worker. This level defeats a compromised build worker — the worker cannot produce valid provenance for a modified artifact even with local access
• →The slsa-github-generator action produces SLSA Level 3 provenance on GitHub Actions out of the box — maintained by the OpenSSF and using GitHub's Sigstore-based artifact attestation infrastructure; teams with standard GitHub Actions workflows can reach Level 2 in an afternoon

SLSA provenance is consumed at deploy time: before promoting an artifact to production, your deployment pipeline verifies the provenance against the expected builder identity, source commit, and build workflow. An artifact built outside your authorized pipeline, or modified after it was built, fails provenance verification and is blocked from deployment. For teams running Kubernetes, admission controllers like Kyverno and OPA Gatekeeper can enforce SLSA provenance verification at the cluster level, connecting supply chain security to your broader zero trust security architecture and ensuring no workload enters any namespace without verified build provenance.

Sigstore: Keyless Artifact Signing at Enterprise Scale

Sigstore is an open-source project (Linux Foundation) that provides the cryptographic signing infrastructure underlying SLSA provenance and artifact attestations. It solves the key management problem that has historically made artifact signing impractical at enterprise scale: managing long-lived private keys that can sign artifacts is operationally complex, and a leaked key is a silent compromise — you cannot know an artifact is untrusted until an incident reveals the key was stolen months earlier.

• →Keyless signing with Sigstore: instead of a long-lived private key, Sigstore uses short-lived OIDC tokens from your CI provider — GitHub Actions, GitLab CI, or Google Cloud. The token authenticates to Fulcio (the Sigstore certificate authority), which issues a short-lived signing certificate bound to the workflow identity. The private key exists for milliseconds, signs the artifact, and is discarded. There is no key to rotate, store, audit, or leak
• →Cosign is the Sigstore command-line tool for signing and verifying container images, OCI artifacts, SBOMs, and SLSA provenance attestations. A single cosign sign command in a GitHub Actions workflow signs the image using the workflow's verified GitHub identity — the only configuration required is enabling the OIDC token permission in the workflow YAML
• →Rekor is the Sigstore transparency log — a tamper-evident, append-only ledger of every signing event. Every cosign signature is logged in Rekor automatically. Anyone can query Rekor to verify that a given artifact was signed by a given identity at a given time, making supply chain claims independently verifiable rather than self-attested
• →Fulcio is the Sigstore certificate authority that issues short-lived signing certificates bound to verified OIDC identities. The certificate binds the cryptographic key to the identity (a GitHub Actions workflow URL, a Google service account, or a human email), so verification is against a readable, auditable identity rather than an opaque key fingerprint
• →Cosign verify at deploy time checks that the image digest, the signing identity, and the Rekor transparency log entry are all consistent — a tampered image or a missing log entry both fail verification, blocking deployment and generating an alert

The Enterprise Implementation Roadmap: Zero to SLSA Level 3

Enterprise software supply chain security follows a phased progression. Attempting all three standards at Level 3 simultaneously from a standing start stalls most teams. The correct path is sequential: visibility first, then integrity guarantees, then policy enforcement. This roadmap assumes you already have a CI/CD pipeline with the shift-left security practices from our DevSecOps implementation guide in place. If you do not, start there — SBOM, SLSA, and Sigstore build on top of a functioning DevSecOps baseline, not in place of one.

• →Weeks 1–4, SBOM Visibility: instrument your ten highest-risk production applications with Syft SBOM generation at build time. Attach SBOMs to container images as OCI artifacts in your registry. Integrate Grype into CI to block builds with critical CVEs and run nightly advisory scans against deployed artifacts. By the end of this phase you will know your real exposure — most teams find vulnerabilities they did not know existed, including in base images they assumed were maintained
• →Weeks 5–8, Artifact Signing: integrate cosign into every container image build workflow using Sigstore keyless signing with your CI provider's OIDC identity. Configure deployment pipelines to require a valid cosign signature before promoting any image to a non-development environment. All unsigned images are blocked. This phase closes the artifact integrity gap and sets up the verification infrastructure SLSA provenance will use
• →Months 3–4, SLSA Level 1–2: add the slsa-github-generator to build workflows for your most critical services. Begin verifying SLSA provenance at deployment time using cosign verify-attestation against your expected builder identity and source repository. Block any deployment where provenance cannot be verified
• →Months 5–6, SLSA Level 3 for Critical Systems: enable ephemeral, isolated build environments with restricted network access for your highest-risk applications. This is the most operationally complex phase and is typically scoped to production-critical services first — payment processing, authentication, data pipelines — with broader portfolio rollout following once the pattern is established
• →Ongoing, Policy Enforcement: deploy Kyverno or OPA Gatekeeper to Kubernetes clusters with policies that enforce SBOM attestation presence, valid Sigstore signatures, and minimum SLSA level for production namespaces. Supply chain security becomes automatic at the admission layer — no team member needs to remember to verify; the cluster does it on every deployment

Regulatory Compliance: EU CRA, Executive Order 14028, and NIST SSDF

Software supply chain security has moved from engineering best practice to regulatory mandate faster than most enterprise legal and compliance teams anticipated. If your organization sells software to the U.S. federal government, SBOM delivery is already required under Executive Order 14028 (May 2021) and the associated OMB memoranda. If your organization sells connected products in the European Union, the EU Cyber Resilience Act requires demonstrable software supply chain security practices — including SBOMs — for market access by 2027. For organizations pursuing DevSecOps maturity through audit frameworks, SLSA provenance maps directly to the NIST Secure Software Development Framework (SSDF) practices in the Produce Well-Secured Software (PS) and Respond to Vulnerabilities (RV) families. The implementation work your team does for security becomes your compliance evidence: the SBOM is the artifact inventory an auditor needs, the SLSA provenance is the tamper-evident record of build integrity, and the Sigstore transparency log is the cryptographic audit trail. Our security and scalability services include supply chain security implementation alongside the compliance posture assessment that maps your current pipeline to specific regulatory requirements.

Frequently Asked Questions

What is a software supply chain attack?

A software supply chain attack targets any component in the path from source code to production — third-party dependencies, build systems, artifact registries, or deployment pipelines — rather than the application itself. Instead of exploiting a vulnerability in your code, attackers inject malicious code at a point where it flows naturally into your software: a compromised open-source package your build pulls automatically, a backdoored CI step that modifies a binary after the source review, or a tampered container image in a registry your deployments pull from without signature verification.

What is the difference between SBOM and SLSA?

SBOM (Software Bill of Materials) answers: what is in your software? It is a machine-readable inventory of every component, library, and dependency, enabling vulnerability response, license auditing, and regulatory compliance. SLSA (Supply-chain Levels for Software Artifacts) answers: how was your software built, and is there cryptographic proof? SLSA provides verifiable provenance that the artifact was produced by a specific builder from a specific source commit without tampering. SBOM is the ingredient list; SLSA is the food-safety certification for how those ingredients were assembled. Both are required; neither substitutes for the other.

How long does it take to implement SLSA Level 3?

SLSA Level 1 and Level 2 are achievable in days to weeks using the slsa-github-generator on GitHub Actions — Level 2 essentially comes for free once you adopt the generator and enable OIDC token permissions. SLSA Level 3 requires hardened, ephemeral build environments with restricted network access, which is meaningful infrastructure work: 3 to 6 months for most enterprises when implementing across their application portfolio. The practical approach is to reach Level 2 broadly and Level 3 for the highest-risk production services first, then expand Level 3 coverage progressively to the rest of the portfolio.

Does generating an SBOM replace vulnerability scanning?

No — SBOM and vulnerability scanning are complementary, not substitutes. An SBOM is an inventory document; vulnerability scanning is the process of matching that inventory against databases of known vulnerabilities (NVD, GitHub Advisories, OS vendor advisories). You need the SBOM to know what to scan, and you need the scanner (Grype, Trivy, Snyk) to know what is vulnerable. The SBOM also provides value beyond point-in-time scanning: it enables immediate impact assessment when a new CVE is published against a known component, supports license auditing across your portfolio, and serves as the compliance artifact regulators and enterprise customers increasingly require. Think of SBOM as the inventory infrastructure that makes vulnerability management faster and more reliable, not a replacement for the scanning itself.

Is Sigstore free to use in enterprise environments?

Sigstore is free and open source. The public instance of Fulcio (the CA) and Rekor (the transparency log) is operated by the Open Source Security Foundation at no cost. For enterprise teams with air-gapped environments, private network requirements, or compliance constraints around transparency log data residency, Sigstore can be self-hosted — this requires infrastructure work but removes the dependency on the public instance. GitHub Enterprise's built-in artifact attestation feature uses Sigstore infrastructure under the hood and is included in GitHub Enterprise pricing, making it the lowest-friction path to Sigstore adoption for teams already on GitHub.

How Belsoft Helps with Software Supply Chain Security

Belsoft implements end-to-end software supply chain security for enterprise engineering teams — from SBOM generation pipelines and vulnerability dashboards through Sigstore artifact signing, SLSA provenance attestation, and policy enforcement at the Kubernetes admission layer. We have helped teams move from zero supply chain visibility to verified artifact signing and SLSA Level 2 provenance across their application portfolio in a single quarter, while simultaneously building the compliance evidence trail for EU CRA and U.S. federal SBOM requirements. If your organization is facing a supply chain security assessment, an enterprise customer SBOM requirement, or a regulatory deadline, our security and scalability practice is the starting point — or book a technical consultation to walk through your specific pipeline, compliance context, and implementation roadmap with our team.

“You cannot protect what you cannot inventory. SBOM is not a compliance checkbox — it is the prerequisite for every supply chain security decision that comes after it.”