CI/CD SSH keys persist long after the pipeline is compromised

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: CI/CD SSH keys stay in runner secrets and remain usable long after teams think they are safe.

Why it matters: IAM and NHI teams need to treat deploy keys as persistent credentials with supply-chain exposure, not as simple build-time convenience secrets.

Context

A deploy pipeline that carries a reusable SSH private key is already a credential governance problem, not just a deployment convenience issue. The core failure is that the runner inherits a long-lived secret that can be copied, logged, or reused outside the job that needed it.

CI/CD systems are especially exposed because they execute with broad automation privileges and often touch production hosts. When SSH access to servers still depends on a static keypair, the pipeline becomes both the delivery mechanism and the identity weak point.

The safer pattern is to make the pipeline authenticate as itself and receive short-lived, scoped access instead of storing a private key. That shift turns deploy access into a session problem rather than a secret-sprawl problem, which is why CI/CD pipeline identity security matters here.

Key questions

Q: How should security teams eliminate static secrets from CI/CD pipelines?

A: Security teams should move from stored credentials to runtime-issued access wherever possible. Use federation for cloud auth, inject short-lived secrets only into the job step that needs them, and keep the secret out of source control, logs, and artifacts. The aim is to remove standing exposure, not just hide it better.

Q: Why do stored deploy keys create such a large blast radius?

A: Stored deploy keys create a large blast radius because one credential can often unlock many repositories, hosts or deployment targets until it is revoked. If the key is copied into scripts, build agents or server disks, an attacker or ex-employee can reuse it without user interaction, especially when it carries broad server permissions and long-lived access.

Q: What is the difference between OIDC federation and SSH key auth?

A: OIDC federation uses a short-lived assertion about the workload to obtain scoped access without storing a reusable private key, while SSH key auth relies on a persistent key pair that proves possession of a private key. OIDC is usually easier to expire and bind to runtime context, whereas SSH keys remain valid until rotated or removed.

Q: What signals show that deploy credentials need to be rotated?

A: Deploy credentials need rotation when they appear on disk, in logs or in source control, when ownership is unclear, or when they have no clear rotation record. Other signals include failed inventory checks, shared use across systems, and credentials that have outlived the workload or deployment job they were issued for.

Technical breakdown

Why static SSH keys fail inside CI/CD runners

A static SSH key is a reusable authenticator, so any process that can read the variable, workspace, or secret store can replay it. In pipeline environments, that usually means a build step, a compromised dependency, or a logging mistake can turn a deploy secret into persistent server access. Unlike a browser or human login, SSH private keys do not naturally expire after a single task. They also inherit the permissions attached to the target account, which makes the blast radius larger than the pipeline job itself. Read Guide to the Secret Sprawl Challenge.

Practical implication: Replace reusable deploy keys with brokered access that expires when the job ends.

Why OIDC federation changes deploy identity

OIDC federation lets the pipeline present a signed assertion about who it is, what repo it came from, and when it requested access. A broker can then exchange that assertion for a short-lived session that is scoped to specific resources and a specific job context. The important shift is that the runner never handles a private SSH key, so compromise of the build environment does not automatically yield long-term access. This is the same trust pattern used for cloud APIs, but applied to server access instead of only to platform services. Read the Ultimate Guide to NHIs: Static vs Dynamic Secrets.

Practical implication: Use federated workload identity so deploy access is issued per run rather than stored on disk.

How session brokering limits SSH blast radius

Session brokering inserts an enforcement point between the runner and the target host. The broker checks policy, validates the identity context, and then proxies an authenticated SSH session without exposing the underlying credential to the client. That architecture adds two controls that static keys cannot provide: resource-level policy and per-session audit. It also means the target host does not need to accept broad inbound access just because the pipeline exists. The access path is created only when the job is authorised and destroyed when the job completes. See the Secrets Management Guide.

Practical implication: Gate deploy access through a session broker that logs identity, target, and duration.

Threat narrative

Attacker objective: The attacker wants durable SSH access to production or adjacent systems through a credential that outlives the compromise of the runner.

