Yes, when the attack path depends on install-time execution. Dependency scanning still matters for inventory and known bad packages, but it cannot show what actually ran. Runtime controls are what catch postinstall behaviour, malicious process trees, and the secret access that follows.
Why runtime controls beat scanning when npm packages execute on install
Dependency scanning answers inventory questions, for example what versions are present and whether a known bad package or published vulnerability is in the tree. It does not tell you whether an install script, lifecycle hook, or bundled payload actually executed. When the risk is postinstall behaviour, the practical control point is the runtime path where the package runs and can touch the host, filesystem, network, or secrets.
That distinction matters because npm risk is often not just “is this package vulnerable?” but “what did this package do during installation or first execution?” Runtime controls can observe process creation, child processes, outbound connections, dropped files, and secret access in ways a static scan cannot. That makes them better aligned to the attack path that malicious packages actually use.
Runtime protection also handles cases where the package itself looks benign until execution time. A package can pass signature, version, and CVE checks and still launch a shell, spawn a miner, modify build artefacts, or exfiltrate tokens during install. In those cases, runtime telemetry is the evidence source that separates an abstract supply-chain concern from an actual compromise path.
What dependency scanning still does well in an npm programme
Dependency scanning is still useful, but its value is different. It helps teams build an inventory, spot exposed versions, identify typosquatting patterns in the tree, and track packages that should be reviewed, replaced, or pinned more tightly. It is especially useful early in the pipeline because it can reduce obvious risk before code is merged or deployed.
The limit is that scanning is retrospective and package-centric, while install-time abuse is behavioural and environment-centric. A package can be safe in one context and dangerous in another if it is given scripts, secrets, or access to CI resources. That is why scanning should be treated as a baseline hygiene control, not the final answer for npm package safety.
For npm specifically, the attack surface expands when packages run as part of build or install flows. If the environment allows postinstall scripts, preinstall hooks, or unrestricted tooling during CI, the more important question becomes whether those executions are monitored, constrained, and able to reach sensitive material. The right control mix is therefore inventory plus behaviour visibility, not inventory alone.
How to decide where to spend effort first
When a package can execute during install, prioritise runtime controls first, then use dependency scanning to narrow the watch list. Runtime controls give you the highest-fidelity signal for malicious behaviour, while scanning helps you decide where to apply closer scrutiny and how to manage known exposure over time. If you can only improve one layer for near-term risk reduction, make it the layer that sees execution.
That priority changes if your main concern is software composition governance rather than active abuse. In that case, scanning remains important for completeness, version drift, and policy enforcement. But once the question is whether an npm package may already be doing something harmful on developer machines, runners, or build hosts, runtime evidence should drive the response.
A useful operational test is simple: if the package can reach secrets, spawn child processes, or open the network during installation, treat runtime controls as mandatory. If the package is only being assessed for inclusion, licence, or patch posture, scanning can stay in the foreground. The control should match the failure mode, not the convenience of the tool.
Risk and Threat Considerations
npm package abuse becomes materially more dangerous when install-time execution reaches secrets, developer credentials, or build infrastructure. Attackers do not need a fully weaponised binary if they can ride a lifecycle hook, blend into normal package activity, and collect tokens or exfiltrate data before defenders notice.
Failure mechanism: A malicious package or compromised dependency executes during install, then uses that execution context to spawn processes, read environment variables, contact an external host, or harvest secrets from the development or CI environment.
Impact: The result can be credential theft, repository compromise, lateral movement into build systems, or poisoned artefacts that propagate downstream before any static scan flags the package as bad.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | npm runtime abuse often steals secrets during install-time execution |
| NHI-04 — Insecure Authentication | malicious npm activity commonly abuses tokens and developer credentials | |
| Recommendation — Detect and block secret exposure paths in package execution flows. Harden token handling and rotate credentials after suspicious package execution. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | runtime controls are needed to catch malicious behaviour from packages |
| CIS-8 — Audit Log Management | behavioural detection depends on logs for execution, egress and secret access | |
| Recommendation — Instrument endpoints and CI hosts to detect and stop malicious process activity. Log package execution events, process trees, and outbound connections for review. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | npm package execution risk maps to malware and malicious lifecycle behaviour |
| AU-12 — Audit Record Generation | runtime response requires records of what executed and accessed secrets | |
| Recommendation — Inspect and block malicious code at execution points, not only at ingestion. Generate audit records for install-time execution and sensitive access events. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | runtime controls need visibility into package-triggered execution and abuse |
| Recommendation — Record package-triggered security events so suspicious behaviour can be investigated. | ||
| MITRE ATT&CK | T1204 — User Execution | malicious npm packages rely on install-time execution by the user or build system |
| T1059 — Command and Scripting Interpreter | postinstall abuse often launches shells or scripts to continue the attack | |
| Recommendation — Hunt for execution paths that run untrusted code during installs or builds. Monitor for script and shell invocation from package installation contexts. | ||
Practitioner Guidance
What to prioritise: Put runtime visibility around package execution first on any path that still permits npm lifecycle scripts, especially in CI and developer workstations that hold tokens or cloud credentials. Pair that with rules that limit what install-time code is allowed to touch.
What to verify: Confirm whether your controls can show child processes, network egress, file writes, and secret access during install, not just whether a dependency is on an approved list. If you cannot observe those actions, you are assuming the package behaved well.
Common mistake: Treating a clean scan as proof of safety. A package can be new, unpublished in advisory databases, or simply malicious by design and still be caught only when it runs.
Practitioner takeaway: Use dependency scanning for inventory and known exposure, but use runtime controls to decide whether npm behaviour is safe in practice, because execution is where the real risk materialises.
Related resources from NHI Mgmt Group
- Should teams prioritise runtime controls over more vulnerability scanning?
- When should organisations prioritize runtime controls over more scanning?
- Should teams prioritize just-in-time secret injection over more dependency scanning?
- How do security teams know if npm dependency controls are actually working?