Coinbase breach exposes CI/CD secret governance gaps in cloud pipelines

At a glance

What this is: This is an analysis of the Coinbase GitHub compromise and its CI/CD secret governance failures, showing how exposed pipeline secrets can enable tampering, malware injection, and data access.

Why it matters: It matters because CI/CD secrets sit at the intersection of NHI, cloud delivery, and IAM governance, so weak handling turns build systems into high-blast-radius access paths.

👉 Read Akeyless's analysis of Coinbase's CI/CD secret exposure and cloud pipeline risk

Context

CI/CD secret governance is the discipline of controlling credentials, tokens, and keys used by build and deployment systems so they are not exposed in code, logs, configuration files, or pipeline tooling. In this case, the underlying problem is not just a breach at GitHub. It is the assumption that development workflows can safely hold persistent access material without creating an exploitable identity path.

Akeyless describes Coinbase’s GitHub environment exposure as a case where improperly managed CI/CD secrets could be used to modify code, inject malicious software, or reach sensitive infrastructure. That makes the incident a governance problem as much as a technical one: the pipeline became an access plane with insufficient lifecycle controls. For IAM and NHI teams, the relevant question is how build-time credentials are issued, used, and retired.

This is typical of modern cloud delivery environments, where secrets sprawl across repositories, pipelines, and deployment automations unless control ownership is explicit.

Key questions

Q: What breaks when CI/CD secrets live in shared environment variables?

A: Shared environment variables create standing privilege on the agent host, which widens exposure to any process or operator with sufficient local access. That breaks the assumption that only the intended pipeline step can use the secret. It also makes rotation, offboarding, and audit harder because the secret is embedded in host state rather than isolated workflow state.

Q: Why do exposed pipeline secrets create such fast compromise risk?

A: Because attackers do not need to break the application when a reusable credential already grants entry. A leaked token can be used immediately against cloud services, build tools, or connected SaaS integrations, often before defenders notice. Short-lived credentials and rapid revocation reduce that window materially.

Q: How do security teams know whether secrets in CI/CD are actually controlled?

A: Look for three signals: how many secrets a workflow can reach, how long those secrets remain valid, and whether any of them can publish or sign artefacts. If a build job can touch long-lived credentials or production systems, the environment is not controlled. The objective is to reduce reachable secrets and shorten exposure windows.

Q: How should teams reduce the risk of pipeline credential compromise?

A: Use runtime injection, short-lived credentials, and rapid rotation so the credential is valid only for the task that needs it. Pair that with clear ownership for certificates and other machine identities that support delivery tooling. The goal is to make pipeline access ephemeral, observable, and revocable rather than persistent.

Technical breakdown

How CI/CD secrets become an access plane

CI/CD systems often need credentials to clone repositories, authenticate to registries, deploy workloads, or call cloud APIs. When those secrets are embedded in scripts, environment variables, plaintext files, or long-lived pipeline variables, the build system effectively becomes a privileged identity surface. Once an attacker reaches the repository or pipeline context, the secret can be used to move from development tooling into production-adjacent control. The core failure is not that CI/CD exists, but that the credential boundary is too porous and too persistent. In NHI terms, these are workload identities and secrets that should be tightly scoped, short-lived, and auditable.

Practical implication: Treat pipelines as privileged systems and remove persistent secrets from every stage that can be substituted with runtime injection or short-lived credentials.

Why exposed pipeline secrets amplify blast radius

A secret embedded in CI/CD is rarely limited to one action. It may authorize code signing, deployment, infrastructure provisioning, or access to storage and monitoring services, which means one exposed token can touch multiple trust zones. That is why CI/CD secret leakage is so dangerous: the credential often outlives the task that created it and can be reused outside the intended workflow. Rotation limits the dwell time, but only if the organisation can inventory where the secret exists and where it is accepted. Without that inventory, revocation is reactive and partial, which leaves the attack path open long after discovery.

Practical implication: Inventory every pipeline credential, map its permissions, and prioritise the highest-blast-radius secrets for immediate rotation and replacement.

How runtime injection and JIT credentials change the control model

Runtime secret injection shifts access from static storage to ephemeral use, so the secret is delivered only when the job actually runs. Just-in-time credentials take that idea further by issuing access for a specific task and expiring it soon after completion. Distributed encryption adds another containment layer by preventing exposed fragments from being directly usable. These controls do not remove the need for governance, but they reduce the value of what an attacker can steal from a pipeline. The architectural change is important: the system stops assuming that access material should be present long enough to be copied or reused.

Practical implication: Replace static pipeline secrets with runtime-delivered or JIT credentials wherever the workload can tolerate ephemeral access.

Threat narrative

Attacker objective: The objective was to turn development pipeline access into broader control over code, infrastructure, and sensitive data flows.

