Notifications
Clear all
Topic starter
06/06/2026 2:09 am
TL;DR: CI/CD pipelines remain prime targets because static, long-lived credentials in build systems unlock production infrastructure, and GitGuardian’s 2026 report found 28.65 million new hardcoded secrets on public GitHub in 2025, with 59% of compromised machines in Shai-Hulud 2 being CI/CD runners. Persistent secrets turn pipeline compromise into platform-wide access, not isolated developer risk.
NHIMG editorial — based on content published by Aembit: CI/CD Pipelines: The Secret Sprawl Problem and the Promise of Workload Identity Federation
By the numbers:
- GitGuardian’s 2026 report found 28.65 million new hardcoded secrets on public GitHub in 2025, a 34% year-over-year increase.
- In the Shai-Hulud 2 supply chain attack, 59% of compromised machines were CI/CD runners rather than developer workstations.
Questions worth separating out
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 CI/CD pipelines increase lateral movement risk?
A: Pipelines often concentrate cloud keys, deployment tokens, and API credentials in one execution path.
Q: How do security teams know whether workload identity federation is working?
A: Look for the absence of persistent secrets in workflows, short-lived credentials with narrow scope, and audit records that tie each access decision to a specific job or repository.
Practitioner guidance
- Inventory every pipeline credential path Map where secrets enter build systems, including workflow files, runner images, environment variables, logs, and third-party integrations.
- Replace persistent secrets with federated workload identity Use OIDC or equivalent attestation to issue short-lived credentials bound to a specific repository, branch, environment, and job.
- Reduce blast radius with job-scoped permissions Split deployment, testing, signing, and notification duties into separate identities with narrowly scoped entitlements.
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.
- Configuration patterns for mapping branch, repository, and environment claims to IAM roles.
- Examples of how workload identity federation replaces stored access keys in real pipelines.
- Discussion of workload identity and access management controls for multi-service environments.
👉 Read Aembit's analysis of CI/CD pipeline secrets and workload identity federation →
CI/CD pipeline secrets: what IAM teams need to change now?
Explore further
06/06/2026 3:39 am
CI/CD secrets are identity assets, not implementation details. Pipelines increasingly hold the same access value as privileged service accounts because they can reach production infrastructure, third-party APIs, and release systems. When credentials are stored in workflow files or runner memory, the delivery layer becomes an identity plane with real blast radius. Teams that still treat pipeline secrets as tooling configuration are underestimating the governance surface.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: What is the difference between secret rotation and workload identity federation?
A: Secret rotation keeps a persistent credential in place and replaces it on a schedule, while workload identity federation removes the stored secret from the workflow entirely. Rotation reduces exposure time, but federation removes the reusable secret material that attackers usually harvest from build systems.
👉 Read our full editorial: CI/CD pipeline secrets are the real breach surface in 2026
