Topic starter
06/06/2026 2:09 am
TL;DR: CI/CD pipelines still expose broad, long-lived credentials that attackers can steal from runners, logs and workflow configs, according to Aembit, with recent incidents showing that pipeline compromise can unlock production infrastructure at scale. Static secrets turn build systems into persistent breach surfaces, not isolated developer tools.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Securing CI/CD Pipelines with Workload Identity Federation”.
By the numbers:
- 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.
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 privileged credentials in CI/CD pipelines create higher breach risk?
A: Privileged credentials in pipelines create higher risk because they are used repeatedly across build, test, and deployment systems, often by machines and service accounts rather than people.
Q: How can security teams tell if a pipeline identity is over-permissioned?
A: Look for workflows that can deploy, provision, or administer environments without separate approval, short-lived credentials, or environment-specific scoping.
Practitioner guidance
- Replace stored pipeline keys with federated workload identity Use OIDC-based authentication for GitHub Actions, GitLab CI/CD and other build systems so workflows exchange a signed identity assertion for short-lived cloud credentials.
- Reduce pipeline blast radius with run-scoped permissions Map each deployment, test and signing job to the narrowest cloud role it needs, then separate read-only, write and release privileges by workflow stage.
- Inventory every place a pipeline secret can reappear Search runner images, build logs, environment files, config repositories and troubleshooting chat history for duplicated credentials that survive the original job.
Bottom line: CI/CD pipelines have become a production access surface because their credentials often unlock cloud infrastructure, registries and deployment systems.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 3:39 am
CI/CD secrets are not a build-system convenience, they are production identities. Pipelines sit at the boundary of source control and runtime authority, which means a leaked credential is not a developer nuisance but a standing access path into cloud and deployment systems. The security model fails when teams treat those credentials as temporary configuration rather than governed identity. Practitioner implication: pipeline secrets must be managed as privileged non-human identities, not as incidental variables.
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.
A question worth separating out:
Q: What should teams do when CI/CD pipeline access must span cloud and SaaS services?
A: They should centralize trust and audit around workload identity rather than creating separate long-lived credentials for each destination. The goal is to issue short-lived, scoped access at runtime and keep offboarding, logging and policy enforcement consistent across every service the pipeline can reach.
👉 Read our full editorial: CI/CD pipeline secrets are the real breach surface in 2026
This post was modified 1 day ago by NHI Mgmt Group