Why do malicious packages create NHI risk as well as AppSec risk?

Why This Matters for Security Teams

Malicious packages are not just supply chain risk in the abstract. They often execute in build agents, developer workstations, and automation runners that already contain secrets, tokens, and cloud credentials. Once a package runs, the issue shifts from code integrity to identity abuse: the attacker can steal non-human identities in practice and reuse them across source control, CI/CD, and cloud services. That makes package hygiene an NHI governance problem as much as an AppSec problem.

NHIMG research shows how often this exposure is already material. The Ultimate Guide to NHIs notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 79% have experienced secrets leaks with tangible damage in 77% of those cases. That context matters because a malicious dependency does not need to “break out” of the application if the runtime already has standing access to valuable systems. The relevant baseline from NIST Cybersecurity Framework 2.0 is that supply chain assurance and identity control have to be treated together, not as separate workstreams.

In practice, many security teams encounter the identity impact of a malicious package only after secrets have already been exfiltrated and reused, rather than through intentional detection of the package itself.

How It Works in Practice

A malicious package typically succeeds because it inherits the privileges of the environment that installs or runs it. If that environment has a CI token, cloud API key, npm or PyPI publish credential, GitHub token, or service account secret, the package can read environment variables, inspect local files, call internal tooling, or beacon data to an external endpoint. The package does not need to own the application code base to become a compromise path into NHI assets.

The NHI angle becomes clearer when the stolen material is a reusable credential rather than a one-time session artifact. A long-lived token behaves like a standing identity with broad reach, especially when it is not bound to a workload, scoped tightly, or rotated quickly. The LiteLLM PyPI package breach and the Shai Hulud npm malware campaign both illustrate the same pattern: code execution becomes credential theft, then credential theft becomes lateral movement. That is why current guidance increasingly treats runtime secret exposure as an identity issue, not just a software issue.

• Reduce standing privilege in build and runtime environments so packages inherit less authority.
• Use short-lived, task-bound credentials where possible instead of durable API keys.
• Isolate dependency installation from production secrets and production network paths.
• Monitor for token use after package install, not only for known malicious signatures.

For teams building stronger control baselines, NIST SP 800-53 Rev. 5 Security and Privacy Controls provides useful control language for least privilege, audit logging, and credential management, while NHIMG’s Top 10 NHI Issues highlights why secret sprawl and weak rotation remain recurring failure points. These controls tend to break down when build pipelines share persistent secrets across many jobs because a single compromised package can harvest credentials from multiple execution contexts.

Common Variations and Edge Cases

Tighter dependency controls often increase developer friction and pipeline overhead, so organisations must balance release speed against the risk of secret exposure. That tradeoff gets sharper in polyglot pipelines, ephemeral runners, and agentic workloads where a package may execute with broad filesystem or network reach.

There is no universal standard for this yet, but current guidance suggests treating package execution environments as hostile by default and constraining the NHI blast radius around them. A package imported into a notebook, serverless function, or CI job can reach different credentials depending on how the runtime injects variables and mounts files, so the same malicious artifact may have very different impact across environments. This is why the 52 NHI Breaches Analysis and NHIMG’s Key Challenges and Risks section are so relevant: exposure usually becomes visible only after credentials are reused outside the original boundary.

Edge cases include internal packages that appear trusted but are compromised upstream, malware that waits for a target secret to appear, and environments that rotate credentials too slowly for short-lived compromise windows. Best practice is evolving toward workload-scoped identity, just-in-time secrets, and request-time policy evaluation, but there is no universal standard for how much automation is enough. The practical question is not whether a package is “trusted,” but whether the environment lets it observe, copy, or replay identities that were never meant for it.

Related resources from NHI Mgmt Group

• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• How should teams reduce risk from malicious npm package installs?
• Why do developer workstations create NHI risk as well as human identity risk?