The State of CI/CD Security 2026

The pipeline is the soft target: it holds production credentials, runs untrusted third-party code, and in 2026 it is where supply-chain attacks increasingly walk in.

Executive summary

The CI/CD pipeline is one of the highest-value targets in a software organization and one of the least hardened. It holds credentials to production, pulls untrusted dependencies on every run, and executes third-party actions, frequently on shared runners, so a single compromised step can reach far beyond the repository it started in. Attackers have noticed. Over the last few years the build pipeline has gone from an afterthought in threat models to a primary route in, and 2026 is the year that shift became impossible to ignore.

The data in this report tracks four fronts, because the pipeline is not attacked in one place. Secrets are still too often long-lived and static, sitting in pipeline configuration where a single leak is permanent until a human rotates it. OIDC and short-lived credentials are spreading fast but are nowhere near universal, which leaves a large fraction of pipelines on the old standing-target model. Runner isolation varies wildly, with shared and reused runners creating cross-job exposure that one poisoned dependency is enough to exploit. And provenance, the signed record of how an artifact was built, remains rare, so most software still cannot prove where it came from.

What ties these four fronts together is that most of them are decided by the runner rather than by the application. Whether a job runs with a long-lived key or a minted token, whether one job can observe the next, and whether the build environment is trustworthy enough to sign for are all properties of where and how the job executes. That is why the runner layer is where much of pipeline security is won or lost, and why hardening it addresses several risk categories at once.

Three numbers frame the year. A majority of pipelines still inject at least one long-lived static secret, the unforced error of pipeline security. OIDC has climbed to roughly two in five cloud-auth workflows, a strong trajectory but a large remaining tail. And only about one in six build artifacts ships with verifiable provenance, which means the supply-chain assurance that regulators and large buyers are starting to demand is, for most of the ecosystem, not yet being produced.

The reassuring part is that the highest-leverage fixes are not rewrites. Moving off static secrets to short-lived OIDC tokens, pinning third-party actions to a digest, running each job in a fresh isolated environment, and emitting provenance from the build are well-understood controls, and several of them come for free with a runner platform that is ephemeral and credential-aware by default. The teams that adopt that posture close whole classes of incident without standing up a security engineering function they do not have.

Static secrets are the unforced error of pipeline security

Most pipelines still inject at least one long-lived secret, and a long-lived secret in CI is a permanent liability in a way a short-lived one is not. The moment it leaks, through a log line, a pull request from a fork, a compromised action, or a misconfigured cache, it stays valid until a human notices and rotates it. The window of exposure is not the duration of the job; it is the duration until someone happens to find out, which can be never.

What makes this an unforced error rather than a hard problem is that the alternative is mature and widely available. Short-lived OIDC credentials remove the standing target entirely. Instead of a stored key that any step can read and any leak can exfiltrate, the job mints a token scoped to exactly what it needs, the cloud provider trusts it because of a verifiable identity claim, and the token expires minutes later. There is nothing durable to steal.

The credential-handling chart shows the gap plainly. A majority of pipelines still rely on a long-lived static secret, a smaller group rotate their static secrets on a schedule, which narrows the window without closing it, and a growing but still minority share have moved to OIDC or a dynamic secrets system. Moving off static secrets is the highest-leverage single change most teams can make, because it converts a permanent liability into a transient one.

• A leaked long-lived secret stays valid until a human rotates it, so the exposure window is unbounded.
• Rotation narrows the window but never closes it; a key is still readable for its whole lifetime.
• OIDC mints a job-scoped token that expires in minutes, leaving nothing durable to exfiltrate.

OIDC is winning but the long tail is large

Keyless authentication via OIDC has gone from niche to mainstream in a remarkably short span. The modeled adoption curve climbs steadily year over year, from a small early-adopter share to roughly two in five cloud-auth workflows in 2026. That is one of the faster security migrations the ecosystem has seen, driven by first-class support in the major CI platforms and clear guidance from cloud providers.

But a trajectory that good still leaves a large absolute tail, and the tail is where the risk concentrates. The pipelines that have not converted are disproportionately the older, less-maintained workflows, the ones nobody has touched in a year because they still work. Those are exactly the pipelines least likely to be watched, least likely to have their secrets rotated, and most likely to be carrying a credential that has been valid and unaudited for a very long time.

The lesson of the adoption curve is therefore not just that OIDC is winning, but that the remaining migration is the hard and important part. The easy conversions, the actively maintained pipelines whose owners read the security guidance, have largely happened. Closing the rest means finding the forgotten workflows and the standing keys they carry, which is tedious inventory work that pays off precisely because those are the pipelines a single leak would hurt most.

