The State of Secrets Management in CI 2026

Secret sprawl across pipelines, the shift to OIDC and short-lived credentials, where leaks actually originate, and why ephemeral runners shrink the blast radius.

Executive summary

Secrets are the part of CI that everyone touches and nobody owns. Credentials accumulate across repository settings, environment files, third-party integrations, and shared organization stores, and the result is sprawl: the same secret copied in several places, no single owner, and no reliable answer to the simplest governance question, which is who can read what. CI is where this sprawl concentrates because the pipeline is the one place that legitimately needs access to source, registries, cloud, and deploy targets all at once.

The encouraging trend is the steady migration away from long-lived static keys toward OIDC and short-lived credentials minted per job. A token that exists only for the life of a workflow run cannot be leaked into a log and quietly reused months later, which removes the most common and most damaging failure mode in a single architectural move. This is the most important shift in CI security in years, and 2026 is the year it stopped being a leading-edge practice and started being the expected baseline.

But the transition is uneven, and long-lived credentials still dominate many pipelines. The migration is a per-provider, per-repository effort that competes with feature work, so the static keys linger in exactly the places least likely to get attention. This report quantifies the sprawl, tracks the OIDC shift, sizes where leaked-secret incidents actually come from, and lays out where central vaulting and ephemeral runners change the picture.

Three numbers frame the year. A little under three fifths of the credentials in a typical CI pipeline are still long-lived static keys, which is the core residual risk. OIDC short-lived credential adoption has grown several times over since 2023, but it is heavily concentrated in larger organizations with platform teams to drive it. And a mid-size organization spreads its CI secrets across roughly a dozen distinct stores, which is the sprawl number that makes rotation slow and audit unreliable.

The throughline is that secrets management in CI is a governance problem before it is a tooling problem, and an architecture problem before it is a redaction problem. Short-lived credentials beat better log scrubbing because they make a captured secret worthless rather than merely harder to find, and ephemeral runners beat careful cleanup because they leave nothing behind to harvest. The teams that internalize that spend their effort on ephemerality and consolidation rather than on chasing leaks after the fact.

Static keys still dominate, and that is the core risk

Despite the OIDC shift, the majority of CI credentials in a typical pipeline are still long-lived static keys. A cloud access key stored as a repository secret, a registry token in an org store, a deploy credential pasted into an environment, all of these persist long after the job that used them, and that persistence is precisely what makes them dangerous. A short-lived token that leaks is already expired by the time anyone could abuse it; a static key that leaks is valid until someone notices and rotates it.

The asymmetry is what makes static credentials the highest-leverage thing to retire. Every other control around a secret, log redaction, scope narrowing, access review, is mitigation that reduces the probability or the impact of a leak. Replacing a static key with a short-lived one removes the failure mode entirely, because there is no longer a durable credential to leak. That is a categorical improvement rather than an incremental one.

The credential mix chart shows the size of the problem: well over half of CI credentials are still long-lived static keys, with OIDC and vault-issued dynamic credentials together a minority. The work for most teams is not adopting a new secrets store, it is methodically retiring the static keys they already have, starting with the ones that grant cloud and production access.

OIDC adoption is real but lopsided by org size

Larger organizations have moved decisively toward OIDC and short-lived tokens, while smaller teams lag well behind. The adoption curve climbs steeply with org size, from a small fraction of the smallest teams to nearly two thirds of the largest, and the reason is structural: OIDC federation is a per-provider, per-cloud setup that benefits enormously from a platform team that can do it once and template it everywhere.

For a small team without that platform function, the per-provider setup feels like overhead disproportionate to the perceived risk, so the static key stays. This is understandable but inverted, because the smallest teams are often the least equipped to detect and respond to a leak when it happens, which makes the durable static credential more dangerous for them, not less. The trend line is clearly upward, but the long tail of small pipelines still minting and storing static keys is where most residual risk concentrates.

The practical reading of the adoption chart is that OIDC has crossed from leading-edge to mainstream at the top of the market and is diffusing downward. The blocker is rarely technical capability; it is the migration effort spread across many repositories and clouds. Anything that lowers that per-repo setup cost, templates, defaults, managed runner integrations, accelerates the diffusion to exactly the teams that are currently most exposed.

Most leaks come from logs and commits, not exotic attacks

