Runners often contain the exact credentials attackers want, including registry tokens, cloud access keys, and .env material. They also install dependencies non-interactively, so a postinstall script can run before anyone notices. When those two conditions combine, package abuse becomes a direct secrets collection problem.
Why This Matters for Security Teams
CI/CD runners are high-value execution environments because they sit between source code, build tools, artifact publishing, and deployment credentials. When a malicious package is introduced, the risk is not just arbitrary code execution. The more serious issue is what that code can read from the runner at runtime: secrets cached in environment variables, file-based tokens, cloud credentials, signing material, and short-lived credentials that were meant to be limited in scope.
This is why dependency abuse should be treated as a secrets exposure problem, not only a supply chain problem. Guidance from the NIST Cybersecurity Framework 2.0 reinforces asset visibility, access control, and secure execution as core defensive outcomes. In practice, runner hardening matters because build jobs frequently inherit more privilege than developers expect, and package install steps can execute before any inspection or isolation response is possible.
Teams often miss this because they focus on repository compromise and overlook the runner as the place where identity, secrets, and untrusted code intersect. In practice, many security teams encounter runner-based secrets theft only after an innocuous dependency has already been installed and its side effects have already exfiltrated credentials.
How It Works in Practice
Most CI/CD systems resolve packages automatically during build or test jobs. If a malicious package includes a lifecycle hook, import-time action, or setup script, it can run inside the runner with the same OS context and network reach as the job itself. That is enough to enumerate environment variables, read mounted files, inspect configuration directories, and attempt outbound exfiltration before the pipeline finishes.
The problem becomes more severe when the runner has access to secrets intended for downstream steps. A cloud deploy token, container registry password, signing key, or NPM/PyPI publish credential may be present for convenience, even if the current job only needs to compile or lint. The OWASP Non-Human Identity Top 10 is useful here because runners behave like machine identities: they are non-human execution principals that often accumulate standing access and broad secret visibility.
Operationally, effective controls usually combine several measures:
- Use isolated, ephemeral runners so secrets do not persist across jobs.
- Scope secrets to the minimum job stage that actually needs them.
- Block untrusted package lifecycle scripts where possible, or require allowlisting.
- Separate build, test, and publish duties so a compromised dependency cannot reach release credentials.
- Prefer short-lived credentials and federated workload identity over static secrets.
The control intent also maps well to NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially controls around least privilege, information flow, and system integrity. These controls tend to break down when self-hosted runners are reused across projects because credential residue and network reach create a larger blast radius than the pipeline design assumes.
Common Variations and Edge Cases
Tighter runner isolation often increases build complexity and operational overhead, requiring organisations to balance faster pipelines against reduced credential exposure. That tradeoff becomes sharper in monorepos, shared build farms, and highly parallel release environments where teams want speed but also need strict separation.
There is no universal standard for this yet, but current guidance suggests treating any runner that can access deployment secrets as a privileged workload, not a disposable utility. That means the same scrutiny used for privileged access should apply to pipeline identities: who can trigger them, what secrets they can reach, and whether they can reach production systems at all. This is where NHI governance becomes relevant, because the runner is effectively a machine identity with execution authority.
Edge cases matter. Self-hosted runners behind restrictive firewalls may reduce exfiltration paths, but they do not eliminate theft if the malicious package can write to logs, artifact stores, or internal services. Likewise, containerized runners help, but container boundaries are not enough if the job mounts host volumes or injects broad environment variables. The safest approach is to assume package code is hostile until proven otherwise, then limit both the secrets available and the places they can be sent.
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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | Runners act like machine identities with secret access and execution authority. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is central to limiting what a compromised runner can access. |
| NIST SP 800-53 Rev 5 | AC-6 | Privilege minimisation reduces the blast radius of malicious package execution. |
Treat each runner as a non-human identity and scope its credentials to the minimum task.
