CI/CD pipelines combine broad access, automation, and persistence in one place. Their identities often outlive individual jobs, share credentials across environments, and can reach cloud and production systems. That means the organisation is managing powerful machine identities that behave like infrastructure, but are often governed with less rigour than human admin access.
Why This Matters for Security Teams
CI/CD pipelines are not just build tools. They are high-trust execution environments that often hold cloud credentials, deployment tokens, service account keys, and signing material in the same workflow. That creates a governance problem because the identity is both transient and persistent at once: individual jobs may be short-lived, but the pipeline, runners, integrations, and stored secrets can remain powerful for months. When those identities are over-privileged or poorly rotated, one compromise can move from source code to production very quickly. NHIMG’s Guide to the Secret Sprawl Challenge shows why secret sprawl is especially dangerous in automation-heavy environments, and NIST Cybersecurity Framework 2.0 reinforces the need for asset visibility, access control, and continuous monitoring. The core issue is not that pipelines are broken by default, but that they concentrate the exact conditions that make NHI governance difficult: broad reach, reuse, and weak lifecycle discipline. In practice, many security teams discover pipeline overreach only after a build credential has already been used to access systems it was never meant to touch.
How It Works in Practice
CI/CD governance fails when machine identities are treated like one-off secrets instead of managed NHIs. A safer model starts by separating the pipeline’s runtime identity from the credentials it uses. The runner should authenticate with a workload identity, not a long-lived shared token, and each action should receive only the access needed for that job. That means using short-lived credentials, JIT issuance, and automatic revocation at task completion rather than static secrets embedded in variables, config files, or repos. Current guidance suggests pairing this with intent-based authorisation so access is decided at runtime, based on what the pipeline is trying to do, not just which role it was assigned weeks ago. For an overview of how this maps to broader NHI practice, see Top 10 NHI Issues and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
Practitioners should also enforce:
- Ephemeral secrets for each pipeline stage, with strict TTL and automatic cleanup.
- Separate identities for build, test, and deploy paths, rather than one shared automation principal.
- Policy-as-code checks at request time, aligned to NIST SP 800-63 Digital Identity Guidelines where identity assurance matters.
- Continuous logging of secret access, token use, and privilege escalation attempts.
NHIMG’s CI/CD pipeline exploitation case study illustrates how a single exposed pipeline credential can cascade into source control, artifact stores, and production deployment systems. These controls tend to break down in monorepos, self-hosted runners, and federated build farms because identity reuse and cross-project trust make isolation harder to enforce.
Common Variations and Edge Cases
Tighter pipeline control often increases build friction, requiring organisations to balance release speed against credential churn and operational overhead. That tradeoff is real, especially in environments that rely on frequent deployments, third-party actions, or shared runner pools. In those cases, best practice is evolving rather than settled: there is no universal standard for how much pipeline autonomy should be preserved versus how aggressively privilege should be constrained. The safest approach is to minimise standing access, but some teams still need longer-lived trust for code signing, release promotion, or regulated change windows.
Edge cases also matter. Vendor-managed CI/CD services may hide underlying runner identities, making it harder to apply workload identity and per-job authorisation consistently. Legacy systems may not support OIDC federation or fine-grained secret issuance, so teams fall back to static credentials, which raises risk. This is where Reviewdog GitHub Action supply chain attack is relevant: third-party automation can silently expand the blast radius of a pipeline. The practical answer is to treat every integration as part of the identity perimeter, then map its access back to NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives. When pipelines span multiple clouds, external contractors, and reusable templates, the governance model usually breaks down at the point where ownership of the identity is unclear.
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 AI RMF 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 short lifetimes to limit NHI exposure. |
| NIST CSF 2.0 | PR.AC-4 | CI/CD access should be least privilege with continuous entitlement review. |
| NIST AI RMF | Autonomous pipeline behaviour needs runtime accountability and risk governance. |
Replace static pipeline secrets with rotated, short-lived credentials and revoke them after each job.
