Who is accountable when a supply chain worm uses stolen tokens to create infrastructure?

Why This Matters for Security Teams

When a supply chain worm uses stolen tokens to create infrastructure, accountability rarely sits with one incident response team. The failure usually spans CI/CD identity, secrets governance, repository permissions, and the controls that let automation act like a trusted operator. That is why this belongs in NHI governance as much as malware response. The 52 NHI Breaches Analysis shows how often identity abuse, not code execution alone, becomes the real blast radius.

Current guidance suggests treating stolen pipeline tokens as infrastructure-building credentials, not ordinary app secrets. If a token can create repos, change workflows, or spin up cloud resources, then the organisation has granted machine identities standing power that outlives the task that created them. NIST control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce the need for access enforcement, auditing, and revocation discipline across automated systems.

In practice, many security teams encounter the worm only after repositories, runners, and cloud accounts have already been chained together through valid tokens, rather than through intentional access governance.

How It Works in Practice

Accountability starts with ownership of the control plane, not just the malware cleanup. The teams that run source control, CI/CD, secrets storage, and cloud provisioning must be able to answer four questions: what identity issued the token, what it can do, how quickly it can be revoked, and whether its activity is constrained by policy at request time. That maps directly to the non-human identity problem described in The State of Secrets in AppSec, where secret leakage and slow remediation remain persistent operational weaknesses.

In a worm scenario, a stolen token often behaves like a privileged workload identity. It may authenticate to a package registry, modify a workflow file, trigger a build, and then use the build runner to reach more systems. This is why static role-based access control is weak on its own. Autonomous or semi-autonomous abuse does not follow a fixed human job pattern. Best practice is evolving toward just-in-time, short-lived credentials, explicit token scoping, and real-time policy checks using policy-as-code. The threat pattern is well illustrated by the Miasma and Hades Supply Chain Worms research, where propagation depended on trusted automation paths.

• Assign an owner for every token class, including CI service tokens, registry tokens, and release automation tokens.
• Use workload identity and ephemeral issuance instead of reusable long-lived secrets where possible.
• Require immediate revocation paths for token theft, workflow compromise, and runner abuse.
• Log identity, action, and environment context so investigators can distinguish abuse from legitimate automation.
• Constrain build systems so a valid token cannot become a general-purpose infrastructure creation key.

In practice, these controls tend to break down when CI/CD runners inherit broad cloud permissions and can mint new infrastructure without a second authorization step.

Common Variations and Edge Cases

Tighter token controls often increase delivery friction, requiring organisations to balance deployment speed against blast-radius reduction. That tradeoff is real in release engineering, but current guidance suggests that automation convenience should never outrank revocation speed and privilege containment. The question becomes sharper when internal tooling, partner integrations, or GitHub Apps can act across multiple repositories. The GitHub Repo Breach - Heroku and Travis CI OAuth Tokens is a reminder that trusted integrations can become a supply chain path if scopes are too broad.

There is no universal standard for this yet, but the consensus is moving toward per-task authorization, short TTLs, and separation between code access and infrastructure creation rights. A token that can read a repo should not automatically be able to create runners, rotate webhooks, or approve workflow changes. The same applies when secret sprawl spans multiple systems. The State of Secrets Sprawl 2026 shows that valid leaked secrets can remain exploitable long after detection, which makes automated revocation as important as detection.

Edge cases include air-gapped build networks, monorepos with shared automation, and managed CI platforms where identity boundaries are less visible. In those environments, the accountable team is still the one that owns the trust relationship, even if the worm exploited a vendor-hosted runner or a third-party app.

Related resources from NHI Mgmt Group

• Why do stolen publishing tokens create such a large supply chain risk?
• How can security teams detect package supply chain attacks that hide their C2 infrastructure?
• What breaks when a supply chain worm can use maintainer credentials to republish packages?
• Why do lookalike package names create such a high-risk supply-chain failure mode?