Most supply-chain risk enters before your code runs

When pipeline exposure is broken down by vector, the largest shares come from code the team did not write and often did not review. Unpinned third-party actions lead, followed closely by transitive dependencies, both pulled fresh on every run from sources outside the team's control. The pipeline is, by design, an execution engine for other people's code, and that is exactly what makes it such a productive target.

An unpinned action is the cleanest example. A workflow that references an action by a moving tag rather than a content digest is trusting whatever that tag points at on the day the job runs, which can change between this morning and this afternoon without any change in the repository. A maintainer account compromise, or a malicious update to a popular action, propagates instantly into every pipeline that did not pin. Pinning to a digest converts that open-ended trust into a fixed, reviewable dependency.

Transitive dependencies and base images extend the same problem one layer deeper. The package you imported imported something else, and the base image you built on shipped something you never inspected. The controls that address the bulk of this are unglamorous and effective: pin actions to a digest, vet and lock dependencies, scan and pin base images, and isolate the runner so that even a malicious step cannot reach the rest of the build or the next job. The chart makes the priority order clear, because it shows where the exposure actually concentrates.

• Unpinned third-party actions and transitive dependencies are the two largest vectors.
• A moving tag trusts whatever it points at on run day; a digest pin makes the dependency fixed and reviewable.
• Runner isolation is the backstop that contains a malicious step once one slips through.

Runner isolation is wildly uneven

A meaningful share of pipelines still run on shared or persistent runners where one job can observe or affect another. That is precisely the foothold a compromised dependency or a poisoned cache needs: it does not have to break out of the job it landed in, it only has to wait for the next job to run on the same machine and read what was left behind. State that bleeds between jobs is both a reliability problem and a security one.

The isolation chart shows the spread. Only about a third of pipelines run in an ephemeral, isolated-per-job model where a fresh environment is created for the job and destroyed afterward. The rest run on shared hosted runners that are reused across jobs, on persistent self-hosted runners that accumulate state, or, for a small but real share, on self-hosted runners with no meaningful isolation at all. Each step away from per-job isolation widens the cross-job attack surface.

The important property of isolation is that it is architectural, not procedural. A team cannot reliably achieve per-job isolation by being careful; it is a property of the runner platform. A managed runner that provisions a clean, single-use environment for each job and tears it down afterward eliminates cross-job exposure as a class, with no cleanup scripts to maintain and no way for one job's residue to reach the next. That is the same isolation that removes a whole category of flaky failures, which is why the security and reliability stories keep pointing at the same architecture.

Per-job isolation removes a whole class of incident

It is worth dwelling on what per-job isolation actually buys, because it is the single architectural choice that closes the most attack paths at once. When every job runs in a fresh environment that is destroyed afterward, a compromised step has nowhere to persist. It cannot poison a cache that a later job will trust, cannot leave a malicious binary on the runner for the next workload to pick up, and cannot read secrets or artifacts that a previous job left behind.

Contrast that with a reused runner. On a persistent or shared-reused runner, a single successful compromise becomes a beachhead. The attacker's code can sit and wait, observe the credentials and source of every subsequent job, and tamper with build outputs across runs. The defender has to win every single time; the attacker has to win once and then simply persist. Isolation flips that asymmetry by removing persistence as an option.

This is also why isolation is a precondition for trustworthy provenance, the subject of the next finding. A signed statement that an artifact was built in a particular way is only meaningful if the build environment could not have been tampered with by a previous or concurrent job. An isolated, single-use runner is what makes the provenance claim worth signing, which is why the two controls are best adopted together rather than in sequence.

Provenance is the last mile and it is barely started

Signed SLSA provenance, the verifiable record of how an artifact was built and from what sources, remains rare. Only about one in six build artifacts ships with it, which means the overwhelming majority of software in circulation still cannot prove its own origin. If a consumer wants to know that a binary was built from the commit it claims, on a build system that was not tampered with, for most artifacts there is simply no signed statement to check.

Provenance has stayed rare because it has felt optional, a nice-to-have that competes with shipping for engineering attention. That calculus is changing. Regulators and large enterprise buyers are beginning to require attestations as a condition of procurement, and the major frameworks have matured to the point where producing provenance is a configuration concern rather than a research project. The pressure is moving provenance from optional to expected, and the teams that have not started will feel it as a sudden requirement rather than a gradual one.