1. Entry occurred through Coinbase’s GitHub environment, where attackers reached CI/CD-related assets and exposed sensitive secrets tied to the pipeline.
2. Credential access followed because the secrets were available in forms that could be reused rather than being tightly bound to a single runtime action.
3. Impact would include unauthorized code changes, malware injection, and exposure of internal systems or customer data through compromised deployment paths.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

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

NHI Mgmt Group analysis

CI/CD secret governance is now a core identity problem, not a DevOps side issue. Pipeline credentials function as non-human identities because they authenticate systems and automate access across build, deploy, and cloud operations. When those secrets are left in repositories, scripts, or tool variables, the identity boundary collapses into the delivery layer itself. The practical conclusion is that IAM and NHI governance must extend into software delivery rather than stop at user and admin accounts.

Static pipeline secrets create a reusable access layer that attackers can exploit at scale. The issue is not only exposure, but persistence: a credential that remains valid after it is copied can be replayed across environments and trust zones. That is why secret sprawl is a blast-radius problem, not just a hygiene problem. Organisations need to think in terms of where a compromised secret can travel, because that determines the real containment boundary.

Runtime secret injection is a stronger governance pattern than storing secrets for later use. The article’s logic is simple: if the secret is never present where it can be copied, the attacker has less to steal. That does not eliminate compromise, but it changes the economics of reuse and exfiltration. Practitioners should treat secret material as something that should appear only when a job executes, not as durable configuration.

Just-in-time access resets the assumption that build credentials should survive beyond the task they support. JIT credentials are useful here because the pipeline does not need standing privilege between releases, yet many programmes still behave as if it does. The implication is that access review and revocation must be designed around ephemeral use, not periodic inspection of long-lived pipeline access.

Secret sprawl is the named concept that explains why this breach pattern keeps repeating. Secrets scattered across code, config files, CI/CD tools, and related automation create multiple failure points instead of one controlled control plane. Once that sprawl exists, central governance becomes fragmented and response becomes slower than attacker reuse. The practitioner takeaway is to collapse the number of places where pipeline secrets can exist and be recovered.

From our research library:

• 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
• 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: Guide to the Secret Sprawl Challenge

What this signals

Secret sprawl is the hidden control failure behind many CI/CD incidents: when credentials live in repositories, build variables, and deployment scripts, there is no single lifecycle owner and no reliable revocation point. That makes the pipeline a distributed identity surface rather than a managed control plane.

For IAM and NHI teams, the practical shift is to govern pipeline credentials the way they would any other non-human identity: inventory them, constrain their scope, and remove standing validity wherever the workflow can tolerate runtime delivery.

For practitioners

• Centralize pipeline secret storage Remove credentials from code, configuration files, and CI/CD variables where possible, and issue them from a governed secrets manager at runtime instead.
• Rotate exposed credentials quickly Prioritise any secret that can reach repositories, deployment systems, or cloud APIs, then revoke and replace it before it can be reused across environments.
• Use just-in-time credentials for pipeline jobs Where a build or deployment task needs access, issue a short-lived credential for that run only and expire it immediately after the job finishes.
• Protect secret material with distributed encryption Use encryption designs that keep fragments separated so an exposed secret cannot be reconstructed easily from a single compromise point.
• Audit machine identity lifecycles Track issuance, renewal, and offboarding for certificates and other machine identities that support CI/CD, because pipeline access often persists longer than the workflow that created it.

Key takeaways

• CI/CD secret exposure turns development tooling into an identity and access problem because pipeline credentials can authorize code, deploy, and cloud control paths.
• The breach pattern becomes more damaging when secrets are long-lived, widely scoped, or stored in places that are difficult to inventory and revoke.
• Runtime secret injection, short-lived credentials, and stronger machine identity lifecycle controls are the controls that most directly reduce this risk.

Key terms

• CI/CD secret: A CI/CD secret is a credential used by build or deployment automation to reach source control, cloud services, registries, or internal systems. In practice it is a non-human identity artifact, so its scope, lifetime, storage location, and revocation path must be governed like any other privileged access token.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Just-in-time Credential Issuance: Just-in-time credential issuance creates access only when a request meets policy and then limits how long the credential remains valid. It reduces standing exposure, but it still depends on strong policy, accurate context, and reliable revocation handling.
• Runtime Secret Injection: A pattern that retrieves credentials only when a process starts, rather than storing them in files or source control. For AI developer tools, it reduces secret persistence, limits accidental disclosure, and keeps the credential tied to a specific execution session.

What's in the full article

Akeyless's full post covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance on centralizing secrets management across cloud and CI/CD environments
• A concrete walkthrough of runtime injection and JIT credential patterns for pipeline jobs
• The article's encryption and distributed fragment approach for protecting exposed secrets
• Discussion of machine identity lifecycle handling for certificates used in delivery workflows

👉 Akeyless's full post covers the Coinbase attack, secret management steps, and mitigation guidance for pipeline credentials.

Deepen your knowledge

NHI governance, machine identity security, and secrets management 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 or NHI governance programme, it is worth exploring.