The State of the Software Supply Chain 2026

SBOMs, signing, SLSA, and provenance are moving from compliance checkbox to default CI step, and the part most teams still miss is the integrity of the build environment that produces them.

Executive summary

The software supply chain, the chain of dependencies, build steps, and artifacts between a commit and a deployed binary, became a board-level concern after a run of high-profile compromises, and the industry response has standardized around a small set of CI-native controls. Generate a software bill of materials so you know what is in an artifact. Sign the artifact and the SBOM so consumers can verify they have not been tampered with. Emit verifiable build provenance so you can prove how the artifact was produced. The OpenSSF and the SLSA framework give these practices a common vocabulary and a ladder of maturity levels.

Adoption of these controls is real but uneven, and the unevenness is instructive. SBOM generation and dependency scanning have spread fastest because they are the cheapest to bolt on, a single pipeline step with no key management and no change to the build environment. Signing lags because it touches keys and identity. End-to-end provenance lags furthest because it makes a claim about the build itself, and a claim is only as trustworthy as the thing producing it.

This report quantifies how far each control has spread across CI pipelines, what each one adds to build time and cost, and where the coverage stops. The recurring finding is that the per-step time cost is modest, measured in tens of seconds, so wall-clock is rarely the real blocker. The harder and more often-missed problem is the integrity of the build environment: a shared, long-lived, mutable build host quietly undermines every attestation produced on it, no matter how carefully the signing steps are wired.

Three numbers frame the year. A small majority of CI pipelines now generate an SBOM on at least some builds, the cheapest control to adopt. Under a third of release pipelines emit SLSA-style provenance, the control that actually proves how an artifact was built. And the controls live on the CI/CD surface that the Stack Overflow Developer Survey puts at roughly three quarters of professional developers, which makes the reliability of those controls a supply-chain property in its own right.

The throughline for engineering and security leaders is that the supply chain is not secured by adding steps to an untrustworthy pipeline. It is secured by making the pipeline itself trustworthy, ephemeral, single-use, reproducible, and then attaching the controls to it. Managed runners that are ephemeral by default deliver the environment integrity that the higher SLSA levels ask for, which reframes the runner choice as a supply-chain decision rather than only a cost one.

SBOMs are common, provenance is not

SBOM generation and dependency scanning have spread fast because they bolt onto an existing pipeline as a single step with no key management and no change to how the build runs. You add a tool, it inspects the dependency graph, and it emits a list. That low friction is why these two controls sit at the top of the adoption chart, with a small majority of pipelines generating an SBOM and even more running a dependency scanner on at least some builds.

Signing and SLSA provenance sit lower because they ask for more. Signing requires trusted identity and key handling, even with the keyless patterns the OpenSSF ecosystem has standardized around. Provenance requires a build environment you can actually vouch for, because the attestation is a claim about how the artifact was produced. The result is a long tail of pipelines that can tell you what is inside an artifact but cannot prove how it was built.

OpenSSF guidance frames provenance as the step that closes that gap, and the adoption curve by org size shows the gap closing slowly and from the top down. Larger engineering organizations emit provenance at meaningfully higher rates than small ones, which tracks both their compliance exposure and their access to platform engineering capacity. The control that matters most is the one that has spread least, and that is the central tension of the 2026 supply-chain picture.

• SBOM and dependency scanning lead adoption because they are single steps with no key management.
• Signing lags because it needs trusted identity; provenance lags furthest because it needs a vouched-for build environment.
• Provenance adoption climbs with org size, closing the gap slowly and from the largest teams down.

Provenance adoption tracks org size and platform capacity

The provenance-by-org-size curve rises steeply: solo and very small teams emit SLSA-style provenance only rarely, mid-size engineering organizations do so at a moderate rate, and the largest cohort is the clear leader. This is not because small teams care less about security. It is because provenance is the control that most depends on platform investment, and platform investment scales with headcount.

Emitting trustworthy provenance means controlling the build environment, wiring identity into the pipeline, and maintaining the attestation tooling, all of which are easier when there is a platform team to own them. A two-person team can add a scanner in an afternoon; standing up a vouched-for, reproducible build environment with attached provenance is a project. The adoption gap by size is really a capacity gap.

