Why do malicious packages create identity risk as well as supply chain risk?

They become identity risk when install-time access includes cloud tokens, signing keys, or service credentials. A malicious dependency can then use those secrets to move from code execution into cloud access, data theft, or further compromise. That is why secrets containment and workload identity controls belong in supply chain policy.

Why This Matters for Security Teams

Malicious packages are no longer just a software integrity problem. They become an identity problem the moment build systems, developer machines, or CI jobs expose cloud tokens, API keys, signing credentials, or other secrets during install or test execution. At that point, the package can pivot from executing code to using legitimate credentials, which is far harder to detect than a simple malware alert. This is why supply chain security and identity governance now overlap directly with workload access control.

The risk is especially acute where package scripts run with broad privileges, where secrets are injected into environments automatically, or where third-party dependencies are trusted by default. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to manage external dependencies, protect credentials, and detect abnormal use of legitimate access paths. NHI Management Group sees this pattern repeatedly in environments that treat dependency risk as code hygiene but treat secrets exposure as a separate problem.

In practice, many security teams encounter the identity impact only after a dependency has already used valid access to reach cloud resources, signing services, or production data.

How It Works in Practice

The mechanism is usually straightforward. A package is installed, a build hook or post-install script runs, and the malicious code looks for secrets in environment variables, config files, runtime metadata, local key stores, or mounted volumes. If the pipeline or workstation exposes a token with broad scope, the package can exfiltrate it and reuse it outside the original trust boundary. That turns a software dependency into an identity-bearing actor.

What makes this difficult is that the resulting activity often looks legitimate. The attacker may use the same cloud identity, the same service account, or the same signing workflow the team relies on every day. Current best practice is to treat package execution as a potential credential access event, not only a code review issue. In mature environments, this means combining software supply chain controls with workload identity controls and secrets governance, consistent with OWASP Non-Human Identity Top 10 guidance.

• Limit package-install privileges so scripts cannot inherit unnecessary access.
• Use short-lived credentials instead of long-lived secrets in CI and build tools.
• Scope service accounts to the minimum resources required for each job.
• Isolate signing keys, deployment tokens, and cloud credentials from general build contexts.
• Monitor for unusual use of legitimate identities after dependency installation or update events.

Security teams should also map these controls to baseline safeguards in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, system and communications protection, and auditability. These controls tend to break down when legacy build pipelines require static secrets, because the same credentials are reused across many jobs and cannot be cleanly rotated.

Common Variations and Edge Cases

Tighter secrets containment often increases build complexity and operational overhead, requiring organisations to balance deployment speed against reduced blast radius. That tradeoff becomes visible in heterogeneous environments where teams mix local development, ephemeral CI runners, self-hosted build agents, and cloud-native pipelines.

There is no universal standard for this yet on every toolchain, but current guidance suggests prioritising identity-aware controls where code execution can touch sensitive access. For example, dependency scanning alone will not stop a malicious package that abuses a mounted cloud token, and malware detection alone may not flag a package using approved service credentials. The harder cases are packages that only activate under certain conditions, or only target a specific cloud provider, registry, or signing workflow.

Edge cases also appear in AI-assisted build systems and agentic automation. If an AI agent can install dependencies or manage release tooling, then its own execution identity becomes part of the supply chain risk surface. That is where NHI governance matters most: every machine identity, service principal, and automation token should be treated as a potential target for package-level abuse. In environments with tightly controlled ephemeral runners and no persistent secrets, the risk is lower, but it is never zero because provenance failures and token leakage can still cascade through trusted automation.

For teams formalising controls, the most useful lens is to join supply chain assurance with identity lifecycle governance rather than treating them as separate programmes.

Related resources from NHI Mgmt Group

• Why do developer workspaces create supply-chain risk when identity is misvalidated?
• Why do hallucinated packages create supply-chain risk even when the model is not directly compromised?
• Why do GitHub-based supply chain attacks create identity risk for cloud environments?
• Why does supply-chain trust create so much identity risk?