When does a CI/CD pipeline become a security risk?

Why This Matters for Security Teams

A CI/CD pipeline stops being a delivery system and becomes a security risk when it can move code or artifacts without proving who changed what, who approved it, and whether the signing path was protected end to end. That is not a theoretical edge case. It is the point where source control, build runners, secrets, and release permissions collapse into one blast radius. NHI Management Group sees this as a workload identity and secrets governance problem as much as an engineering one.

GitGuardian’s research shows why the stakes keep rising: 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, which means the pipeline itself can become the attacker’s foothold. In practice, many security teams encounter this only after a trusted workflow has already published malicious artifacts, rather than through intentional control testing. See the CI/CD pipeline exploitation case study and the NIST Cybersecurity Framework 2.0 for the governance pattern behind this risk.

How It Works in Practice

The practical failure mode usually starts with over-trusted automation. A build job inherits broad repository access, long-lived secrets, or a signing credential that is available whenever the runner starts. If that job can accept unverified code, pull dependencies from unpinned sources, or promote artifacts with weak approval logic, then the pipeline can be used to inject malware at scale. The risk is amplified when secrets live in environment variables, when runners are shared across projects, or when approvals are treated as a checkbox instead of a real decision point.

Strong practice is to separate identity, approval, and secret exposure. That means workload identity for the runner, short-lived credentials for the job, and policy checks that evaluate the request at runtime. Where possible, use JIT credentials that expire when the task ends, rotate or revoke immediately after use, and bind signing operations to a controlled release step rather than the whole build. Current guidance also favours attestation for provenance, because artifact trust is only meaningful if the pipeline can prove the build inputs and the execution context.

• Use dedicated runner identities instead of shared admin tokens.
• Keep signing keys out of general build jobs and require step-up approval.
• Prefer ephemeral secrets and automatic revocation over static credentials.
• Gate promotion on provenance, code review, and policy checks together.

The Reviewdog GitHub Action supply chain attack is a good reminder that trusted actions and reusable workflow components can carry hidden exposure, while the Guide to the Secret Sprawl Challenge explains why secrets spread faster than teams can manually contain them. These controls tend to break down when self-hosted runners are reused across trust zones because identity, secrets, and execution context are no longer isolated.

Common Variations and Edge Cases

Tighter pipeline control often increases delivery overhead, requiring organisations to balance release speed against the cost of stronger approvals, isolated runners, and short-lived secrets. There is no universal standard for this yet, so current guidance suggests risk-based segmentation rather than forcing every pipeline into the same model.

Some environments are especially tricky. Multi-repo monorepos can obscure which component actually needs access. External contributors may require test access but never release access. AI-assisted commit and review workflows add another layer, because generated changes can hide dependency updates or secret leakage in ways human reviewers miss. In these cases, intent-based authorization is more reliable than static RBAC alone: the system should decide whether this specific pipeline action is allowed, with context about the artifact, environment, and approval state. That is also where workload identity matters, because the runner must prove what it is before it is granted anything.

For teams formalising the control model, the Shai Hulud npm malware campaign shows how package trust can be abused through pipeline dependencies, and the NIST Cybersecurity Framework 2.0 remains a useful baseline for mapping these controls into governance. If the pipeline can sign, publish, or deploy without a per-task trust decision, it is already operating beyond safe bounds.

Related resources from NHI Mgmt Group

• How should security teams reduce ransomware risk from remote access credentials?
• When does code injection become a supply chain risk?
• What is workload identity federation and why is it important for CI/CD security?
• How do I implement secrets scanning in a CI/CD pipeline?