How should security teams eliminate static secrets from CI/CD pipelines?

Why This Matters for Security Teams

Static secrets in CI/CD are not just “stored credentials”; they are standing access that can be copied into logs, artifacts, environment snapshots, caches, and forked build contexts. Once a pipeline token or deployment key exists in a durable form, it becomes a high-value target for supply chain attackers who know that build systems often have broader reach than the developers using them. The OWASP Non-Human Identity Top 10 treats this as an identity problem because pipelines should authenticate as workloads, not as shared humans with long-lived secrets.

NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly secrets spread once they enter operational tooling. Vendor research from The State of Secrets Sprawl 2025 found that 4.6% of public GitHub repositories contain at least one hardcoded secret, which is a useful reminder that exposed credentials are not a corner case. In practice, many security teams discover pipeline secret exposure only after a build log, artifact, or third-party action has already been harvested.

How It Works in Practice

The cleanest pattern is to replace stored pipeline credentials with runtime-issued access tied to the job that is executing. That usually means federation for cloud authentication, workload identity for the runner, and short-lived tokens issued only when the pipeline reaches a trusted step. This aligns with the broader move from static IAM toward context-aware authorization, where the system decides at request time whether this specific job, in this specific environment, should receive access.

For most teams, the implementation stack looks like this:

• Use OIDC federation from the CI platform to the cloud provider instead of embedding access keys.
• Scope tokens to a single repository, branch, environment, or deployment target.
• Issue credentials only inside the job step that needs them, then revoke or let them expire immediately after use.
• Prefer workload identity and policy evaluation over shared service accounts, especially for production deploy jobs.
• Keep secrets out of source control, logs, artifacts, and environment dumps by default, not as an afterthought.

This is where static IAM fails for autonomous or highly automated delivery systems: pipelines do not behave like fixed human roles, and their access patterns change with every run, environment, and approval gate. Runtime controls such as policy-as-code and short TTLs are better suited to this variability because they evaluate the actual request rather than assuming a stable pattern. Guidance from the SPIFFE overview is especially relevant here because it treats workload identity as cryptographic proof of what the runner is, not just what secret it happens to hold. NHIMG’s CI/CD pipeline exploitation case study shows why this matters when build systems are used as a lateral movement path into cloud and source control estates.

Where teams still need a secret, the best practice is to make it ephemeral, narrowly scoped, and injected only at runtime through a broker or vault rather than stored in a variable group. These controls tend to break down when self-hosted runners are persistent and broadly privileged because an attacker can reuse the host, the workspace, or the runner process itself.

Common Variations and Edge Cases

Tighter secret controls often increase pipeline complexity, requiring organisations to balance reduced standing exposure against developer friction and platform maintenance. There is no universal standard for every CI/CD platform yet, so current guidance suggests choosing the least persistent credential path that still supports the job’s real dependencies.

Some environments still need exceptions. Legacy build tools may not support OIDC, air-gapped release systems may require a bootstrap credential, and cross-account deployment flows can force an intermediate trust layer. In those cases, the goal should be to constrain the exception, not normalise it: set the shortest possible TTL, bind the secret to a single use case, and monitor for unexpected reuse.

Teams should also account for non-obvious leak paths. Secrets can surface in debug output, test fixtures, cached layers, child workflows, or third-party marketplace actions. NHIMG’s Reviewdog GitHub Action supply chain attack is a strong reminder that even trusted automation can become a disclosure channel. The main tradeoff is operational speed versus control depth: the more dynamic the credential model, the more important it becomes to automate rotation, revocation, and secret scanning.

Related resources from NHI Mgmt Group

• How should security teams govern credentials used by CI/CD pipelines?
• How should security teams replace static secrets in Databricks pipelines?
• What breaks when CI/CD pipelines rely on static secrets?
• How should security teams handle protobuf vulnerabilities in CI/CD pipelines?