Software Supply Chain Security in 2026: How SBOMs, SLSA Provenance, and Sigstore Signing Replace Trusting Your Dependencies With Verifying Them

Ask a development team what code is running in production and you will usually get a confident answer about the application they wrote. Ask what else is running - the logging library, the date parser, the four packages that date parser depends on, and the eleven packages underneath those - and the confidence disappears. In a typical modern application, the code the team actually authored is a thin layer on top of hundreds of components it did not. Software supply chain security is the discipline of turning that vague trust into something you can verify: knowing what you ship, where it came from, and whether anyone changed it along the way.

Why the Attack Moved Upstream

Attackers follow leverage. Breaking into one company gets you one company. Compromising a package that ten thousand companies install gets you ten thousand chances, and the victims install it themselves, during a normal build, with no phishing email required.

The recurring patterns are boring and effective. A maintainer account with no multi-factor authentication gets taken over and a malicious version is published. A package name one character away from a popular one collects installs from typos. An internal package name that exists only in a private registry gets registered publicly, and a misconfigured resolver fetches the public one instead - the dependency confusion trick that keeps working years after it was first demonstrated. Or the build system itself is compromised, so the published artifact contains code that never appeared in the source repository at all.

"Reviewing the source code in a repository tells you nothing about the artifact your users downloaded. Those are two different objects, and the gap between them is where supply chain attacks live."

The SBOM: An Inventory You Can Query

A Software Bill of Materials is a structured list of every component in a piece of software, with versions, licenses, and relationships. The two formats that matter are CycloneDX and SPDX, and generating one is genuinely easy - most build tools and container scanners emit an SBOM in a single command.

The value shows up on a bad day. When a serious vulnerability drops in a widely used library, the question every organization scrambles to answer is whether they are affected. Teams without an inventory spend days grepping repositories and interrogating vendors. Teams with SBOMs stored per release answer it with a query, and know not just whether the component is present but which services, which versions, and which customer deployments.

Two honest caveats. An SBOM generated once and filed away is worthless within a sprint - it has to be produced automatically on every build and stored with the artifact. And an SBOM is an inventory, not a verdict: presence of a vulnerable component does not always mean exploitability, which is why VEX documents exist to record that a flagged CVE is not reachable in your configuration.

SLSA: Proving How Something Was Built

SLSA - Supply-chain Levels for Software Artifacts - is a framework for describing how trustworthy a build process is, expressed as ascending levels rather than a pass or fail badge. The core artifact it produces is provenance: signed metadata that states which source commit, which builder, and which inputs produced this specific binary.

The progression is roughly this:

• Build from source control. No releases from a developer machine, ever. Every artifact traces to a commit.
• Generate signed provenance. The build platform, not the developer, attests to what it produced.
• Harden the builder. Isolated, ephemeral build environments so one job cannot poison another and secrets cannot be exfiltrated by build scripts.
• Hermetic and reproducible builds. Fully declared inputs, no network access at build time, and ideally the same inputs producing the same bytes - which lets an independent party rebuild and compare.

Most teams get meaningful risk reduction from the first two steps alone, and both are now close to a configuration change on major CI platforms rather than a bespoke engineering project.

Sigstore and the End of the Key Management Excuse

Code signing has existed for decades and most projects skipped it, for an understandable reason: managing long-lived private keys is genuinely miserable. Where do you store it, who can use it, and what happens when it leaks?

Sigstore removes that problem with keyless signing. Instead of a permanent key, the signer authenticates with an existing identity - a CI workload identity or an account on an identity provider - and receives a certificate valid for a few minutes, just long enough to sign. The signature and certificate are recorded in a public transparency log, so anyone can later verify that a given artifact was signed by a given identity at a given time, and a maintainer can detect a signature they never made.

The practical effect is that signing became free of the operational burden that kept it niche. Container images, language packages, and release binaries can all carry verifiable signatures with a few lines of pipeline configuration, and clusters can be configured to refuse anything that fails verification.

The Honest Trade-Offs

This is not free. Scanners produce large volumes of findings, many of them unreachable in your actual code paths, and a team that treats every CVE as an incident will burn out and start ignoring the tool - triage discipline matters more than scanner choice. Verification adds a failure mode to deployment, so the day a certificate or policy is misconfigured, releases stop. Reproducible builds remain hard for some ecosystems. And provenance proves where an artifact came from, not that the code inside it is safe: a perfectly signed package from a compromised maintainer is still malicious, which is why signing complements review rather than replacing it.

Regulation is also pushing this forward. The EU Cyber Resilience Act places obligations on products with digital elements to document components and handle vulnerabilities, and public sector procurement in several markets now asks for SBOMs by default. Increasingly, vendors are being asked for this material during security reviews - which means it shows up in sales cycles, not just security audits.

Why This Matters for Smaller Teams Too

It is tempting to file this under enterprise concerns, but the exposure is the same at any size. A small agency shipping a client site pulls in the same public packages as a bank, from the same registries, with the same maintainer accounts. The difference is that the small team usually has no inventory, no signing, and no way to answer a client asking whether last week’s widely reported vulnerability affects them.

Start with the cheap wins: lockfiles committed, dependencies updated on a schedule instead of in a panic, CI actions pinned, and an SBOM produced on every build. Those four take an afternoon, and they move you from hoping nothing upstream went wrong to being able to check.

Need help hardening your build pipeline or answering a client security questionnaire? Explore our development and security services or contact us for a review of your deployment process.