Topic starter
17/08/2026 4:39 pm
TL;DR: Akeyless shows how Coinbase’s GitHub environment exposure let secrets embedded in CI/CD workflows create paths to code tampering, malware injection, and data access in cloud pipelines. The breach underscores that secrets management, rotation, and just-in-time credentials are governance controls, not optional hygiene.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Lessons from the Coinbase Breach”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: CI/CD secret exposure turns development tooling into an identity and access problem because pipeline credentials can authorize code, deploy, and cloud control paths.
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
👉 Read Akeyless's analysis of Coinbase's CI/CD secret exposure and cloud pipeline risk →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 4:45 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Coinbase breach exposes CI/CD secret governance gaps in cloud pipelines