TL;DR: Coinbase’s GitHub environment exposure shows how secrets embedded in CI/CD workflows can turn development tooling into a path for code tampering, malware injection, and data access, according to Akeyless. The lesson is that secret management, rotation, and JIT credentials are now core control points for cloud and pipeline identity governance.
NHIMG editorial — based on content published by Akeyless covering the Coinbase attack: CI/CD secret exposure and mitigation guidance
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Akeyless's analysis of Coinbase CI/CD secret exposure and mitigation steps →
CI/CD secrets exposure in GitHub: what IAM teams need to fix?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
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.
A few things that frame the scale:
- 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 question worth separating out:
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.
👉 Read our full editorial: Coinbase breach exposes CI/CD secret governance gaps in cloud pipelines