What do security teams get wrong about hardening only install-time package execution?

Why This Matters for Security Teams

Hardening only install-time package execution misses the way modern dependency abuse actually lands in development environments. Security teams often focus on the moment a package is installed, but malicious code can also run during module import, editor automation, build hooks, test harnesses, and task runners. That is why package trust decisions need to be tied to the full software delivery path, not just one event. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces control coverage across acquisition, execution, and monitoring rather than a single gate. The operational problem is visible in real-world package incidents, including the LiteLLM PyPI package breach, where the risk was not just installation but the downstream execution path that developers assumed was routine. NHI Management Group research also shows how easily execution-related trust assumptions fail when 79% of organisations have experienced secrets leaks. In practice, many security teams discover the exposure only after a dependency has already executed in a build or IDE workflow, rather than through intentional review of every execution surface.

When teams treat install-time scanning as the whole answer, they miss the places attackers prefer because they look normal to developers and are less likely to trigger alerts. That creates a false sense of coverage while leaving import-time code, pre-commit hooks, and CI task runners available for abuse.

How It Works in Practice

Effective control starts by mapping where package code can execute, then applying policy and telemetry at each point. That means examining package manager behavior, runtime import paths, editor integrations, CI jobs, and local automation scripts as separate control surfaces, not one combined risk. Security teams should treat package execution as a lifecycle issue: acquisition, unpacking, installation, import, build, test, and release. The Ultimate Guide to NHIs is relevant here because dependency accounts, tokens, and automation identities often enable these workflows, and compromise of one pathway can cascade across many others. Current guidance suggests combining allowlisting, provenance checks, signed artifacts, and runtime monitoring rather than relying on one prevention point alone. Practical controls usually include:

• Blocking or reviewing package scripts that run during install, build, or publish steps.
• Restricting import-side effects in packages that execute code on load.
• Separating developer workstation privileges from CI/CD execution rights.
• Monitoring task runners, editor extensions, and pre-commit hooks as executable trust boundaries.
• Using policy to decide when a package may execute, not only when it may be installed.

For implementation guidance, NIST SP 800-53 Rev 5 Security and Privacy Controls supports broader monitoring and configuration management, while the package-breach pattern seen in the LiteLLM PyPI package breach shows why execution paths outside installation deserve equal scrutiny. These controls tend to break down in fast-moving CI/CD environments where package execution is delegated to many ephemeral runners and developers can add new hooks faster than policy can be updated.

Security teams should also distinguish between blocking execution and observing execution. In many environments, the goal is not to prohibit all dynamic behavior, but to make every execution path attributable, reviewable, and revocable when trust changes.

Common Variations and Edge Cases

Tighter execution control often increases developer friction, requiring organisations to balance supply chain safety against build speed and autonomy. That tradeoff is especially visible in monorepos, polyglot stacks, and teams that rely on package-generated code or legitimate post-install actions. Best practice is evolving, and there is no universal standard for exactly which package hooks must always be blocked versus reviewed, so policy should reflect the organisation’s risk tolerance and release model. Edge cases matter. Some packages legitimately use install scripts to compile native extensions, while others perform runtime code generation during import. IDE automation and task runners can also behave differently from CI, which means a control that works in central pipelines may leave local developer workflows exposed. NHI Management Group research on the Ultimate Guide to NHIs shows why this matters operationally: excessive privilege and poor visibility are common across machine identities, so a small execution exception can become a high-impact path if it reuses the same secrets or tokens. The right answer is usually tiered trust, with more scrutiny for packages that execute code, fetch remote content, or touch credentials. In practice, controls fail when organisations assume a single package policy can cover install, import, build, and editor-driven execution equally well.

Related resources from NHI Mgmt Group

• What do security teams get wrong about package install scripts?
• What do security teams get wrong about AI coding-agent persistence?
• What do security teams get wrong about private repositories and internal pipelines?
• What do security teams get wrong about point-in-time file monitoring?