What should teams do immediately when a supply chain package steals tokens and keys?

Why This Matters for Security Teams

When a supply chain package steals tokens and keys, the incident is not limited to the install host. Those credentials often reach GitHub workflows, cloud APIs, package registries, and internal automation, which means the attacker can turn a single execution into persistence. NHI Management Group research on the State of Secrets Sprawl 2026 shows that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why detection without revocation is usually too slow.

Security teams often underestimate how quickly stolen credentials become operational. A malicious package can exfiltrate secrets during install, then use them to plant backdoors in repositories, tamper with CI jobs, or widen access through trusted service accounts. That is why current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev. 5 both point toward rapid containment, credential invalidation, and traceable recovery rather than simple endpoint cleanup. In practice, many security teams encounter the true blast radius only after the attacker has already used the stolen identity to persist in CI or source control.

How It Works in Practice

The immediate priority is to assume that every credential available during the package execution is compromised. That includes environment variables, local config files, cached cloud tokens, developer CLI sessions, and any short-lived access that could still be replayed. Containment should start with isolating the affected endpoint, then moving outward to systems where the package may have had read access: GitHub, CI runners, artifact stores, package registries, and secret managers. The LiteLLM PyPI package breach and Reviewdog GitHub Action supply chain attack both illustrate how package execution can become credential harvesting at scale.

Practically, teams should treat the response as a credential reconstitution exercise:

• Revoke every token, key, certificate, and session that was present on the endpoint during install.
• Invalidate downstream secrets that those credentials could reach, including cloud roles and CI/CD service accounts.
• Search GitHub, CI logs, build artifacts, and runner caches for persistence, exfiltration, and newly created automation.
• Rebaseline identities by re-issuing only the minimum necessary access after verification.
• Review package lifecycle controls such as allowlisting, provenance checks, dependency pinning, and build isolation.

This response aligns with the NHI management problem described in the Guide to the Secret Sprawl Challenge: secrets are distributed across too many systems to rely on manual cleanup. The operational goal is not merely to remove malware, but to ensure every compromised NHI is rotated before it can be reused. These controls tend to break down when secrets are embedded in CI runner images or developer laptops without central inventory, because responders cannot prove which identities were exposed.

Common Variations and Edge Cases

Tighter revocation often increases operational disruption, requiring organisations to balance blast-radius reduction against service continuity. That tradeoff matters most when the stolen package ran in a shared build environment, because a single install may have accessed multiple projects, tenants, or deployment pipelines. In those cases, guidance is still evolving on how much automation is appropriate, but current best practice is to revoke first and restore access selectively after scope is known.

Edge cases also appear when the compromised package touched identities that are long-lived by design, such as release engineering accounts, deployment keys, or third-party integration tokens. Those should be converted to shorter-lived credentials where possible, with stronger lifecycle controls and tighter scoping. The Salesloft OAuth token breach shows why token theft often becomes downstream application abuse, not just infrastructure compromise. For teams with mature controls, the practical lesson is to pair incident response with package governance so that a future install cannot execute with broad secret access in the first place. In environments with federated CI, ephemeral runners, or secrets injected at runtime, the response becomes harder because the same token may exist in multiple ephemeral contexts at once.

Related resources from NHI Mgmt Group

• What should teams do after a supply chain package has exposed wallet keys?
• How should teams contain a supply-chain worm once it reaches CI?
• What should teams do after a supply chain implant is discovered on a workstation?
• How do attackers turn a supply-chain incident into wider NHI compromise?