What do teams get wrong about scanning dependencies for malware?

Why This Matters for Security Teams

Dependency scanning is often treated as a source-code hygiene control, but malware in packages can be deliberately quiet until install, import, or runtime. That matters because the security question is not only whether a package contains suspicious strings, but whether it behaves maliciously when executed in a build agent, browser session, or production service. NHI Mgmt Group’s Ultimate Guide to NHIs shows why this is broader than software supply chain hygiene: 79% of organisations have experienced secrets leaks, and 96% store secrets outside dedicated managers in vulnerable locations. Those conditions make malicious dependencies far more damaging once they can observe tokens, alter requests, or exfiltrate credentials.

The common mistake is assuming signature-based or metadata-based package review can prove benign behaviour. In reality, a clean-looking dependency may still tamper with HTTP traffic, proxy browser actions, or wait for specific runtime conditions before activating. Current guidance from the NIST Cybersecurity Framework 2.0 supports layered detection and response rather than a single gate. In practice, many security teams discover dependency abuse only after a package has already run inside a trusted pipeline or workstation, rather than through intentional pre-production review.

How It Works in Practice

Effective dependency malware detection combines static review with behaviour-aware controls. Static scanning still matters for typosquatting, known bad hashes, suspicious maintainers, and embedded indicators. But teams also need sandbox execution, dynamic analysis, and runtime monitoring to see whether a package alters browser requests, injects code, reaches out to command-and-control infrastructure, or attempts to harvest secrets at execution time. That is where simple “scan and approve” workflows usually fail.

A practical approach is to layer controls around the full lifecycle of the dependency:

• Verify package provenance and integrity before download or install.
• Run new or updated packages in an isolated sandbox with network and filesystem telemetry.
• Monitor outbound connections, child process creation, and request manipulation during test and production execution.
• Alert on access to secrets, token stores, browser sessions, and CI/CD variables.
• Revoke or quarantine packages that change behaviour after installation, not just those that contain known signatures.

This is especially important for NHI-heavy environments, where compromised packages can target API keys, service accounts, and automation tokens. The Shai Hulud npm malware campaign is a useful reminder that package abuse often aims at credential theft and downstream trust chains, not just endpoint infection. The NIST guidance on continuous monitoring in NIST Cybersecurity Framework 2.0 aligns with this runtime-first view. These controls tend to break down when packages are auto-deployed into high-privilege CI/CD pipelines because the malicious behaviour executes before human review can intervene.

Common Variations and Edge Cases

Tighter dependency controls often increase build time and operational friction, requiring organisations to balance delivery speed against malware resistance. That tradeoff becomes most visible in fast-moving JavaScript, Python, and container ecosystems where packages update frequently and transitive dependencies can change without direct developer intent.

There is no universal standard for how much runtime analysis is enough yet. Best practice is evolving, but teams should treat the following as high-risk edge cases: packages that manipulate browser requests, dependencies that execute post-install scripts, internal mirrors that repackage third-party code, and agentic automation that installs tools on its own. In those cases, source review alone is especially weak because the malicious logic may be hidden behind environment checks or delayed execution.

Teams should also remember that malware scanning is not the same as trust validation. A package can be open source, widely used, and still dangerous if it captures tokens or modifies outbound traffic. For that reason, runtime signals, secret scanning, and strict egress controls should be considered part of the detection stack, not optional extras. Where organisations lack mature telemetry, the most practical interim step is to gate new dependencies by risk tier and observe their behaviour in a constrained environment before broad rollout.

Related resources from NHI Mgmt Group

• What do security teams get wrong about persistence in Linux malware cases?
• What do security teams get wrong about fileless malware in containers?
• What do security teams get wrong about low-and-slow application probing?
• What do teams get wrong about AI threat modeling?