What breaks when install-time scripts are allowed in dependency pipelines?

Why This Matters for Security Teams

Install-time scripts convert dependency acquisition into arbitrary code execution during CI, build, or package install phases. That means the security boundary is no longer the application runtime; it is the pipeline itself. Once a package can run code at install time, it can inspect environment variables, read cached credentials, and reach signing or publishing steps before defenders see a problem. This is why supply chain abuse so often becomes a secrets exposure event, not just a malicious code event.

The risk is amplified by the reality of secret sprawl. NHI Management Group notes that 96% of organisations store secrets outside dedicated secrets managers in vulnerable locations, and 79% have experienced secrets leaks. The pattern shows up in incidents like the Reviewdog GitHub Action supply chain attack, where trust in a dependency or action became trust in execution. The NIST Cybersecurity Framework 2.0 frames this as a governance and protection failure: if third-party code can execute inside the build path, the environment must be treated as hostile by default.

In practice, many security teams discover install-time script abuse only after a CI token, package signing key, or cloud credential has already been used elsewhere.

How It Works in Practice

When install-time scripts are allowed, package managers may execute lifecycle hooks such as preinstall, install, or postinstall automatically. That behaviour is convenient for legitimate dependencies, but it creates a hidden execution channel for attackers. A malicious package can perform recon, exfiltrate secrets, tamper with artifacts, or chain into other tools if the build identity has broad permissions. The problem is not limited to npm or PyPI. Any dependency pipeline that runs code before explicit approval inherits the same risk class.

Current guidance suggests treating install-time execution as a privilege, not a default. In mature pipelines, teams reduce blast radius by disabling script execution where possible, using allowlists for trusted packages, and separating dependency resolution from privileged build steps. Builds should run with short-lived credentials and minimal scope, with secrets injected only when strictly required. This is especially important because install-time code often runs before policy checks, dependency scanning, or artifact signing gates can intervene. The CI/CD pipeline exploitation case study shows how a pipeline compromise can cascade into broader environment access, while the Guide to the Secret Sprawl Challenge explains why scattered secrets make that cascade much worse.

• Disable package install scripts by default unless a dependency is explicitly trusted and reviewed.
• Use ephemeral build identities and JIT credentials so a compromised install phase cannot reuse long-lived access.
• Keep signing keys, publish tokens, and cloud credentials out of the install environment whenever possible.
• Run dependency fetching in a low-privilege stage, then promote only verified artifacts into privileged stages.

These controls tend to break down when legacy build tooling requires scripts for core functionality because teams then reintroduce broad secrets to preserve developer velocity.

Common Variations and Edge Cases

Tighter script blocking often increases build friction, requiring organisations to balance dependency compatibility against execution control. That tradeoff is real: some packages rely on install scripts for native compilation, platform detection, or post-install setup. Best practice is evolving, and there is no universal standard for how much script execution should be allowed in every ecosystem. The right answer depends on whether the dependency is internal, pinned, reviewed, and reproducible.

High-risk environments usually adopt exceptions instead of blanket trust. For example, a vetted internal package may be permitted to run scripts in a constrained build container, while public packages are installed with scripts disabled. Teams should also remember that package managers differ in how they handle lifecycle hooks, lockfiles, and transitive dependency execution. A control that works in one ecosystem may not fully protect another. The NHI Management Group research on Shai Hulud npm malware campaign shows how quickly a trusted package path can become a secret-harvesting path, especially when credentials are present in the build context.

For broader governance, the safest approach is to assume that any install-time script can behave like attacker-controlled code and to apply the same scrutiny used for production workloads.

Related resources from NHI Mgmt Group

• What breaks when install-time scripts are left enabled by default?
• What breaks when automatic install scripts are allowed in AI-assisted builds?
• What breaks when dependency install scripts are disabled by default?
• How should teams control dependency install scripts in modern pipelines?