Lifecycle-script blocking is no longer enough because the malicious code runs when a plugin is imported, not only when a package is installed. That means dependency resolution, config loading, and build startup can all become execution points. Teams need to treat imported build plugins as code that can reach the network and the local secret store.
What actually breaks in the build when plugin imports can execute code?
The security assumption that “nothing runs until install-time scripts are blocked” stops being true. If a build system imports a trusted plugin or helper during dependency resolution, config parsing, or startup, that import can execute attacker-controlled code before any later safeguards or review steps happen. In practice, the build itself becomes an execution surface, not just the package manager.
That changes the failure model in a few ways. First, the point of execution moves earlier than most teams expect, so controls aimed only at postinstall scripts miss the malicious path. Second, the code runs inside the build’s own trust boundary, which often includes network reachability, repo access, and secret-bearing environment variables. Third, the blast radius is no longer limited to a bad package becoming installed; it can extend to whatever the build can read, fetch, or publish once import-time code runs.
For build and dependency hygiene, this is the same class of problem seen in Shai Hulud npm malware campaign, Nx s1ngularity attack 2025, and coa and rc npm hijacks 2021: the harmful action is not just package installation, but code execution inside the developer or CI runtime.
Why import-time execution is a supply-chain problem, not just a package-manager problem
Import-time execution breaks the usual line between “safe metadata handling” and “unsafe code execution.” Many build tools load plugins, presets, transforms, or config helpers as soon as they need to inspect the project. If those imports are compromised, the malware can run before the build has even reached the test or bundle phase.
That means dependency resolution, config loading, and build startup all become security-relevant execution points. A team that only blocks lifecycle scripts still leaves room for a malicious dependency to run through a different hook. The real question becomes whether the build process ever imports untrusted JavaScript with ambient access to the filesystem, network, or secrets.
There is also a trust problem in how teams rank dependencies. A plugin added for convenience can feel less risky than an application dependency, but build plugins often sit closer to credentials, CI tokens, artifact publishing paths, and source code than runtime app code does. Once imported, they can inspect environment variables, modify generated artifacts, or stage follow-on downloads.
That is why supply-chain integrity controls such as SLSA matter here: they help teams reason about provenance, build inputs, and trust boundaries instead of assuming imported code is harmless because it arrived through a normal dependency graph.
How to harden builds against import-triggered npm malware
The practical defense is to treat imported build-time code as production-capable code. If it can run during startup, it needs the same scrutiny you would apply to any executable component with access to secrets or outbound connectivity.
- Minimise which plugins are auto-loaded during config discovery.
- Pin and review build dependencies with the same care used for application code.
- Run builds with the smallest possible secret set and network reach.
- Separate dependency resolution from secret-bearing build steps where feasible.
- Prefer reproducible, provenance-checked artifacts over “whatever the plugin executes on import.”
Build teams should also validate that their controls match the actual execution path. If a plugin can reach the secret store or call out to the network during import, then package-install blocking alone is not an adequate boundary. The control objective is not just to stop installation-time abuse, but to prevent unreviewed code from executing in any phase that can touch sensitive material.
For operational safeguards, CIS Controls v8 is useful because it aligns inventory, secure configuration, and malware defense with the need to manage what is allowed to execute in build environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, OWASP ASVS, SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Build runners and CI accounts need tightly managed execution and access paths. |
| Recommendation — Restrict build-runner privileges and remove unnecessary accounts and access paths. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Import-time execution in build tooling is an architecture and code-execution concern. |
| Recommendation — Review build plugins as executable code paths and constrain unsafe dynamic loading. | ||
| SLSA | Supply-chain Levels for Software Artifacts | The issue is trusted build input integrity and provenance of code that executes during builds. |
| Recommendation — Require provenance checks for build inputs and trusted plugins before execution. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Malicious code can execute through imported build plugins and needs executable-code controls. |
| CM-5 — Access Restrictions for Change | Imported build code can change artifacts and reach protected resources during the build. | |
| Recommendation — Scan and control executable build inputs before they can run in CI or local builds. Limit which build components may modify pipelines, artifacts, and sensitive resources. | ||
Practitioner Guidance
What to verify: Confirm which build tools auto-import plugins, presets, and config helpers during dependency resolution or startup. Those import paths are the ones most likely to bypass install-script blocking and should be reviewed as execution surfaces, not as passive metadata handling.
What to prioritise: Reduce the secret and network exposure of build runner before tightening package policy. If the build cannot reach secrets or the internet, import-time malware has far less room to exfiltrate or pivot even if it executes.
Common mistake: Treating “no postinstall scripts” as equivalent to “no executable supply-chain risk.” That shortcut misses plugin imports, which can fire earlier and with better access than the package manager scripts teams usually monitor.
Practitioner takeaway: The important boundary is not package installation, it is any trusted import that can run code with build-time privileges. Once that boundary is crossed, the build environment itself must be governed like an execution tier.