1. Entry occurs when an attacker compromises a CI/CD runner, malicious dependency, or pipeline variable and reaches the stored SSH private key.
2. Credential access follows when the key is copied from secrets, environment variables, or shell logs and reused outside the intended job.
3. Escalation happens when the stolen key opens access to the target host with whatever permissions the original deploy identity already had.
4. Impact is persistent server access that can be reused for deployment tampering, lateral movement, or silent infrastructure changes until the key is revoked.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Deploy keys are a supply-chain identity problem, not a server-access convenience. Once a reusable SSH credential sits in CI/CD, the security question changes from who can deploy to who can extract the key from the runner, logs, or workflow state. That means the deploy pipeline has become a secrets repository with execution rights, which is a poor identity boundary for modern delivery. Practitioners should treat pipeline-held SSH keys as standing access with a wider blast radius than the job that uses them.

Keyless server access is the right governance model for deployment identity. Cloud APIs already moved toward short-lived, federated credentials because static secrets do not match ephemeral workloads. SSH deployment should be governed the same way: a pipeline should authenticate as itself and receive access only for the duration and scope of the job. The governance shift is from possession-based access to assertion-based access, which is far easier to audit and revoke.

Standing SSH credentials create a long-lived privilege debt. Every deploy key that is never rotated, never attributed cleanly, and shared across hosts adds hidden operational risk. The debt is not just exposure time, but the inability to prove which workflow used the key, which host it reached, and who still retains copies. Organisations need to stop treating static deploy keys as a normal exception and start modelling them as unresolved privilege.

Long-lived deploy key exposure is the same failure pattern as secrets sprawl. The specific named concept here is runner-held credential persistence: a secret survives longer than the pipeline session that needed it, so compromise of the runner becomes compromise of the identity itself. That persistence makes revocation slower, attribution weaker, and incident response more ambiguous. The implication is that the control point has to move from storage to issuance, not just to a better vault.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Runner-held credential persistence: the real risk is not only that CI/CD stores a secret, but that the secret survives longer than the job that needed it. Once a pipeline can replay a deploy key after the build ends, the control boundary has already failed.

The operational response is to shift SSH access from possession to issuance. That makes the deploy pipeline a consumer of time-bound identity, not a custodian of permanent credentials, which is the right model for modern delivery.

Access reviews do little when the credential can be copied out of the runner and reused indefinitely. The governance point is to enforce session-scoped SSH access before compromise, not to count on after-the-fact recertification.

For practitioners

• Audit deploy secrets for static SSH material Search repository secrets, CI variables, and secret managers for SSH_KEY, PRIVATE_KEY, DEPLOY_KEY, and PEM patterns. Identify owners, hosts reached, and last rotation dates, then classify any key without a clear lifecycle as standing access.
• Replace reusable deploy keys with federated identity Move the pipeline to an identity provider flow that issues short-lived credentials for each job. The runner should authenticate as the workload, receive a scoped assertion, and avoid storing a private SSH key anywhere on disk or in variables.
• Broker SSH sessions through a policy gateway Place a session broker between the runner and target hosts so access is authorised per resource and per run. Require identity, resource, and duration logging for every session so deploy access is attributable after the fact.
• Remove authorized_keys dependence from deploy workflows Eliminate per-server public key sprawl by shifting server access to ephemeral sessions. If a workflow still depends on updating authorized_keys across many hosts, the access model is still anchored to a reusable secret.

Key takeaways

• Static SSH deploy keys create a durable identity problem inside CI/CD because they can be copied, logged, and reused outside the intended job.
• The strongest evidence in the source points to secrets sprawl and runner compromise as the combination that makes pipeline-held credentials unsafe.
• The practical fix is to issue SSH access per job through federation and session brokering, so there is no reusable key to steal.

Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: Static vs Dynamic Secrets · CI/CD Pipeline Identity Security Guide · Top 10 CI/CD Security Risks

Key terms

• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Static SSH Key: A static SSH key is a long-lived public and private key pair used for remote login and system access. Because it persists until someone manually removes it, it can outlive employment changes, become hard to inventory, and create standing access that is difficult to govern at scale.
• OIDC Federation: OIDC federation is a token-based trust model that lets one system accept identity assertions from another. It is commonly used to avoid static cross-environment credentials and to issue short-lived access based on trusted token claims. The control value depends on how tightly the trust relationships are governed.
• Session Brokering: Session brokering is the pattern of placing a control layer between the external user and the target system. The broker authenticates the user, retrieves credentials from a secure store, injects them into the session, and records activity, which reduces direct secret exposure and improves accountability.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.