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

At a glance

What this is: This is Akeyless’s analysis of the Coinbase attack, which highlights how exposed CI/CD secrets inside GitHub can enable code modification, malware injection, and infrastructure access.

Why it matters: It matters because CI/CD secrets are NHI assets, and IAM, PAM, and workload identity teams need controls that reduce exposure, limit standing privilege, and constrain blast radius.

👉 Read Akeyless's analysis of Coinbase CI/CD secret exposure and mitigation steps

Context

CI/CD secrets are credentials, tokens, and keys that software pipelines use to deploy code and access cloud services. When those secrets are embedded in GitHub repositories or exposed in workflow tooling, they become reusable non-human identities with access that attackers can exploit outside the intended build process.

The Coinbase incident is a familiar pattern rather than an isolated oddity: development workflows often accumulate secrets faster than teams can govern them. That creates a security gap across cloud infrastructure, source control, and deployment automation, where standing credentials can outlive the context that created them.

For identity teams, the issue is not just exposure but lifecycle failure. If a secret can be copied, reused, and operationally useful before rotation or revocation happens, then the control model is already behind the attack surface.

Key questions

Q: What breaks when secrets are stored in code and CI/CD tools?

A: Access becomes invisible, reusable, and hard to revoke, which means the organisation loses control of where authentication material exists. Once secrets are embedded in code or pipeline tools, discovery gets harder, offboarding slows down, and the same credential can survive multiple deployment cycles.

Q: Why do pipeline credentials create such a large blast radius?

A: Pipeline credentials often have standing privilege, broad scope, and access to multiple environments, which makes one exposed token much more damaging than a single user account. If those credentials can reach production, an attacker can operate as trusted automation and move laterally without triggering obvious boundary violations. That is why rotation, scoping, and ownership matter so much.

Q: How do security teams know if workflow secret handling is actually working?

A: Look for three signals: fewer long-lived secrets in workflows, strong inventory of which jobs can access which credentials, and successful use of short-lived federated auth for cloud access. If secrets still appear in runner logs, environment variables, or ungoverned third-party actions, the control is not working as intended.

Q: Who is accountable when a CI/CD secret leak affects production systems?

A: Accountability usually sits with the teams that own the pipeline, the secrets lifecycle, and the downstream systems that trust those credentials. A mature programme maps each credential to an owner, a purpose, and a revocation path so leaks can be traced and contained before they become a production incident.

Technical breakdown

How CI/CD secrets become reusable access paths

CI/CD systems often rely on API keys, tokens, certificates, and service credentials to move code through build, test, and deploy stages. If those values appear in source code, environment variables, logs, or pipeline configuration, they can be replayed by anyone who obtains them. The technical failure is not only disclosure but trust persistence: the secret remains valid long enough to authorize actions outside the pipeline’s intended context. That turns development infrastructure into a control plane for attackers, especially when the same credentials reach cloud APIs, artifact stores, and orchestration services.

Practical implication: Treat every pipeline credential as a live access path and remove any secret that can be used outside a narrowly scoped runtime context.

Why rotation and JIT credentials matter in pipeline identity

Secret rotation changes the useful lifetime of exposed credentials, while Just-in-Time credentials reduce or eliminate standing access altogether. In CI/CD, the difference matters because attackers often act quickly after discovery, and stale secrets can remain valid long after exposure. JIT also shifts access from persistent identity to ephemeral authorization, which is better aligned to task-scoped pipeline operations. Encryption helps reduce value at rest, but it does not replace governance over when a secret exists, who can retrieve it, and how quickly it can be invalidated.

Practical implication: Use short-lived credentials for pipeline tasks and make revocation or expiry a first-class part of release engineering.

How machine identity lifecycle control limits the blast radius

Certificates, tokens, and service identities need lifecycle management just as human accounts do. That means issuance, renewal, renewal suppression, revocation, and audit must be governed together rather than treated as separate tooling problems. In cloud and CI/CD environments, compromised machine identities can enable unauthorized deployments, lateral access, or data extraction even when source code itself is not altered. A mature model ties secret distribution to policy, records every retrieval, and ensures that identity state is continuously matched to operational need.

Practical implication: Link machine identity governance to secrets management so that credential issuance and revocation are controlled in the same operating model.

Threat narrative

Attacker objective: The attacker’s objective was to turn exposed CI/CD secrets into broad access for code tampering, infrastructure abuse, and sensitive data theft.

