Why do CI runners and publishing tokens make package compromise worse?

Because they convert a one-time execution event into durable access. If the compromised package can reach tokens that publish code, access cloud resources, or move between repositories, the attacker can repurpose legitimate automation identities for persistence and downstream spread.

Why This Matters for Security Teams

ci runner and publishing tokens turn software delivery into a high-trust execution path, which is why package compromise becomes a supply chain event rather than a single bad build. Once an attacker reaches a runner, the problem is not just malicious code in the package. It is the automation identity that can sign artifacts, publish releases, access registries, or call cloud APIs with legitimate permissions.

That changes the blast radius. A compromised package can inherit the privileges of the pipeline that built or published it, and those privileges often outlive the code itself. Current guidance from NIST SP 800-53 Rev. 5 on least privilege and integrity monitoring still applies, but package pipelines introduce a harder question: which identities should exist only long enough to complete one trusted task? NHIMG has repeatedly documented how exposed automation credentials remain exploitable long after the initial incident, including in the The 52 NHI breaches Report.

In practice, many security teams discover this only after a runner account has already been used to publish a tampered artifact or pivot into downstream systems, rather than through intentional token lifecycle design.

How It Works in Practice

The core failure mode is credential reuse across automation boundaries. A CI runner is often granted access to source, package registries, cloud environments, and signing systems so it can complete builds without human intervention. A publishing token may then be injected into the same job, creating a direct path from code execution to release authority. If the package or dependency is compromised, the attacker does not need to break into a separate admin account. They can simply abuse the automation context already present in the job.

Mitigation starts with separating build, test, sign, and publish responsibilities. Use short-lived, task-scoped credentials instead of static tokens, and prefer workload identity backed by OIDC, SPIFFE, or similar cryptographic proof of what the runner is, not just what secret it holds. The practical aim is to make access ephemeral and auditable:

• Issue credentials per job, not per runner image.
• Limit publish tokens to a single registry, repo, or environment.
• Rotate and revoke immediately after completion.
• Bind approval gates to the release step, not the build step.
• Detect unusual runner-to-cloud or runner-to-registry calls in real time.

For compromise patterns, the Guide to the Secret Sprawl Challenge is a useful reference because it shows how secrets proliferate across code, tickets, and automation tooling. On the external side, Anthropic’s report on an AI-orchestrated campaign is a reminder that autonomous tooling can chain actions quickly once it has valid access, which is exactly why static pipeline secrets are so risky. These controls tend to break down when a single shared runner image is reused across many repositories because one compromise can inherit too many trust relationships at once.

Common Variations and Edge Cases

Tighter pipeline controls often increase operational overhead, requiring organisations to balance release speed against the cost of more frequent token issuance, approval checks, and identity federation setup. There is no universal standard for this yet, so current guidance suggests matching control strength to the sensitivity of what the pipeline can publish or sign.

Some teams treat self-hosted runners as safer than SaaS runners, but that only helps if the runner is isolated, ephemeral, and strongly segmented from registry and cloud credentials. Shared runners, long-lived tokens, and broad repo-wide permissions are especially dangerous in monorepos, multi-package publishing setups, and hybrid CI systems where one job can reach multiple deployment targets. This is where NHIMG case studies such as the Salesloft OAuth token breach and the Vercel Context.ai OAuth Supply Chain Breach matter: durable tokens do not just enable release automation, they enable downstream spread if exposed.

Best practice is evolving toward zero standing privilege for pipelines, but where artifact signing, provenance attestation, or cross-repository publishing are involved, teams often still need narrowly scoped exceptions. Those exceptions should be short-lived, monitored, and tied to a specific release event, because static privilege is what turns package compromise into persistent infrastructure compromise.

Related resources from NHI Mgmt Group

• Why do CI/CD service accounts and publishing tokens need the same governance as human access?
• Why do CI runners and developer workstations increase supply-chain identity risk?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• What actions should I take if my OAuth tokens are compromised?