TL;DR: CI/CD breaches at CircleCI, GitLab and Travis CI show that pipeline compromise can expose production secrets, trigger unauthorized pipeline execution and hand attackers the permissions those credentials carry, according to Aembit. The security model breaks when pipelines and applications still rely on static credentials instead of federated, identity-based access.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “CI/CD Security Checklist: Eliminate Pipeline Secrets in 3 Weeks”.
Key questions
Q: What breaks when CI/CD pipelines rely on static secrets?
A: Static secrets create a reusable attack path into production infrastructure.
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: What are the signs that CI/CD security controls are not working well enough?
A: Common warning signs include secrets appearing in code or adjacent collaboration tools, policy violations that remain unresolved, weak visibility across the pipeline, and scanners that miss misconfigurations until late.
Practitioner guidance
- Replace static pipeline credentials Scan CI/CD variables, workflow files and build logs for hardcoded keys, tokens and sessions, then remove anything that can be replayed outside the pipeline.
- Federate pipeline authentication with OIDC Configure trust relationships so GitHub Actions, GitLab CI/CD or Jenkins authenticates with signed identity assertions and receives temporary cloud credentials only for the approved scope.
- Separate deployment identities by environment Create distinct dev, staging and production service accounts with no credential overlap and no shared path from non-production runners into production.
Bottom line: CI/CD pipelines become breach multipliers when they store the credentials that unlock production systems.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
CI/CD secret stores are now identity systems, whether teams recognise them or not. When a pipeline holds the credentials that unlock production infrastructure, the build plane becomes part of the identity plane. That shifts the governance problem from isolated secrets handling to lifecycle control over machine-authenticated access. Practitioners should treat every pipeline credential as a governed identity with scope, provenance and revocation requirements.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 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: Should teams prioritise OIDC federation before secret rotation?
A: Yes, when pipelines still rely on long-lived credentials. Rotation reduces exposure, but it leaves the same architectural weakness in place. OIDC federation changes the model so the pipeline proves identity at runtime and receives temporary credentials, which removes the need to manage reusable secrets in the first place.
👉 Read our full editorial: CI/CD pipelines are failing as secret stores, not just build systems