1. Entry occurred when attackers reached Coinbase’s GitHub environment and exposed secrets embedded in CI/CD processes.
2. Escalation followed because the exposed credentials could be reused to modify code, inject malicious software, or access sensitive infrastructure.
3. Impact included potential unauthorized deployments, malware injection, and data exfiltration across development and cloud systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD secret sprawl is a non-human identity governance failure, not a tooling nuisance. The Coinbase pattern shows that pipeline credentials behave like durable identities once they can be replayed outside the build context. When those credentials are scattered across repositories, logs, and environment files, the governance problem becomes lifecycle control, not just secure storage. The practical conclusion is that secrets must be treated as governed identities with issuance, use, and revocation rules.

Standing privilege is the real weakness behind exposed pipeline secrets. A secret that remains valid after it leaves the intended workflow creates unnecessary blast radius and makes fast-moving attacks viable. This is exactly where JIT credentials and short-lived tokens matter, because they break the attacker’s ability to convert discovery into durable access. Practitioners should read this as a privilege-minimization problem, not simply a leak-prevention problem.

Credential exposure in source control creates an identity blast radius that extends beyond the repository. Once a CI/CD secret can reach cloud APIs, deployment systems, or signing workflows, the compromise can move from code tampering to infrastructure control. That makes secrets management part of software supply chain defence, not just IAM hygiene. Teams should measure how far one credential can travel before it is blocked or expires.

Machine identity lifecycle is now inseparable from DevSecOps governance. Certificates, tokens, and API keys all need issuance, rotation, and revocation tied to actual runtime need. The Coinbase case reinforces that a secrets platform without lifecycle governance still leaves organisations with reusable credentials and unclear accountability. The practical conclusion is to govern machine identities with the same seriousness applied to privileged human access.

Secret sprawl persists because many organisations still manage secrets as isolated objects instead of a connected identity estate. That assumption fails in cloud-native delivery, where one credential can control multiple systems and one exposed token can open several paths at once. The implication is that security teams need a unified view of NHI, pipeline, and certificate lifecycle rather than siloed controls.

From our research:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• A faster path to control is mapping secret issuance, rotation, and revocation to the lifecycle model in The 52 NHI Breaches Report.

What this signals

Secret blast radius: The practical measure is not whether a secret exists, but how far it can travel before expiry or revocation stops it. In cloud delivery, that means evaluating source control, pipeline runners, artifact stores, and cloud APIs as one connected identity estate, not separate tool domains.

With 4.6% of public GitHub repositories containing at least one hardcoded secret, repository hygiene is still a live exposure problem, not a mature-control problem. Teams should expect disclosure pressure to persist until runtime injection and short-lived credentials become default operating practice, especially in high-change DevOps environments.

For practitioners

• Centralize pipeline secret governance Inventory every credential used by build, test, and deploy pipelines, then move them under one controlled lifecycle so secrets are injected at runtime rather than stored in code, scripts, or configuration files.
• Replace standing pipeline access with JIT credentials Issue temporary access for each task where possible, and require automatic expiry or revocation so leaked credentials cannot be reused after the intended job is complete.
• Shorten secret validity windows Set rotation and invalidation thresholds based on exposure risk, not convenience, and prioritise tokens that can reach cloud APIs, signing services, or deployment tooling.
• Tie machine identity lifecycle to release workflows Govern certificates, tokens, and API keys through issuance, renewal, revocation, and audit so that identity state always matches operational need across the delivery pipeline.
• Monitor for secret disclosure and replay Use continuous audit logging and detection for secret access, unusual pipeline behaviour, and reuse of credentials outside expected build activity.

Key takeaways

• The Coinbase pattern shows that exposed CI/CD secrets are identity failures with real blast radius, not just poor secret storage.
• Manual mitigation is too slow for pipeline credentials, which is why rotation, runtime injection, and JIT access need to operate together.
• Machine identity lifecycle controls are now part of DevSecOps security, because one leaked token can reach code, cloud, and deployment systems.

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.
• Machine identity lifecycle: Machine identity lifecycle is the full governance process for a non-human identity from creation to retirement. It includes provisioning, access scoping, rotation, renewal, offboarding, and auditability, and it fails when any one of those steps is handled manually or inconsistently.

What's in the full article

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

• Step-by-step guidance for centralising secrets across cloud and CI/CD environments.
• Operational detail on automated rotation and temporary Just-in-Time credentials.
• Explanation of the distributed encryption approach used to reduce secret value at rest.
• Machine identity lifecycle considerations for certificates alongside secrets management.

👉 The full Akeyless post covers centralisation, JIT credentials, distributed encryption, and machine identity lifecycle detail.

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 or secrets governance programme, it is worth exploring.