Why do install scripts make package supply-chain attacks more dangerous?

Why This Matters for Security Teams

Install scripts are dangerous because they turn package installation into code execution, often before teams have any chance to inspect behavior or enforce runtime policy. That matters most in build pipelines, containers, and serverless deployments, where package install steps can read secrets, reach metadata services, or alter downstream artifacts. NHI Management Group’s research on the 52 NHI Breaches Analysis shows how quickly identity misuse and secret exposure can cascade once an attacker gains execution inside a trusted workflow.

The core mistake is assuming package trust is the same as code trust. It is not. A package can look legitimate at publish time and still execute arbitrary logic during install, especially in ecosystems that support preinstall, postinstall, or lifecycle hooks. The result is that supply-chain compromise no longer depends on a developer importing malicious code later. It can happen as soon as the dependency manager resolves the package. For threat context, the CISA cyber threat advisories routinely emphasize that trusted update and build paths are prime attacker targets.

In practice, many security teams discover this only after a build credential, token, or release artifact has already been exposed, rather than through intentional package vetting.

How It Works in Practice

Install scripts become a supply-chain multiplier because they run in the same context as the developer workstation, CI runner, or image build process. That context often includes environment variables, cached credentials, cloud tokens, artifact registry access, and network egress. A malicious script can exfiltrate secrets, modify dependency trees, drop persistence into build outputs, or plant a second-stage payload that activates later. This is why package installation should be treated as execution, not passive retrieval.

Current guidance suggests layering controls instead of relying on any single safeguard. At minimum, teams should separate dependency fetching from package execution, disable lifecycle scripts where feasible, and allowlist only the packages that genuinely require them. Stronger builds also use short-lived credentials, isolated runners, and network restrictions so a script cannot freely phone home or reach instance metadata. The OWASP Non-Human Identity Top 10 is relevant here because the blast radius is often created by over-privileged machine identities, not just by the malicious package itself.

For real-world validation, NHIMG’s Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign both show how automation paths can be abused to harvest secrets at scale. Mapping these behaviours to MITRE ATT&CK Enterprise Matrix helps teams see the install step as an execution and credential-theft opportunity, not just a software hygiene issue. These controls tend to break down when legacy build jobs require broad network access and long-lived registry tokens because the install phase becomes indistinguishable from normal trusted automation.

Common Variations and Edge Cases

Tighter package controls often increase build friction and break older workflows, so organisations have to balance delivery speed against execution risk. That tradeoff is real: some ecosystems depend on install-time compilation, native bindings, or postinstall bootstrapping, and a blanket ban can disrupt legitimate releases.

Best practice is evolving rather than settled. There is no universal standard for when lifecycle scripts should be fully blocked versus selectively permitted, but the safer pattern is to classify packages by necessity and isolate anything that needs execution. High-risk cases include private package mirrors, transitive dependencies with opaque maintainer history, and CI systems that reuse the same identity across many jobs. In those environments, a single compromised install can reach far beyond the original package boundary.

Teams should also distinguish package trust from author trust. Even a known maintainer account can be hijacked, and even a benign package can become dangerous if its install script assumes broad filesystem or cloud access. For broader NHI governance context, the Ultimate Guide to NHIs — Why NHI Security Matters Now is useful because install scripts often exploit the weakest machine identity in the chain, not the primary application identity. External threat guidance such as the Anthropic AI-orchestrated cyber espionage report also reinforces a broader point: automated systems amplify attacker speed, so static trust assumptions age poorly.

Related resources from NHI Mgmt Group

• Why do cloud and NHI secrets make supply chain attacks more dangerous?
• Why do Kubernetes environments make supply chain attacks more dangerous?
• Why are package imports a supply-chain risk even when install scripts are blocked?
• Why do hidden dependencies make npm supply chain attacks so dangerous?