The State of CI Secrets Tooling 2026

Vault, OIDC, and cloud secret managers: adoption by org size, the move to short-lived credentials, where leaks still originate, and why ephemeral runners shrink the window.

Executive summary

Secrets are the highest-consequence thing a CI pipeline touches, and 2026 is the year the industry stopped treating long-lived static tokens as acceptable. The combination of OIDC federation, which lets a workflow exchange a signed identity token for a short-lived cloud credential, and mature cloud secret managers has made keyless CI access both practical and the recommended baseline. HashiCorp Vault remains the standard for teams that need a centralized, audited, multi-cloud secrets broker, while the cloud-native managers cover the single-cloud majority.

The shift is not merely a tooling preference; it reflects a change in how the industry reasons about secret risk. OpenSSF guidance and the broader supply-chain security conversation have reframed the goal away from protecting durable credentials and toward eliminating them, because a credential that does not persist cannot be leaked and reused. The static key, once the unremarkable default, is now the thing a security review flags, and the tooling landscape has reorganized itself around supplying credentials that expire.

This report quantifies how far that shift has actually gone: how many pipelines still ship a static key, how OIDC adoption is progressing across organization sizes, what the primary secrets mechanism looks like in practice, and where leak incidents still originate. The framing throughout is that the biggest remaining risk is not the secrets store itself, which is generally sound, but the static credentials lingering in workflow configuration and the breadth of scope teams hand to the tokens they do issue.

Three numbers frame the year. More than half of CI pipelines still rely on at least one long-lived static credential, which is the residual risk the rest of the tooling is meant to retire. Roughly two fifths of teams have adopted OIDC federation for cloud access from CI, with adoption concentrated in larger organizations. And an OIDC-minted credential typically lives around fifteen minutes against the indefinite lifetime of a static key, which is the entire point: a fifteen-minute secret is worth far less to an attacker than a permanent one.

The throughline is that the secrets tooling is largely solved and the gap is adoption and configuration. OIDC-friendly, ephemeral runners shrink the window in which any leaked credential is useful, so that even a token that escapes is valid only for minutes and only for the job it served. The teams that pair good tooling with that runner architecture turn secret leaks from incidents into non-events, and they do it without depending on flawless human discipline.

Static credentials are still the default, and still the problem

Despite years of guidance, the plurality of pipelines still inject at least one long-lived static secret, usually a cloud access key or a registry token stored as a repository or organization secret. The primary-approach chart shows static repo and org secrets as the single largest category, ahead of cloud secret managers, OIDC, and Vault. The static key remains the path of least resistance because it works on the first try and requires no federation setup.

These are the credentials that show up in leak incidents, and the reason is durability. A static key that escapes into a build log, gets committed to source, or is exfiltrated from a forked build remains valid until a human notices and rotates it, which can be days, weeks, or never. The window of usefulness for an attacker is the entire lifetime of the key, which for a static credential is effectively unbounded.

The implication is that the highest-leverage security work is not adopting a new secrets store but retiring the static keys already in place. OpenSSF guidance points in the same direction: the recommended posture is keyless access wherever the cloud and CI provider support it, precisely because removing the durable credential eliminates the failure mode rather than mitigating it. The store is rarely the weak point; the static credential sitting in workflow configuration is.

OIDC is the highest-leverage upgrade most teams have not finished

Exchanging a workflow identity token for a short-lived cloud credential removes the static key entirely, and adoption is clearly rising with organization size. The adoption curve climbs from a small fraction of the smallest teams to well over half of the largest, mirroring the pattern in every other CI maturity dimension: the practices that need a platform team to template and roll out concentrate in the organizations that have one.

The blocker is rarely technical. OIDC federation is well documented and supported across the major clouds, and the GitHub Actions side is a few lines of workflow configuration. The friction is the migration effort across many repositories and many cloud accounts, each of which needs its trust relationship configured, which is exactly the kind of broad, unglamorous work that loses to feature deadlines unless someone owns it.

The payoff is large enough to justify owning it. A fifteen-minute credential that never leaves the job is worth far less to an attacker than an indefinite key, so the same leak that would be an incident with a static key becomes a non-event with OIDC. The teams that have not finished the migration are typically partway through, with the high-traffic repositories converted and a long tail of older or lower-priority pipelines still minting static keys.

Most leaks are exposure, not a broken secrets store

Credential exposure overwhelmingly comes from secrets that were long-lived and over-scoped, not from a breach of Vault or a cloud secret manager. The leak-origin chart puts long-lived keys in config and logs as the largest single root cause, with over-scoped tokens behind them, and compromised dependencies and forked-PR exfiltration making up the remainder. The stores themselves are conspicuously absent from the top of the list.

