Prioritise CI/CD hardening when pipelines can reach privileged credentials or deploy to production, because those environments often turn one leaked secret into many. Secret scanning still matters, but pipeline isolation, minimal token scope, and short-lived access reduce the number of credentials available to steal in the first place.
Why This Matters for Security Teams
Teams should prioritise CI/CD hardening when build and deploy systems can touch production, signing keys, cloud admin roles, or secret stores. At that point, the pipeline is no longer just a delivery path; it is a privilege amplifier. Broader secret scanning still has value, but it finds exposed credentials after they exist. Hardening reduces how many credentials can be reached, how long they live, and how far a stolen token can travel.
This is especially important because pipeline compromise is a common blast-radius multiplier. In GitGuardian’s The State of Secrets Sprawl 2026, 59% of compromised machines in a major supply chain attack were CI/CD runners rather than personal workstations. That lines up with NHIMG’s CI/CD pipeline exploitation case study, which shows how an attacker who lands inside delivery tooling can pivot into signing, deployment, and secret retrieval workflows. The practical lesson is that one weak runner or over-scoped token can outpace dozens of successful secret scans.
Current guidance from the OWASP Non-Human Identity Top 10 is to treat machine identities and automation paths as first-class attack surfaces, not as a byproduct of software delivery. In practice, many security teams discover the problem only after a build job has already minted access to systems that secret scanning was supposed to protect.
How It Works in Practice
The decision is usually driven by reach and privilege. If a pipeline can read vault material, assume a cloud role, sign artifacts, or deploy to regulated environments, then pipeline hardening should come first. That means narrowing the number of places secrets appear, reducing token scope, and shifting to short-lived credentials wherever possible. Secret scanning should then act as a backstop, not the main control.
- Isolate runners so untrusted code cannot reach deployment credentials or shared caches.
- Use JIT credentials and ephemeral secrets for build, test, and release steps.
- Prefer workload identity over long-lived static tokens so each job proves what it is, not just what it knows.
- Apply RBAC and policy checks at request time so deploy permissions expire with the task.
- Continuously scan repos, logs, ticketing tools, and artifact metadata, because exposure is not limited to source code.
That approach matches NHIMG’s Guide to the Secret Sprawl Challenge, which emphasises that secret leakage is often a symptom of deeper identity sprawl. It also fits the evidence in Reviewdog GitHub Action supply chain attack, where pipeline trust boundaries, not just exposed strings, became the real issue. For control design, the OWASP guidance and OWASP Non-Human Identity Top 10 both point to reducing standing privilege before trying to detect every leaked secret.
This guidance tends to break down when organisations run highly distributed build systems with shared runners, unmanaged self-hosted agents, or legacy deployment scripts that cannot support short-lived identity issuance.
Common Variations and Edge Cases
Tighter CI/CD controls often increase delivery friction, requiring organisations to balance release speed against blast-radius reduction. That tradeoff is real, especially in teams that depend on many third-party actions, frequent hotfixes, or legacy platforms with weak identity primitives.
There is no universal standard for this yet, but current guidance suggests the following pattern: harden the pipeline first when the pipeline can deploy, sign, or mint credentials; expand secret scanning breadth when the environment is sprawling, collaboration-heavy, or already showing leakage outside code. GitGuardian’s 2025 research found that 28% of secrets incidents now originate outside repositories, and 38% of incidents in collaboration tools are highly critical or urgent. That means scanning Slack, Jira, and Confluence matters, but it does not replace reducing privilege where automation can already act.
For teams operating in newer AI-driven delivery flows, the risk is even more dynamic. Autonomous agents and workflow bots can chain tools, request more access than a human reviewer expected, and surface secrets in execution logs, so guidance from the Shai Hulud npm malware campaign is a reminder that malicious automation can turn build trust into credential harvest. For broader governance, the 52 NHI Breaches Analysis reinforces the same pattern: once a system has standing access, secret discovery is often too late to prevent abuse.
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 | Standing secrets in pipelines directly increase NHI exposure and blast radius. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access for runners and deploy jobs is central to pipeline hardening. |
| NIST Zero Trust (SP 800-207) | Zero trust supports continuous verification of build and deploy identities. |
Replace long-lived pipeline tokens with short-lived NHI credentials and revoke unused access quickly.