Leaked-secret incidents overwhelmingly trace to mundane causes. A credential echoed into build output by a debug line, a key committed to source in a moment of haste, an over-scoped shared store that exposed far more than any single job needed, a third-party integration handed a broader token than it required. The dramatic supply-chain breach makes the headlines, but the everyday leak is a static secret that ended up somewhere readable.

Short-lived credentials defang the two largest categories almost for free. A secret echoed into a log or committed to source is only dangerous while it is still valid, and an OIDC-minted credential that lives for the duration of the run has already expired by the time anyone reads the log. This is why ephemerality beats redaction as a defense: redaction tries to prevent the secret from being captured, while ephemerality makes capturing it pointless.

The leak-source chart makes the priority concrete: logs and commits together account for the clear majority of incidents, with over-scoped stores and third-party integrations behind them. The implication is that the highest-return security investment is not a better log scrubber, it is removing the durable credential that the scrubber is trying to protect, so that a missed redaction is a non-event rather than an incident.

• Build logs and committed-to-source leaks together are the clear majority of incidents, both mundane and both common.
• Short-lived OIDC credentials make a captured secret worthless because it has already expired by the time it is read.
• Ephemerality beats redaction: redaction tries to prevent capture, ephemerality makes capture pointless.

Sprawl is a governance problem before it is a tooling problem

CI secrets spread across repository settings, org-level stores, central vaults, and third-party integrations, with the same value often duplicated across several of them. A mid-size organization spreads its CI secrets across roughly a dozen distinct stores, and that fragmentation is the root of the governance failure: when a secret lives in many places, no single place is authoritative and no single owner is accountable.

Sprawl makes the two operations that matter most, rotation and audit, slow and unreliable. Rotating a credential that is duplicated across a dozen stores means finding and updating every copy, and missing one leaves a valid stale secret in circulation. Auditing who can read a secret is impossible when the answer depends on the union of access controls across stores that were never designed to be reconciled. The duplication is what turns a manageable inventory into an unmanageable one.

Consolidating onto a central vault with clear ownership pays off more than any single tool swap, because it restores the ability to answer the basic questions. The sprawl chart shows how scattered the typical distribution is, with repo and environment settings holding the plurality and the rest spread across org stores, vaults, and third parties. The goal is not a particular product, it is a single authoritative source per secret with one owner and one rotation path.

Per-job isolation closes the cross-contamination class

A runner that retains state between jobs is a quiet liability for secrets. Cached credentials, environment variables, and tokens from one workload can linger on the machine and be observable by the next job that lands on it, which means a secret legitimately used by one pipeline can be harvested by an unrelated one that simply happened to run on the same runner afterward.

This cross-contamination is invisible in normal operation, which is what makes it dangerous. Nothing fails, nothing logs an error, and the leak only surfaces if a malicious or compromised workload goes looking for what the previous job left behind. Shared, long-lived runners are exactly the environment where this happens, because the whole point of keeping them around is to reuse state between jobs, and credentials are state.

Per-job isolation closes the class outright. A runner that is provisioned fresh for a single job and torn down completely afterward retains nothing for the next workload to inherit, so there is no residue to harvest. This is the same architecture that delivers reliability and reproducibility benefits, which is why the security case and the operational case for ephemeral runners point at the same design.

Ephemeral runners shrink the secret blast radius

The blast radius of a secret is the set of things that can reach it and the window of time over which they can. Ephemeral runners shrink both. A runner that tears down completely after each job means no credential outlives the run that used it on the machine, and when that is paired with short-lived credentials and central vaulting, the standing exposure that an attacker could target collapses to almost nothing.

The combination is what matters. Short-lived credentials limit the time window, central vaulting limits the duplication, and ephemeral runners limit the residue, and together they ensure that at any given moment there is very little durable, broadly accessible secret material sitting anywhere in the pipeline. Each control covers a gap the others leave, which is why the mature posture uses all three rather than betting on any one.

Managed runners that provision a fresh environment per job deliver the ephemerality leg by default rather than as a hardening project a team has to staff and maintain. That lowers the cost of the strongest part of the architecture to nearly zero, which is significant precisely because the teams most exposed to secret leaks are the ones least able to build and operate ephemeral runner infrastructure themselves.

• Short-lived credentials limit the time window, vaulting limits duplication, and ephemeral runners limit the residue.
• The three controls cover each other's gaps, so the mature posture uses all three rather than betting on one.
• Managed runners deliver the ephemerality leg by default, lowering the cost of the strongest control to near zero.