The implication is that anything which lowers the platform cost of a trustworthy build environment pulls provenance adoption down-market. If the environment integrity the higher SLSA levels require comes by default from the runner layer rather than from a hand-built pipeline, the control stops being a large-org luxury. That is the lever this report keeps returning to, because it is the one that changes the shape of the curve rather than just nudging it.

The controls are cheap in time; the build environment is the weak link

Adding SBOM generation, signing, and provenance to a release build costs a modeled tens of seconds, not minutes. SBOM generation lands around twenty seconds, signing is faster, provenance attestation a bit more, and the full chain together is well under two minutes of added wall-clock on a typical release build. Wall-clock is therefore rarely the real reason a team stops short; the cost is not where the resistance comes from.

The harder problem is that provenance is only as trustworthy as the environment that produces it. A shared, long-lived, mutable build host undermines the attestation no matter how carefully the steps are wired, because an attacker who can influence that host can influence what gets attested. Signing an artifact built on a contaminated runner produces a perfectly valid signature over a compromised binary. The cryptography is fine; the premise is not.

This is why the higher SLSA levels emphasize the build platform itself, not just the outputs. Ephemeral, single-use build environments are what make provenance meaningful, because a runner that exists for exactly one build and is destroyed afterward cannot carry contamination into the attestation. The time cost of the controls is a distraction from the real question, which is whether you can vouch for the machine that ran them.

Ephemeral runners are a supply-chain control, not just a cost choice

A runner that is provisioned fresh for one job and destroyed after it cannot carry contamination from a previous build, cannot accumulate tampered tooling across runs, and gives every attestation a clean, reproducible base. Those three properties are exactly what SLSA's higher levels ask for from the build platform, which means the runner sourcing decision is a supply-chain decision whether or not it is framed that way.

On a long-lived shared runner, by contrast, the build environment is a standing surface. State persists between jobs, credentials linger, and a single compromised build can leave residue that the next build trusts. No amount of signing downstream fixes a build platform that an attacker can quietly influence, because the signature attests to whatever was actually built, contamination included.

Managed runners that are ephemeral by default deliver the clean-base property without a platform team hand-building disposable images and proving their teardown is airtight. That matters most for exactly the teams the adoption curve shows lagging: the ones without the platform capacity to engineer environment integrity themselves. Getting it as a default rather than a project is what makes the strongest part of the supply chain reachable for smaller teams.

• A fresh, single-use runner cannot carry contamination, tampered tooling, or leftover credentials between builds.
• Those three properties are what SLSA's higher build-platform levels ask for, so the runner choice is a supply-chain choice.
• Ephemeral-by-default managed runners deliver environment integrity without a platform team hand-building disposable images.

Most teams stop at what and never reach how

The largest single cohort in the coverage split generates an SBOM or runs a scanner and considers the supply chain handled. They can enumerate the dependencies in an artifact, which is genuinely useful, but they never add signing or provenance, so they cannot prove the artifact was not tampered with after the build or vouch for how it was produced. They know what is inside and nothing about how it got there.

This is the 'scan or SBOM only' band, and it is the modal state of supply-chain security in 2026. The next bands, adding signing and then a full provenance chain, fall off sharply, which means most pipelines have answered the easy half of the question and stopped at the boundary where keys, identity, and environment integrity begin. The gap is not awareness, it is the cost of the next step.

Closing it is incremental rather than a rewrite. Sign the SBOM and the artifact first, reusing the keyless signing patterns the OpenSSF ecosystem has standardized, then layer provenance attestation on top, anchored to a build environment you can vouch for. Each step is additive and each is modest in time. The teams that stall do so at the environment-integrity boundary, which is precisely where an ephemeral runner layer removes the hardest part of the work.

Flaky security steps get disabled, which is the worst outcome

When a signing or attestation step fails transiently, a registry timeout, an identity-provider blip, a network hiccup reaching a transparency log, the failure lands on a team under release pressure. The path of least resistance is to make the step non-blocking or remove it so the release can ship, which quietly drops the control entirely. A security step that is required but flaky tends to become a security step that is optional and then absent.

The cruel part is that most of those failures are mechanical and pass on a clean retry. The signing step was not wrong; the registry was briefly unreachable. Treating a transient infrastructure failure as a reason to disable a control is a rational response to an unreliable pipeline and a terrible outcome for the supply chain, because the control disappears precisely when the pressure to ship is highest.