The teams that will satisfy the requirement without a scramble are the ones already building on isolated runners that emit provenance from the build by default. Because the build environment is trustworthy and single-use, the signed statement means something, and because it is emitted automatically, it does not depend on every team remembering to do it. Provenance is the last mile of supply-chain security, and like the earlier miles it is largely a property of the build platform rather than a task bolted on at the end.

The runner layer is where most of this is won or lost

Step back from the four fronts and a single pattern emerges: credential model, isolation, and provenance are all decided by where and how the job runs, not by the application code. A team can write the most careful workflow in the world and still inherit a long-lived secret, a reused runner, and an untrustworthy build environment from its platform. Conversely, the right runner layer hands several of these controls to a team that did nothing special to earn them.

This is what makes the runner layer the highest-leverage place to intervene. A managed runner that prefers short-lived OIDC credentials over static secrets, provisions a fresh isolated environment per job, and emits provenance from the build closes the static-secret front, the cross-job-isolation front, and the provenance front in a single architectural decision. The supply-chain front still requires pinning and vetting, but even there the per-job isolation acts as a backstop that contains a step that slips through.

None of this is a reason to skip the application-level controls, pinning actions, vetting dependencies, and scoping permissions still matter. But it reframes the work. Rather than treating pipeline security as a long checklist every team must implement from scratch, the most effective teams choose a runner platform that delivers the structural controls by default and then spend their remaining effort on the few risks that genuinely live in their own configuration.

Recommendations

Move off static secrets to short-lived OIDC tokens

This is the highest-leverage single change in pipeline security. Replace stored cloud keys with OIDC, so each job mints a token scoped to what it needs and expires it minutes later. Prioritize the older, less-maintained workflows, because the unconverted long tail is exactly where a single leak does the most damage and where a standing key is least likely to be watched.

Pin third-party actions and dependencies to a digest

A moving tag trusts whatever it points at on the day the job runs. Pin actions to a content digest and lock dependencies so a maintainer compromise or a malicious update cannot propagate silently into your pipeline. This directly addresses the two largest supply-chain vectors, which are code your team did not write.

Run every job in a fresh, isolated environment

Per-job isolation is architectural, not procedural; a team cannot achieve it by being careful. Use a runner platform that provisions a clean, single-use environment per job and destroys it afterward. This removes cross-job exposure as a class, eliminates a category of flaky failures, and makes any provenance you later emit worth signing.

Emit SLSA provenance from the build by default

Provenance is moving from optional to expected as regulators and large buyers require it. Produce a signed build attestation automatically from an isolated, trustworthy runner, so the claim is meaningful and does not depend on every team remembering to do it. Starting now turns a future procurement requirement into a configuration detail instead of a fire drill.

Choose the runner layer deliberately as a security control

Credential model, isolation, and provenance are properties of where the job runs. A managed runner that favors OIDC, isolates per job, and emits provenance closes three fronts in one decision, leaving your team to focus its remaining effort on the risks that genuinely live in your own workflow configuration rather than reimplementing the structural controls from scratch.

Outlook

Expect the pipeline to keep climbing the threat-model priority list through 2026 and beyond. As application surfaces harden and identity providers mature, the build system becomes a relatively softer target with relatively higher value, holding production credentials and executing untrusted code on every run. Attacker attention follows that math, which is why supply-chain incidents have grown faster than the surfaces they exploit.

The defensive trajectory is equally clear, and it converges on the runner. Short-lived OIDC credentials, ephemeral per-job environments, pinned dependencies, and provenance emitted by default are settling into a single expected baseline rather than a menu of optional hardening steps. The security story, the reliability story, and the provenance story increasingly point at the same architecture, which is what makes that baseline durable rather than a passing fashion.

For most teams the practical takeaway is that pipeline security does not require a dedicated security engineering function to get right. It requires moving off standing secrets, pinning what you do not control, isolating every job, and signing what you ship, and it requires choosing a runner layer that delivers most of those structurally. The organizations that internalize that will spend the next two years closing whole classes of incident while their peers keep rotating keys after the fact.

Methodology

This report synthesizes publicly available supply-chain and DevSecOps research with Latchkey's own modeled analysis of pipeline credential handling, runner isolation, and provenance practices. Figures labeled "modeled" are illustrative estimates derived from typical pipeline configurations and observed adoption curves, not a primary survey; figures attributed to a named source reflect that source. Adoption and risk percentages are scenario estimates and should be validated against your own security posture. 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
• GitLab DevSecOps Survey
• GitHub Actions documentation
• CNCF Annual Survey

More Latchkey reports