What the best-governed teams do differently

The teams with the healthiest CI secrets posture share a small set of habits. They prefer OIDC and short-lived credentials by default and treat a new long-lived static key as something requiring justification rather than the path of least resistance. They consolidate onto a single authoritative store per secret with a named owner, so rotation is one operation and audit has one answer.

They also treat the runner layer as part of the security boundary rather than as neutral infrastructure. By running each job on a fresh, isolated environment that retains nothing, they remove the cross-contamination and residue failure modes structurally instead of trying to clean up after them, and they instrument their secrets inventory so that sprawl is visible and a new duplicate is caught early rather than discovered during an incident.

• OIDC and short-lived credentials by default, with new static keys treated as exceptions needing justification.
• One authoritative store per secret with a named owner, so rotation is single-step and audit has one answer.
• Per-job isolated ephemeral runners that retain nothing between workloads.
• A maintained secrets inventory so sprawl is visible and new duplicates are caught early.
• Fork-triggered and untrusted runs withheld from secrets, with approval gates on anything that needs them.

Recommendations

Retire static keys before adopting new tooling

The core risk is durable static credentials, not the absence of a particular secrets product. Methodically replace long-lived static keys with short-lived OIDC credentials, starting with the ones that grant cloud and production access, because removing the durable credential eliminates the failure mode rather than merely mitigating it.

Lower the per-repo cost of the OIDC migration

OIDC adoption lags in smaller teams because the per-provider setup feels like overhead. Template the federation config, set keyless access as the default for new repos, and lean on managed runner integrations so the migration cost per repository drops, which is what diffuses OIDC to the exposed long tail of small pipelines.

Make ephemerality the defense, not redaction

Most leaks are secrets echoed into logs or committed to source. Rather than investing primarily in better log scrubbing, make captured secrets worthless by minting them short-lived per job, so a missed redaction is a non-event instead of an incident. Ephemerality prevents the impact; redaction only attempts to prevent the capture.

Consolidate onto one authoritative store per secret

A mid-size org spreads secrets across roughly a dozen stores, which makes rotation slow and audit unreliable. Consolidate each secret to a single authoritative source with a named owner and one rotation path, so the basic governance questions of who can read it and how it rotates have a single answer.

Treat the runner as part of the security boundary

Shared runners that retain state let one job harvest another's credentials, and that cross-contamination is invisible until exploited. Run each job on a fresh, isolated, ephemeral environment that retains nothing, which closes the residue and cross-contamination classes structurally instead of relying on cleanup after the fact.

Outlook

Expect the OIDC and short-lived credential shift to continue diffusing from large organizations down to smaller ones through 2026 and into 2027, driven less by new awareness than by falling setup cost. As templates, defaults, and managed runner integrations make keyless access the path of least resistance rather than an extra project, the long tail of small pipelines still shipping static keys will shrink, which is where most residual risk currently sits.

The architectural convergence is the durable story. Short-lived credentials, central vaulting, and ephemeral per-job runners each close a different failure class, and together they collapse the standing secret exposure of a pipeline to nearly nothing. Because the same ephemeral-runner architecture also delivers reliability and reproducibility benefits, the security case and the operational case reinforce each other, which makes the posture stick rather than fade as a passing compliance fashion.

For most teams the practical takeaway is that CI secrets do not need a heroic security program to get right. They need static keys retired in favor of short-lived ones, sprawl consolidated to authoritative stores with clear owners, and a runner layer that retains nothing between jobs. The organizations that internalize that will spend the next two years with a secrets posture that fails safe by design, while their peers keep chasing leaks they could have made harmless.

Methodology

This report synthesizes publicly available security and developer survey data with Latchkey's own modeling of CI secret distribution, OIDC adoption, leak sources, and per-job isolation on ephemeral runners. Figures labeled modeled are illustrative estimates derived from public reporting and representative pipeline shapes, not a primary survey, and are intended to show direction and magnitude rather than a precise population value. Adoption and incident-source figures are modeled distributions rather than measured population statistics. 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

• GitHub Actions - billing & pricing
• Stack Overflow Developer Survey
• CNCF Annual Survey
• GitHub - Octoverse
• OpenSSF

More Latchkey reports