Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

CI/CD secrets exposure: what IAM teams need to change now


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 2364
Topic starter  

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.

NHIMG editorial — based on content published by Aembit: CI/CD security guidance for removing static secrets and hardening pipeline identities

Questions worth separating out

Q: How should security teams replace static credentials in CI/CD pipelines?

A: Security teams should replace stored pipeline secrets with federated, short-lived authentication such as OIDC so the workflow never holds a reusable credential.

Q: Why do CI/CD pipelines create a bigger identity risk than teams expect?

A: CI/CD pipelines often hold the credentials that unlock production infrastructure, so a single compromised workflow can expose far more than build access.

Q: What breaks when service accounts are reused across pipeline environments?

A: Reusing service accounts across dev, staging and production breaks blast-radius control because one compromised path can move into higher-value environments without a new authentication event.

Practitioner guidance

  • Replace static pipeline credentials with OIDC federation Scan GitHub Actions, GitLab CI/CD and Jenkins for hardcoded credentials, then migrate each cloud connection to federated authentication so the workflow never stores a reusable token.
  • Split deployment identities by environment Create separate dev, staging and production service accounts with no credential overlap, and keep production deployment rights distinct from runtime permissions.
  • Extend identity-based authentication to workloads Replace service passwords and broad shared keys with workload identity, temporary tokens and policy-based access so running applications do not recreate the same secret exposure pattern.

What's in the full article

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

  • Step-by-step OIDC federation setup for GitHub Actions, GitLab CI/CD and cloud providers.
  • Concrete workflow examples for replacing static API keys with temporary cloud credentials.
  • Practical rollout sequence for separating dev, staging and production service accounts.
  • Security-check error messaging patterns that help developers fix failed pipeline controls quickly.

👉 Read Aembit's guidance on eliminating CI/CD secrets and pipeline identity risk →

CI/CD secrets exposure: what IAM teams need to change now?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 4 weeks ago
Posts: 924
 

CI/CD identities are production identities, not developer conveniences. The article shows that pipeline access often reaches cloud infrastructure, deployment systems and application secrets, which means CI/CD credentials already sit inside the production trust boundary. Treating them as secondary or lower-risk identities creates a governance blind spot. For identity programmes, the implication is straightforward: pipeline identities need the same ownership, scope control and review discipline as any privileged non-human identity.

A few things that frame the scale:

  • 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
  • AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

A question worth separating out:

Q: Who is accountable when a pipeline identity exposes production secrets?

A: Accountability sits with the team that owns the pipeline identity, its permissions and its lifecycle, not just the developers who use it. That means IAM, platform security and DevOps ownership all need explicit control definitions for provisioning, review, rotation and revocation of CI/CD credentials.

👉 Read our full editorial: CI/CD pipelines are failing as secret stores, not just build systems



   
ReplyQuote
Share: