Security teams should treat CI/CD credentials as production-grade machine identities and apply least privilege, short lifetimes, and continuous monitoring. The key is to limit what the pipeline can reach, revoke secrets quickly, and audit every privilege path that could let one stolen token spread across repositories, cloud accounts, or SaaS systems.
Why This Matters for Security Teams
CI/CD pipelines are not just build helpers. They are production-grade non-human identities that can authenticate to source control, cloud control planes, artifact registries, SaaS services, and deployment targets. If those credentials are long-lived or broadly scoped, one compromised runner or leaked token can become a bridge into everything the pipeline can touch.
The practical risk is no longer theoretical. GitGuardian’s Guide to the Secret Sprawl Challenge reports that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, which underscores how often attackers target automation paths first. That reality is consistent with the patterns documented in the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack.
Governance has to assume that pipeline credentials will be copied, logged, inherited, or reused unless controls prevent that by design. NIST Cybersecurity Framework 2.0 is useful here because it frames identity and access as an ongoing control problem, not a one-time setup, while the OWASP Non-Human Identity Top 10 highlights the recurring failure modes around secret sprawl, weak lifecycle management, and privilege creep. In practice, many security teams discover pipeline exposure only after a build token has already been reused across repositories or cloud accounts, rather than through intentional monitoring.
How It Works in Practice
Good pipeline governance starts by treating every CI/CD credential as a workload identity with a defined purpose, time limit, and blast radius. Static secrets should be the exception, not the default. Current guidance suggests using just-in-time issuance for jobs, short-lived OIDC-backed tokens where possible, and automated revocation at the end of a workflow. The goal is to remove reusable standing access from the pipeline entirely.
That means mapping each pipeline stage to the minimum set of actions it needs. A build job should not be able to deploy. A test job should not read production secrets. A release job should authenticate separately from a dependency scan. Policy should be enforced at runtime, not only through code review, because a pipeline’s needs can change by branch, environment, artifact, or approval state. This aligns with the direction described in NIST SP 800-63 Digital Identity Guidelines, even though the standard is not written specifically for pipelines.
- Issue credentials per job, not per team, and keep TTLs as short as operationally possible.
- Separate build, test, and deploy identities so one compromise cannot traverse the whole delivery path.
- Store secrets in a vault or workload identity broker, not in repository variables or plaintext environment files.
- Log issuance, use, and revocation events so unusual token reuse is visible quickly.
- Rotate credentials automatically after any suspected exposure, because detection alone does not stop replay.
NHIMG research has repeatedly shown why this matters. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful reference for choosing ephemeral secrets over persistent ones, and the Shai Hulud npm malware campaign shows how quickly leaked automation credentials can be harvested and reused. These controls tend to break down when legacy pipelines depend on shared service accounts, because those environments cannot separate identity by job or by trust boundary.
Common Variations and Edge Cases
Tighter pipeline credential controls often increase operational overhead, so teams have to balance developer velocity against blast-radius reduction. That tradeoff is real, especially in monorepos, multi-cloud delivery chains, and legacy release systems that were never designed for ephemeral access.
There is no universal standard for every environment yet, but current guidance strongly favours short-lived credentials, segmented identities, and policy checks at execution time. Some platforms can use federated identity cleanly, while others still need a brokered secret pattern until native support matures. In regulated environments, the acceptable answer may be a hybrid model: JIT access for deployment and vault-issued secrets for older tools that cannot speak OIDC.
Edge cases appear when pipelines call third-party SaaS, when runners are shared across teams, or when builds fan out into many child jobs. In those cases, the security team should assume lateral movement is possible and place extra emphasis on zero standing privilege, immutable runner images, and strong separation between artifact signing, testing, and release authority. The NIST Cybersecurity Framework 2.0 and Top 10 NHI Issues both support this kind of layered governance.
For teams comparing controls, the Guide to the Secret Sprawl Challenge remains a practical reminder that discovery and revocation must move together. The hardest failures usually show up in environments where build tooling still assumes every runner is trusted for the full duration of the job.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Pipeline secrets need rotation and lifecycle control to prevent reusable standing access. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and identity governance are central to pipeline credential control. |
| NIST Zero Trust (SP 800-207) | Zero trust fits CI/CD by validating each job and limiting implicit trust in runners. |
Use short-lived pipeline credentials and rotate or revoke any secret that outlives its job.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