This matters because it points the remediation effort at the right place. The secret managers and brokers are generally sound and well-audited; the failure mode is what teams put into workflow configuration and how broadly those tokens are scoped. A correctly stored secret that is handed to a job with far more permission than it needs, and that lives indefinitely, is the actual risk, and no improvement to the store addresses it.

Narrowing scope and shortening lifetime addresses the bulk of real-world incidents directly. A token scoped to exactly the resource a job touches limits what a leak can reach, and a token that expires in minutes limits how long a leak is useful. Together they convert the two largest leak categories, durable keys and over-scoped tokens, from incidents into bounded, low-impact events, which is a far better return than hardening a store that was not the problem.

• Long-lived keys in config and logs are the single largest leak root cause; the secrets stores themselves rarely fail.
• Over-scoped tokens are the second largest cause, so least-privilege scoping addresses real incidents directly.
• Shortening lifetime and narrowing scope together convert the top two categories into bounded, low-impact events.

Forked-PR builds remain a sharp edge

Workflows that run untrusted code from forked pull requests with access to secrets are a recurring exfiltration path, and the leak-origin data keeps this category live even at otherwise mature teams. The danger is specific: a forked pull request can modify the very workflow that runs it, so if that workflow has secrets in scope, an attacker can simply add a step that prints or ships them somewhere.

The mitigation is well understood. Secrets should be withheld from fork-triggered runs by default, sensitive workflows should require explicit maintainer approval before they run on forked code, and the environment should be isolated so that even an approved fork build cannot reach beyond its own job. None of this is novel, and the major CI providers expose the controls to do it.

It stays a sharp edge because it is easy to get subtly wrong. A workflow trigger configured slightly too permissively, an approval gate that a busy maintainer waves through, or a secret left in scope for a job that did not need it, any of these reopens the path. This is exactly the kind of configuration risk that per-job isolation and OIDC mitigate structurally: if the fork build runs on an ephemeral runner with no standing credentials and only short-lived, job-scoped tokens, there is far less to exfiltrate even when the gate is imperfect.

Vault and cloud managers solve different shapes of the problem

The tooling landscape is not a single winner but a division of labor, and the primary-approach chart reflects it: cloud secret managers, OIDC, and a centralized broker each hold a meaningful share. Cloud-native secret managers are the natural fit for a single-cloud team, because they integrate tightly with that cloud's identity system and require the least setup to issue scoped, rotated credentials.

HashiCorp Vault remains the standard where the requirements are broader: a centralized, audited, multi-cloud secrets broker that can issue dynamic credentials across providers and present one audit surface for all of them. Teams that span clouds, or that need dynamic secrets with tight leases and a single policy engine, reach for Vault precisely because a per-cloud manager cannot span the estate. The cost is operational, because a centralized broker is itself infrastructure to run.

OIDC federation cuts across both, because it is not a store at all but a way to avoid storing a credential in the first place. The mature pattern combines them: OIDC for the keyless cloud access that needs no stored secret, a secret manager or Vault for the secrets that genuinely must be stored, and least-privilege scoping throughout. The choice between Vault and a cloud manager is about the shape of the estate, not about which is more secure, and OpenSSF-aligned guidance treats keyless OIDC access as the preferred option wherever it is available regardless of which store backs the rest.

Ephemeral, OIDC-friendly runners shrink the blast radius

A runner that is freshly provisioned per job and torn down afterward leaves no standing credentials to harvest. There is no cached token from a previous job for the next workload to find, no environment file left on disk, no residue at all, because the machine that ran the job no longer exists by the time the next job starts. Per-job isolation closes the cross-contamination class that shared, long-lived runners leave open.

OIDC-native flows compound this. When the only credentials present in a job are short-lived and job-scoped, minted at the start of the run and expired by the end, there is very little durable secret material anywhere in the pipeline at any moment. A leaked token is valid only for minutes and only for the job that held it, so the exfiltration paths that matter, including the forked-PR edge, lose most of their value because there is so little standing exposure to capture.

Managed ephemeral runners make this the default rather than a hardening project a team has to staff and maintain. The combination of ephemerality and OIDC is the strongest part of the architecture, and it is also the part most teams are least equipped to build themselves, so delivering it by default is where the runner layer does the most for secrets posture. Even an imperfect configuration fails far safer when the runner retains nothing and the credentials expire in minutes.

