Why are package imports a supply-chain risk even when install scripts are blocked?

Because malicious code can execute at require() time. If a dependency includes a top-level loader, normal application startup, code generation, or schema validation can trigger malware without any postinstall hook. Blocking install scripts reduces one path, but it does not stop import-triggered execution in trusted runtime contexts.

Why This Matters for Security Teams

Blocking install scripts reduces one common package abuse path, but it does not eliminate code execution during import. In JavaScript, Python, and similar ecosystems, dependencies can run top-level code as soon as the module is loaded, which means malware can execute during startup, validation, code generation, or test runs. That makes package imports a supply-chain risk even in “scriptless” installs.

This is especially dangerous in build pipelines and developer workstations where package managers are trusted to resolve, cache, and load code automatically. A malicious package may not need a postinstall hook if it can trigger at require time, during transitive dependency loading, or through a tool that introspects imported modules. Current guidance suggests treating package resolution and import as execution events, not passive file reads. For broader supply-chain context, the OWASP Non-Human Identity Top 10 and NHIMG research on the Mastra npm Supply Chain Attack both show how quickly trusted dependencies can become execution vectors.

In practice, many security teams discover the problem only after a build agent, CI job, or developer laptop has already loaded the package and exposed secrets or tokens.

How It Works in Practice

Import-time execution happens because package ecosystems often evaluate module code as part of normal runtime behavior. A package can place malicious logic at the top level of the file, so the moment an application calls require(), imports a helper, or a tool scans the module graph, the payload runs. That is why blocking install scripts helps, but only partially: it prevents one execution mechanism, not the broader class of runtime-triggered execution.

Security teams should assume that any trusted runtime context can become an execution context. Practical controls include pinning and verifying dependencies, reviewing transitive packages, minimizing automatic imports in build tooling, and isolating package loading in hardened environments. For higher-risk pipelines, combine dependency allowlisting with behavioral checks, secret scanning, and egress controls. The LiteLLM PyPI package breach illustrates how package trust can be abused to reach sensitive material, while the NIST Cybersecurity Framework 2.0 supports the operational discipline needed for supply-chain governance.

• Review dependency trees before import, not only before installation.
• Run builds and tests in isolated environments with minimal secrets present.
• Prefer signed, pinned, and reproducible artifacts where possible.
• Alert on unexpected network calls or filesystem access during module load.

These controls tend to break down in fast-moving monorepos and AI-assisted build pipelines because imports are often triggered automatically by code generation, linting, or test discovery.

Common Variations and Edge Cases

Tighter package controls often increase developer friction and maintenance overhead, so organisations must balance supply-chain assurance against release velocity. There is no universal standard for this yet, especially across Python, JavaScript, and polyglot build systems where import semantics differ.

One edge case is transitive dependency loading, where the direct package appears benign but a nested library executes code at import time. Another is tooling that imports packages only to inspect metadata, render schemas, or generate clients. In those cases, the risk is not a traditional “install” event at all. The The 52 NHI breaches Report reinforces how often identity and trust failures occur through indirect paths, not obvious entry points.

For teams operating under the NIST SP 800-53 Rev 5 Security and Privacy Controls, the practical answer is to classify imports as code execution events and require the same scrutiny used for executable binaries. That is the right mental model when package ecosystems blur the line between “library” and “runtime payload.”

Related resources from NHI Mgmt Group

• Why do install scripts create such a large supply chain risk?
• Why do package publishing workflows create supply chain risk even when code reviews exist?
• Why do dormant packages create supply-chain risk in developer environments?
• How do attackers turn a supply-chain incident into wider NHI compromise?