They let malicious code execute before developers inspect the package and survive after the package is removed. A postinstall hook can materialize a payload outside node_modules, which bypasses normal uninstall logic and makes eradication harder. That design also reduces visibility for scanners that rely on package contents alone, especially when the payload is encoded.
Why This Matters for Security Teams
Install-time execution changes a package from passive code into an active delivery mechanism. In npm ecosystems, that matters because dependency trust is often granted before the code is reviewed, while automated build and CI processes may run package lifecycle scripts by default. The risk is not limited to a single malicious module. It includes transitive packages, dependency confusion, typosquatting, and any hidden payload that can write beyond the package directory. That is why supply chain controls need to account for execution, not just source integrity.
Security teams often focus on whether a package is signed, pinned, or sourced from an approved registry. Those checks help, but they do not stop a harmful Non-Human Identity from using install-time privileges to plant files, fetch secrets, or alter later execution paths. The practical problem is persistence: once code lands in a hidden runtime directory outside the expected package tree, removal becomes a filesystem and trust issue, not just a package-manager task. In practice, many security teams encounter this only after a build agent, developer workstation, or release pipeline has already executed the payload rather than through intentional pre-execution inspection.
How It Works in Practice
npm packages can define lifecycle hooks such as preinstall, install, and postinstall. If these scripts are enabled, they execute during dependency installation, often with the permissions of the user or CI runner. That gives an attacker a chance to unpack code, download a second-stage payload, or write into locations that are not obviously tied to the package record. Hidden runtime directories are especially problematic when they are created under user profile paths, application caches, or other writable locations that survive an uninstall.
The operational issue is that package managers track declared files, not everything a script may create at runtime. A package can appear benign in the lockfile and still leave behind active code after removal. This is also where scanner limitations show up: tools that inspect only archive contents or dependency metadata can miss encoded payloads, delayed execution, or files written after installation. The NIST Cybersecurity Framework 2.0 framing is useful here because it pushes teams to address identify, protect, detect, respond, and recover as one control loop rather than as separate checkboxes.
- Restrict lifecycle scripts in CI unless a package has been explicitly reviewed.
- Record and diff filesystem changes during install, not just package manifests.
- Treat hidden writable directories as part of the software bill of materials review scope.
- Monitor for outbound network calls during package installation and first run.
- Rebuild clean environments rather than trusting uninstall to remove all artifacts.
These controls tend to break down in developer endpoints and ephemeral build agents because local caches, shared workspaces, and permissive script execution make it difficult to distinguish legitimate setup from malicious persistence.
Common Variations and Edge Cases
Tighter control over install-time behaviour often increases build friction, so organisations have to balance developer convenience against supply chain assurance. That tradeoff becomes sharper when teams rely on packages that legitimately use postinstall steps for native compilation, browser binary downloads, or environment-specific setup. Best practice is evolving here, and there is no universal standard for which scripts should always be blocked.
Edge cases matter. Some npm packages write runtime files into application-specific cache locations, which can be normal on one platform and suspicious on another. Others only activate when certain environment variables, CI markers, or architecture checks are present, so a package may look harmless in a lab but behave differently in production. Hidden directories can also be used for stealth after initial compromise, where the install hook is only the first stage and later execution is triggered by application startup, cron-like scheduling, or user interaction.
For higher-risk environments, the practical answer is policy plus observation: approve only known-good packages, execute installs in isolated build contexts, and validate post-install filesystem state before promotion. When npm is part of a broader identity or automation stack, those hidden directories can also store secrets, tokens, or access artifacts that behave like NHI credentials, which makes removal and rotation equally important.
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 ATLAS address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | Install-time payloads undermine data and artifact integrity during software delivery. |
| OWASP Non-Human Identity Top 10 | NHI-07 | npm scripts can abuse non-human identities and tokens present in build or runtime contexts. |
| MITRE ATLAS | AML.TA0001 | Supply chain tampering can be used to seed malicious behavior before model or app execution. |
| NIST AI RMF | GOVERN | If npm packages feed AI systems, install-time compromise can corrupt upstream model tooling and data. |
Establish accountable review and provenance checks for every dependency that can alter AI pipelines.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
