What is the difference between package scanning and runtime monitoring for npm supply chain attacks?

Package scanning checks code and metadata before deployment, which helps catch suspicious scripts, oversized payloads, and obvious obfuscation. Runtime monitoring watches what the package actually does during install and execution, including network calls, file access, and process behavior. For supply chain threats, both matter because malicious behavior often appears only after the package starts.

Why Security Teams Need Both Signals

Package scanning and runtime monitoring answer different questions about npm supply chain risk. Scanning tries to stop suspicious code before it reaches production, while runtime monitoring looks for the behavior that only appears once install hooks or application code executes. That distinction matters because malicious npm packages often hide payloads in lifecycle scripts, compressed blobs, or delayed execution paths that static review can miss. NHIMG’s research on the Shai Hulud npm malware campaign shows how quickly attackers can abuse package trust to reach secrets and developer systems, and the broader pattern is consistent with CISA cyber threat advisories: defenders need both pre-deployment and in-execution visibility.

For teams managing software pipelines, the real issue is not whether a package looks clean on inspection, but whether it behaves safely under real install conditions, with real network access, real filesystems, and real credentials present. That is why package scanning is best treated as a gate and runtime monitoring as a detector. In practice, many security teams encounter malicious behavior only after a trusted dependency has already run with developer or CI privileges, rather than through intentional review.

How Package Scanning and Runtime Monitoring Work Together

Package scanning analyzes the artifact before deployment. For npm, that usually means reviewing package metadata, dependency trees, install scripts, minified or obfuscated code, unusual versioning patterns, and payload size anomalies. It is good at catching obvious indicators such as suspicious preinstall or postinstall hooks, impossible release histories, and known-bad package names. It is also useful for policy enforcement when combined with allowlists, lockfile review, and provenance checks.

Runtime monitoring watches what the package actually does after it starts. That includes outbound network requests, file creation and modification, process spawning, environment variable access, token harvesting, and attempts to enumerate cloud or source control credentials. This is where many npm attacks become visible, because malicious logic may be dormant until installation or until the package runs inside a developer workstation, CI job, or build container.

Current guidance suggests treating these as complementary controls rather than alternatives. OWASP Non-Human Identity Top 10 and NHIMG’s 52 NHI Breaches Analysis both reinforce the same operational lesson: package trust often becomes identity abuse once the code executes. A practical workflow is to scan on ingest, sandbox on install, and monitor runtime behavior in CI and developer endpoints, with alerts for network beacons, secret reads, and unexpected child processes.

• Scan for lifecycle scripts, obfuscation, and dependency anomalies before installation.
• Run installs in a sandbox that records filesystem and process activity.
• Watch for outbound connections to unfamiliar hosts during install or test runs.
• Correlate behavior with secrets access, token use, and credential exfiltration attempts.

These controls tend to break down when packages are installed in highly permissive CI runners or developer laptops with broad secret access, because the telemetry arrives too late to stop the first credential grab.

Where the Tradeoffs and Edge Cases Show Up

Tighter runtime control often increases friction, requiring organisations to balance build speed and developer autonomy against better detection of malicious behavior. That tradeoff is especially visible in npm ecosystems with frequent installs, ephemeral build agents, and legitimate packages that use dynamic network calls or postinstall steps for normal functionality.

There is no universal standard for this yet, but best practice is evolving toward layered controls: static scanning for known risk patterns, policy checks for provenance and dependency hygiene, and runtime instrumentation for behavior that only emerges during execution. For teams handling sensitive build environments, the most useful signal is often the combination of a clean scan with abnormal runtime activity, not either control alone. NHIMG’s LiteLLM PyPI package breach and the Shai Hulud npm malware campaign are useful reminders that supply chain compromise often becomes a secrets problem quickly, especially when build systems retain long-lived credentials.

Runtime monitoring is less effective when packages are executed in offline environments with minimal telemetry or when defenders cannot distinguish legitimate install-time behavior from malicious activity. In those cases, the safest assumption is that scanning and sandboxing must compensate for limited observation.

Related resources from NHI Mgmt Group

• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between vulnerability scanning and supply chain governance?
• What is the difference between protecting developer credentials and protecting package integrity in a supply chain attack?
• What is the difference between code-only AppSec scanning and end-to-end software supply chain visibility?