Why do CI runners and developer workstations increase supply-chain identity risk?

Why This Matters for Security Teams

CI runners and developer workstations are high-risk because they combine execution of untrusted code with direct access to sensitive identity material. That includes package tokens, cloud metadata, GitHub context, Kubernetes service account material, and secrets cached for convenience. When a build step or plugin runs, it can turn a routine software task into credential collection and abuse. The risk is not only theft, but propagation through the software supply chain.

NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a strong signal that these environments deserve the same scrutiny as production workloads. The control gap is amplified by the fact that 96% of organisations still store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

Practitioners often assume the danger is limited to the build artifact, but the more common failure is credential exposure on the machine that assembled it. In practice, many security teams encounter lateral movement only after a routine pipeline or developer plugin has already harvested live secrets and republished them elsewhere.

How It Works in Practice

The core problem is concentration of privilege on endpoints that routinely execute third-party code. A CI runner may fetch dependencies, install build tools, unpack archives, run tests, and authenticate to registries in the same session. A developer workstation does the same, but with even less isolation and more ambient trust. That creates a broad attack surface for package scripts, pre-commit hooks, IDE extensions, and malicious dependency chains, as shown in NHIMG research such as Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack.

Current guidance suggests treating these systems as transient execution zones rather than trusted identity holders. That means separating workload identity from human login state, issuing short-lived credentials per job, and limiting token scope to the exact repository, branch, environment, or registry needed for the task. Standards work such as the OWASP Non-Human Identity Top 10 reinforces the need to reduce standing secrets and improve lifecycle control. On the implementation side, workload identity patterns such as OIDC federation and SPIFFE-style attestation are preferred because they prove what the runner is at request time, not just what secret it can present.

• Issue ephemeral, per-job credentials and revoke them automatically at completion.
• Prefer workload identity over long-lived shared tokens whenever possible.
• Block broad cloud metadata access and restrict secret mount paths on runners.
• Separate build, test, and release permissions so a compromised step cannot sign or publish.
• Log secret access and token use as part of the pipeline audit trail.

NIST’s NIST Cybersecurity Framework 2.0 aligns with this by emphasizing access governance, monitoring, and response, but these controls tend to break down when self-hosted runners share persistent disks and cached credentials with multiple repositories because one compromise can inherit the trust of many jobs.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance developer velocity against credential exposure and pipeline fragility. That tradeoff becomes sharper in environments that rely on legacy build scripts, monorepos, or self-hosted runners that cannot easily be made ephemeral.

Best practice is evolving for these cases. Some teams can move quickly to full JIT provisioning, while others must start by shrinking token scope, splitting duties between build and release stages, and replacing static deploy keys with short-lived federated access. NHIMG’s Top 10 NHI Issues and the 52 NHI Breaches Analysis both show that weak rotation, overprivilege, and poor visibility are recurring themes, not isolated mistakes.

There is no universal standard for every CI platform yet, especially where third-party marketplace actions or internal plugins need broad access to secrets. In those environments, the safest approach is to assume the execution environment is hostile, constrain what it can reach, and make every credential short-lived and narrowly scoped. That becomes even more important when developer laptops are allowed to act as signing authorities or release operators, because a compromised workstation can bypass many protections that exist inside the CI platform itself.

Related resources from NHI Mgmt Group

• Why do developer workstations increase the blast radius of supply-chain malware?
• Why do developer workstations increase supply-chain risk so quickly?
• Why do shared data directories increase supply chain risk in ML pipelines?
• Why do CI secrets and developer tokens increase supply chain risk?