Automated recovery at the runner layer keeps these steps reliable enough to stay required. When a security step fails on a known-transient signal, the platform retries it on a fresh environment before a human decides to rip it out under deadline. The same CI/CD adoption that now covers roughly 76 percent of professional developers is the surface these controls live on, so their reliability is itself a supply-chain property: a control that is flaky enough to get disabled provides no protection at all.

Provenance is only worth as much as its verification

Producing provenance is half the chain; consuming it is the other half. An attestation that no downstream step verifies is documentation, not a control. The 2026 picture skews heavily toward production, because emitting an SBOM or a provenance statement is a single CI step, while verifying one at deploy or admission time requires policy, tooling, and a place to enforce it.

The OpenSSF and SLSA framing is explicit that the value is realized at the verification boundary: a gate that refuses to deploy an artifact whose provenance does not meet a required level, or whose signature does not verify against an expected identity. Without that gate, an attacker can simply supply an artifact with no provenance, or weaker provenance, and a pipeline that only produces but never checks will happily carry it forward.

For teams building toward a real supply-chain posture, the sequence is produce, then verify, then enforce. Produce the SBOM, signature, and provenance on a trustworthy build environment; verify them at the boundary where artifacts enter the next stage; and enforce a policy that fails closed when verification fails. The environment integrity this report keeps emphasizing underpins all three, because verification of an attestation produced on an untrustworthy host certifies the contamination along with the artifact.

Recommendations

Adopt the chain in order: SBOM, signing, then provenance

The cheap controls come first for a reason. Generate an SBOM and run a scanner, then sign the SBOM and the artifact using keyless patterns from the OpenSSF ecosystem, then layer provenance attestation. Each step is additive and modest in time, so the path from "what" to "how" is incremental rather than a rewrite.

Treat the build environment as part of the supply chain

Provenance signed on a shared, long-lived, mutable host attests to whatever was built, contamination included. Run release builds on ephemeral, single-use environments so every attestation has a clean, reproducible base. This is the part of SLSA the higher levels actually hinge on, and the part adoption most often skips.

Verify and enforce, do not just produce

An attestation nobody checks is documentation. Add a verification gate at the boundary where artifacts enter the next stage, and make it fail closed when provenance or signatures do not meet the required level. Production without verification leaves the door open to an artifact that simply omits the attestation.

Keep security steps reliable so they stay required

A flaky signing or attestation step gets made non-blocking under release pressure, which silently drops the control. Most of those failures are transient and pass on retry. Automated recovery at the runner layer keeps the steps green enough that nobody disables them when it matters most.

Lower the platform cost so provenance reaches smaller teams

Provenance adoption tracks org size because environment integrity has been a platform-team project. Getting an ephemeral, vouched-for build environment by default from the runner layer removes the hardest part of the work, which is what pulls the strongest controls down-market to teams without dedicated platform staff.

Outlook

Expect SBOM generation to approach ubiquity and the harder controls to keep climbing from the top of the market down. Regulatory pressure, customer security questionnaires, and framework guidance from the OpenSSF and SLSA will continue to push signing and provenance from optional to expected, especially for teams that ship software others depend on. The direction is not in question; the pace is gated by how cheap the next step becomes.

The decisive variable is the platform cost of a trustworthy build environment. As ephemeral, reproducible build platforms become a default property of the runner layer rather than a hand-built project, the environment-integrity boundary where most teams stall today moves out of the way. That is what turns provenance from a large-org capability into a reachable one for the mid-market, and it is why the runner decision and the supply-chain decision are converging into a single choice.

For engineering and security leaders the practical takeaway is that securing the supply chain is not about stacking more steps onto an untrustworthy pipeline. It is about making the pipeline trustworthy first, ephemeral, single-use, reproducible, and then attaching the controls and verifying them at the boundary. The teams that internalize that will find the full chain is closer and cheaper than the adoption gap suggests, because the expensive part was never the steps, it was the environment underneath them.

Methodology

This report synthesizes publicly available supply-chain security guidance (OpenSSF, the SLSA framework) and developer survey data with Latchkey's own analysis of CI build economics. Control-adoption shares, per-control time overhead, and the coverage split are modeled estimates derived from typical release-pipeline shapes, framed against OpenSSF and SLSA definitions, not a primary survey. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• OpenSSF
• Stack Overflow Developer Survey
• CNCF Annual Survey
• GitHub Actions documentation

More Latchkey reports