Why do malicious package incidents so often become identity incidents?

Why Malicious Packages Turn Into Identity Incidents

The package is often just the delivery mechanism. The real damage starts when malware lands on a developer workstation, CI runner, notebook, or build host that already holds reusable secrets. Those environments routinely contain cloud tokens, signing keys, API keys, and service credentials, which means a single compromised dependency can become a direct path into broader infrastructure. NHI Management Group’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks. That is why package compromise so often becomes identity compromise, not merely endpoint compromise.

Security teams also underestimate how quickly identity abuse outlives the original payload. Once a token is stolen, an attacker can authenticate through normal channels, blend into trusted workflows, and pivot into cloud control planes or CI/CD systems even after the malicious package is removed. The same pattern shows up in incidents such as the LiteLLM PyPI package breach and the Shai Hulud npm malware campaign, where credential exposure became the real incident surface. In practice, many security teams encounter identity abuse only after the package has been contained, rather than through intentional secrets governance.

How the Attack Chain Actually Works

Malicious packages rarely need deep exploitation. They need execution in an environment where identities are already present and reachable. A common sequence is simple: a developer installs or builds a package, the payload scans local files, environment variables, credential stores, browser profiles, or shell history, then exfiltrates anything usable. From there, the attacker does not need to keep using the package. They use the stolen identity to authenticate as a legitimate workload, which is much harder to distinguish from normal traffic.

This is why package risk has to be treated as an identity problem. The best evidence of trust is not whether the package was signed or popular, but whether the environment it touched had tightly scoped, short-lived access. Current guidance suggests reducing blast radius by separating human developer access from machine access, issuing ephemeral credentials only when a task requires them, and keeping high-value secrets out of local disk entirely. NIST control families such as NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce least privilege, auditability, and secure credential handling, but the operational translation for packages is more specific:

• use per-build or per-job identities instead of shared service accounts;
• store secrets in a managed vault and inject them at runtime only when needed;
• rotate and revoke tokens automatically after each job or session;
• monitor for unusual token use from package-install or build contexts;
• treat dependency execution as a privileged event, not a routine software action.

NHIMG’s breach research, including the 52 NHI Breaches Analysis and the Cisco DevHub NHI breach, shows the same pattern across environments: once a secret is exposed, attackers move into the identity layer and keep using legitimate access paths. These controls tend to break down when build systems reuse long-lived credentials across many jobs because one stolen token then grants broad, persistent access.

Where the Standard Advice Breaks Down

Tighter package controls often increase developer friction and pipeline maintenance, so organisations have to balance speed against credential containment. That tradeoff matters because the easiest controls to adopt are often the least effective if they leave static secrets in place.

There is no universal standard for every environment yet, but a few edge cases are predictable. Air-gapped systems can still fail if signed packages are mirrored with embedded secrets. Notebook environments are especially risky because interactive users often copy credentials into cells, config files, or mounted volumes. Monorepos and shared runners amplify exposure when many teams inherit the same token scope. And in AI-assisted development, package installs may run alongside tools that already hold access to source, tickets, logs, and cloud APIs, which widens the identity blast radius. Anthropic’s report on the first AI-orchestrated cyber espionage campaign shows how quickly tool access can be chained once an attacker gets a foothold in a trusted workflow: Anthropic — first AI-orchestrated cyber espionage campaign report.

For that reason, current best practice is evolving toward explicit workload identity, runtime policy checks, and secretless execution where possible. When teams cannot eliminate static credentials, they should at least shorten TTLs, scope tokens narrowly, and assume package execution is a common credential theft vector. The real lesson from modern incidents is that supply chain compromise is often just the first step in an identity attack.

Related resources from NHI Mgmt Group

• How should teams reduce risk from malicious npm package installs?
• Why do supplier compromises often become enterprise identity incidents?
• Why do npm supply-chain incidents so often become identity incidents?
• Why does identity matter more when vulnerabilities are discovered faster than they can be patched?