Install-Time Execution

How install-time execution works

Install-time execution happens when package code runs during dependency installation, not when the application starts. That distinction matters because the installer phase is often treated as a routine build step, yet it can execute arbitrary scripts with the same filesystem, network, and environment access available to the developer or CI job that is performing the install.

In practice, the risk is not the package manager itself but the trust placed in dependency metadata and lifecycle hooks. Any mechanism that runs automatically during install can become an execution path for malicious code, whether the package is public, internal, transitive, or pulled in through a lockfile update.

Why install-time execution is a security boundary

Install-time execution is dangerous because it often occurs before hardening controls are fully in place. Build agents may expose cloud tokens, signing keys, registry credentials, source tree access, and other secrets that an attacker can harvest if the install step is abused.

This is why install-time execution is best understood as a privilege boundary, not just a convenience feature. If an organisation assumes dependency installation is inert, it may grant package scripts more authority than intended and create a path from dependency fetch to environment compromise.

For a practical control perspective, NIST SP 800-190 Container Security is a useful companion when install-time behaviour feeds into image builds or containerised pipelines, because it frames how software enters trusted runtime environments. NIST SP 800-190 Container Security

Common attack patterns and failure modes

The most common failure mode is automatic script execution from a dependency that developers expected to be passive. That can include preinstall, install, or postinstall hooks, as well as build steps invoked by package managers during dependency resolution.

Attackers value this stage because it combines software supply-chain trust with execution at a moment when defenders may not yet have telemetry, least-privilege separation, or sandboxing. The result can be credential theft, build tampering, malicious payload staging, or hidden persistence inside the delivery pipeline.

Install-time abuse is especially effective when organisations rely on broad package-manager defaults and assume lockfiles alone are enough. A locked dependency graph does not help if the resolved package is itself hostile or if scripts are allowed to run without scrutiny.

How organisations reduce exposure and recover safely

Defence starts with limiting what install steps are allowed to do. Strong package-script controls, frozen or reviewed lockfiles, registry scoping, dependency age checks, and explicit approval for build scripts all reduce the chance that an install event becomes an execution event.

When a suspicious install is discovered, teams should treat the endpoint, CI job, or build image as potentially exposed. That means reviewing install logs, diffing artefacts, checking for unexpected outbound connections, and rotating any secrets that were present in the environment during installation.

For organisations managing package-install governance, the npm Install-Time Security Guide covers the specific controls that matter most: script allowlisting, frozen lockfiles, release-age cooldowns, and registry settings that reduce malicious install-time code execution.

Install-time execution also sits within broader supply-chain and dependency governance. SLSA is relevant where the goal is to strengthen provenance and reduce the chance that unreviewed artefacts reach the build in the first place.

Detection and practitioner response

Detecting install-time abuse usually means looking for behaviour that does not belong in a normal dependency install, such as unexpected network calls, child process creation, archive manipulation, or secret access during package resolution. Those signals are more valuable than the package name alone, because the same dependency may behave differently across environments.

Practitioners should also assume post-install compromise may leave little visible change in the application code. If a malicious script ran during dependency installation, the review needs to extend beyond the package to the build host, secret stores, generated artefacts, and any published images or bundles that were produced afterward.

MITRE ATT&CK Enterprise Matrix is useful here because it helps map install-time behaviour to downstream execution, credential access, and persistence patterns that security operations teams can hunt for. MITRE ATT&CK Enterprise Matrix

Related resources from NHI Mgmt Group

• Execution (MITRE ATT&CK Tactic)
• What do security teams get wrong about hardening only install-time package execution?
• How should security teams handle package install-time execution in CI environments?
• Why do package compromises that move from install hooks to import-time execution create a bigger trust problem?