What should organisations do first when a CI/CD environment relies on static credentials?

Why This Matters for Security Teams

Static credentials in CI/CD are not just a hygiene issue, because they turn build, test, deploy, and release automation into a standing access path that often outlives the task it was meant to perform. When those credentials are reused across environments or shared by teams, a single leak can expose production, artifact stores, source control, and cloud control planes at once. NHI Management Group’s research on the Guide to the Secret Sprawl Challenge shows how quickly secret sprawl becomes operational debt, and OWASP’s Non-Human Identity Top 10 frames this as an identity problem, not just a storage problem.

The first move should therefore focus on the production-facing path, because that is where a static credential has the greatest blast radius if it is replayed, copied, or inherited by downstream jobs. In practice, many security teams discover the danger only after a runner compromise, a leaked token in logs, or a pipeline plugin incident has already turned routine automation into a credential sink.

How It Works in Practice

The practical response is to identify where the pipeline uses a long-lived secret to reach a live system, then replace that secret with runtime identity or a tightly scoped ephemeral credential where the access pattern is repeated. That usually means starting with deploy jobs, release tooling, infrastructure provisioning, and shared runners before moving to lower-risk stages such as linting or unit test jobs.

A useful working model is to treat each pipeline step as a workload with its own identity and trust boundary. Where supported, use federated workload identity, short-lived tokens, or brokered access instead of putting reusable cloud keys or service account secrets into environment variables. Guidance from NIST SP 800-63 Digital Identity Guidelines is helpful for identity assurance thinking, but CI/CD usually needs runtime trust decisions as well, not just account lifecycle control.

• Inventory credentials by pipeline stage and rank them by production reach.
• Replace static deploy tokens first, then shared credentials used by multiple jobs or teams.
• Issue short-lived secrets per run or per task, and revoke them automatically on completion.
• Move secrets out of code, logs, and config files into a managed secret broker.
• Validate that every runner can prove its workload identity before it receives access.

This is not theoretical: NHIMG’s CI/CD pipeline exploitation case study highlights how quickly runner exposure can become a supply chain problem, and the 2026 State of Secrets Sprawl report notes that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.

These controls tend to break down when legacy deployment scripts hardcode shared credentials into multiple release paths because no single owner can safely rotate them without coordinated downtime.

Common Variations and Edge Cases

Tighter credential controls often increase pipeline complexity and release friction, so organisations have to balance blast-radius reduction against the speed of delivery. That tradeoff is real, especially in monorepos, multi-cloud deployments, and environments where one runner serves many teams.

There is no universal standard for this yet, but current guidance suggests a phased approach: isolate the highest-value production path first, then convert adjacent jobs to ephemeral access as tooling allows. In some environments, the right first step is not full replacement but hardening around the static secret, such as limiting scope, shortening lifetime, and constraining network reach while a migration plan is built.

Edge cases matter. Self-hosted runners often deserve higher priority than hosted ones because they may have direct network access to internal systems. Shared service accounts, break-glass deploy keys, and secrets embedded in third-party build actions also need early review because they often bypass normal rotation workflows. For organisations building a formal program, the Ultimate Guide to NHIs - Static vs Dynamic Secrets is a useful reference point for deciding where static access remains acceptable and where runtime identity should take over. The best practice is evolving, but static credentials should never be left in the most privileged deployment paths just because they are convenient.

Related resources from NHI Mgmt Group

• What fails when static credentials are used in CI/CD pipelines?
• What breaks when organisations keep using static roles in dynamic environments?
• How should security teams prevent 403 errors in CI/CD pipelines?
• When should organisations prioritise Zero Standing Privilege for non-human identities?