What do security teams get wrong about supply chain scanning for open source package threats?

Why This Matters for Security Teams

Supply chain scanning is often treated like a code-quality control, but open source package threats are usually an identity, trust, and execution problem. A scanner that only matches known CVEs will miss freshly uploaded typosquats, malicious maintainer takeovers, and install-time code paths that never appear in a vulnerability database. That gap is why practitioners need to look at package provenance, publisher reputation, and runtime behavior alongside static findings.

This is not theoretical. NHIMG research on the PyPI Breach and the Shai Hulud npm malware campaign shows how package ecosystems can be abused to deliver secrets theft and downstream compromise long before conventional signatures catch up. OWASP’s Non-Human Identity Top 10 also reinforces that software identities, tokens, and automation credentials are attractive targets when package install scripts can reach them.

Security teams often discover the problem only after a build system, developer workstation, or CI runner has already executed the malicious package and exposed credentials in the process.

How It Works in Practice

Effective package threat detection needs more than dependency resolution. Current guidance suggests combining several layers because each one covers a different failure mode. Static scanning still matters for known vulnerable versions, but it should be paired with package intelligence and behavioural checks that can surface suspicious new uploads, maintainer impersonation, or hidden install logic.

In practice, teams should evaluate:

• Package provenance: who published it, when it was first seen, and whether the account history looks normal.
• Repository context: commit patterns, release cadence, issue activity, and signs of sudden ownership change.
• Install-time and post-install behaviour: scripts that fetch remote content, decode blobs, or touch sensitive files.
• Runtime execution: whether the package spawns shells, reaches token stores, or contacts unusual domains.
• Secret exposure impact: whether CI, developer laptops, or build agents hold credentials that a package can steal.

That is why the best practice is evolving toward source review plus runtime telemetry, not just artifact scanning. NIST’s SP 800-53 Rev. 5 remains useful here because it frames integrity, monitoring, and configuration management as operational controls rather than one-time checks. NHIMG’s The State of Secrets in AppSec research is also relevant because package attacks frequently become secrets incidents once exposed tokens are harvested from local environments or pipelines.

These controls tend to break down in fast-moving CI pipelines that automatically trust newly published packages, because the package is executed before reputation and behaviour checks can complete.

Common Variations and Edge Cases

Tighter package controls often increase build friction and review overhead, requiring organisations to balance delivery speed against the risk of executing untrusted code. That tradeoff is real, especially for teams that consume large dependency trees or rely on frequent updates.

There is no universal standard for this yet, but a practical split is emerging. For low-risk internal libraries, teams may accept lighter screening and stronger change control. For internet-facing apps, build tooling, and any package that can run install hooks, current guidance suggests a stricter gate: quarantine first-seen packages, require manual approval for ownership changes, and block network access during install where possible.

Edge cases also matter. A package can be legitimate today and compromised tomorrow through maintainer takeover. A dependency can appear harmless in source form but generate dangerous behaviour only during install. And some threats will never look like malware until they trigger secret access or lateral movement. NHIMG’s LiteLLM PyPI package breach and Nx Package Attack cases are strong examples of why execution context matters as much as the package name.

For teams aligning to external guidance, the Anthropic cyber espionage report is a reminder that automated systems can chain tools quickly once trust is misplaced, while CISA’s cyber threat advisories are useful for tracking active supply chain tactics as they evolve.

Related resources from NHI Mgmt Group

• What do security teams get wrong about package provenance in supply-chain attacks?
• What do security teams get wrong about using package version checks as their main supply chain defense?
• What do security teams get wrong about agentic supply chain risk?
• What do security teams get wrong about MCP supply-chain risk?