• Per-job ephemeral runners leave no cached credentials for the next workload, closing the cross-contamination class.
• OIDC-native flows mean the only secrets present are short-lived and job-scoped, so leaks are valid for minutes at most.
• Managed runners make ephemeral, OIDC-friendly execution the default rather than a hardening project to staff.

What the best-governed teams do differently

The teams with the strongest CI secrets posture treat keyless access as the default and a stored static key as an exception that needs justification. They finish the OIDC migration rather than leaving a long tail of older repositories on static keys, and they scope every token they do issue to exactly the resources its job touches, so a leak reaches as little as possible.

They also treat the runner as part of the security boundary and the forked-PR path as a first-class threat rather than an edge case. By running every job on a fresh, isolated, ephemeral environment with only short-lived job-scoped credentials present, and by withholding secrets from untrusted fork builds behind approval gates, they make the common leak categories structurally low-impact instead of relying on flawless human discipline to prevent them.

• Keyless OIDC access as the default, with stored static keys treated as exceptions needing justification.
• Least-privilege scoping on every issued token so a leak reaches as little as possible.
• The right store for the estate: cloud managers for single-cloud, Vault for centralized multi-cloud brokering.
• Secrets withheld from forked-PR runs behind approval gates, with isolated environments.
• Ephemeral, OIDC-friendly runners so leaked credentials are valid for minutes and only for their job.

Recommendations

Finish the OIDC migration, do not leave a long tail

OIDC removes the static key entirely, and adoption rises with org size because templating it needs an owner. Convert the long tail of older and lower-priority repositories, not just the high-traffic ones, since the unconverted pipelines are exactly where the durable static keys that show up in leak incidents continue to live.

Scope every issued token to least privilege

Over-scoped tokens are the second largest leak root cause. Scope each credential to exactly the resources its job touches so that even a leaked token reaches as little as possible, which converts a broad compromise into a narrow, bounded one and addresses real incidents rather than hardening a store that was not the failure point.

Treat forked-PR builds as a first-class threat

Forked pull requests can rewrite the workflow that runs them, so withhold secrets from fork-triggered runs by default, gate sensitive workflows behind maintainer approval, and isolate the environment. Pair this with ephemeral runners and OIDC so that even an imperfect gate exposes only short-lived, job-scoped credentials with little to exfiltrate.

Match the store to the estate, then layer OIDC over it

Use a cloud-native secret manager for a single-cloud team and HashiCorp Vault where a centralized, audited, multi-cloud broker is genuinely needed, then use OIDC for the keyless access that needs no stored secret at all. The choice between stores is about the shape of the estate; keyless OIDC access is the preferred option wherever it is available.

Make ephemeral, OIDC-friendly runners the default

Per-job ephemeral runners leave no standing credentials to harvest, and OIDC-native flows mean any present credential is short-lived and job-scoped. Adopt managed runners that deliver both by default so a leaked token is valid only for minutes and only for its job, turning the common leak categories into bounded, low-impact events.

Outlook

Expect keyless access to keep displacing static credentials through 2026 and into 2027, with the curve diffusing from large organizations down to smaller ones as the per-repository migration cost falls. OpenSSF-aligned guidance and the cloud providers' own defaults increasingly nudge new pipelines toward OIDC from the start, so the static-key share should erode steadily even without any change in awareness, simply because keyless becomes the path of least resistance.

The tooling division of labor is likely to persist rather than collapse to a single winner. Cloud-native managers, Vault, and OIDC solve different shapes of the problem, and mature teams combine them rather than choosing among them, so the interesting movement is not in which store wins but in how much of the credential surface moves to keyless access that needs no store at all. That is where the residual risk shrinks fastest.

For most teams the practical takeaway is that the secrets tooling is largely solved and the remaining work is adoption and configuration. Finish the OIDC migration, scope tokens tightly, harden the forked-PR path, and run every job on an ephemeral, OIDC-friendly runner that retains nothing, and the common leak categories become bounded and low-impact by design. The organizations that internalize that will spend the next two years with secret leaks that fail safe, while their peers keep treating each one as an incident.

Methodology

This report synthesizes publicly available developer-security survey data and OpenSSF guidance with Latchkey's own analysis of CI secrets handling on ephemeral runners. Adoption and leak-origin shares are modeled from public survey direction and observed pipeline patterns, not a single primary survey, and are intended to show direction and magnitude rather than a precise population value. Credential-lifetime figures reflect documented OIDC short-lived credential behavior. 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
• GitHub Actions documentation
• HashiCorp
• GitLab DevSecOps Survey

More Latchkey reports