DevOps practices dramatically accelerate NHI creation while creating conditions under which those NHIs go unmanaged. CI/CD pipelines spin up identities at each stage. Developers hardcode credentials into scripts. Service accounts are not decommissioned when projects end. Credentials are copied across environments. The solution is DevSecOps — embedding security controls directly into the pipeline.
Why DevOps Turns NHI Risk Up So Quickly
DevOps is a major NHI risk source because it multiplies identity creation faster than traditional governance can keep up. Every pipeline, test environment, deployment job, and automation step may require a service account, API key, certificate, or token. In practice, those secrets are often created for speed, copied between environments, and left in place long after the project that needed them has changed.
This is not a theoretical concern. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations such as code, config files, and CI/CD tools, and 30.9% store long-term credentials directly in code, which makes DevOps pipelines a high-value target for both accidental exposure and deliberate abuse. For background on the identity sprawl problem, see Ultimate Guide to NHIs and the attack patterns in CI/CD pipeline exploitation case study. NIST Cybersecurity Framework 2.0 reinforces the need to manage identity, access, and change as operational risks rather than afterthoughts, especially where automation can accelerate exposure.
In practice, many security teams discover DevOps identity sprawl only after a leaked token, overprivileged build account, or forgotten integration has already been used to move laterally.
How DevSecOps Reduces the Risk in Real Pipelines
DevSecOps works when security controls are embedded into the delivery process rather than bolted on after release. The goal is to make every non-human identity traceable, least-privileged, short-lived, and revocable. That means treating pipeline credentials as governed assets, not convenience artifacts.
Current guidance suggests the most effective pattern is a combination of secret detection, workload identity, and policy checks at runtime. A build job should authenticate as a workload, not as a human reused through a shared token. Where possible, use NIST Cybersecurity Framework 2.0 aligned controls to define ownership, review cadence, and revocation paths, then pair them with the NHI lifecycle practices described in Top 10 NHI Issues.
- Issue JIT credentials for a single job or stage, then revoke them automatically on completion.
- Prefer workload identity over static shared secrets so the pipeline proves what it is, not just what it knows.
- Scan repositories, build logs, and artifacts for secrets before promotion.
- Enforce RBAC and approval gates for privilege escalation, especially in release and production paths.
- Use rotation and offboarding workflows so stale service accounts do not survive project closure.
These controls tend to break down in highly fragmented toolchains because identity state becomes split across source control, runners, secret stores, and cloud platforms.
Where the Standard Advice Breaks Down
Tighter controls often increase delivery friction, requiring organisations to balance release speed against identity hygiene. That tradeoff is real in microservice-heavy platforms, ephemeral test environments, and multi-cloud estates where secrets, roles, and certificates are created and destroyed continuously. Best practice is evolving, and there is no universal standard for how much automation should be delegated to pipelines versus gated by human approval.
One common edge case is shared CI/CD tooling across many teams. Centralised pipelines can improve consistency, but they also concentrate privilege and expand blast radius if an agent, runner, or integration token is compromised. Another is legacy automation that cannot easily support short-lived credentials. In those environments, the immediate goal is not perfection, but reducing standing privilege, shortening token life, and removing hardcoded secrets from code and scripts as fast as possible.
For broader remediation patterns, the Ultimate Guide to NHIs — Key Challenges and Risks is useful, and the compromise dynamics are visible in the Cisco DevHub NHI breach. The practical lesson is simple: where pipelines can mint identities faster than governance can retire them, risk becomes structural rather than incidental.
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 and CSA MAESTRO address the attack and risk surface, while 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 | Covers secret leakage and poor rotation in DevOps pipelines. |
| CSA MAESTRO | Addresses governance for automated, goal-driven systems using non-human identities. | |
| NIST AI RMF | Supports governance and risk management for AI-driven automation in delivery pipelines. |
Apply runtime policy, least privilege, and lifecycle controls to every automated pipeline identity.
