What breaks when a dependency can run code during build time?

Why This Matters for Security Teams

When a dependency can execute during build time, the risk is no longer limited to vulnerable application code. The build system itself becomes part of the trust boundary, and that matters because CI runners often hold source repositories, signing keys, cloud tokens, and deployment credentials. Security teams that treat package installation as a passive event tend to miss the moment when a compromised dependency can exfiltrate secrets or tamper with outputs.

This is especially important in modern software supply chains, where dependency trees are deep, transitive packages are common, and build tooling may automatically resolve scripts without strong review. Guidance from the NIST Cybersecurity Framework 2.0 is useful here because it reinforces inventory, protection, detection, and recovery across the full lifecycle, not just in production. The practical question is not whether a package is popular, but whether its build hooks can do anything a normal developer process can do.

Teams often underestimate how quickly a build-time dependency issue becomes an organisation-wide incident. Once a malicious script runs in CI, it can pivot into artifact poisoning, credential theft, or persistence in a release pipeline. In practice, many security teams encounter this only after a build log, secret leak, or unexpected outbound connection has already revealed the compromise.

How It Works in Practice

Build-time execution usually appears through package manager hooks, install scripts, custom build steps, or transitive tooling that runs before compilation completes. In a healthy pipeline, those steps are tightly constrained and observable. In a weak pipeline, they inherit the same privileges as the developer or runner process, which means they can read files, inspect environment variables, call local tools, and reach external services unless egress controls block them.

The operational impact depends on where the build happens. On developer laptops, build scripts may access SSH agents, browser sessions, cached cloud credentials, or local secrets. In CI, the same code may reach repository tokens, artifact registries, signing material, and infrastructure APIs. Current guidance suggests reducing that trust by applying least privilege, isolating build runners, and reviewing dependency behaviour as part of secure software supply chain controls. CISA and SLSA-aligned practices are often used to harden this layer, and the OWASP CI/CD Security Risks material helps teams think about pipeline abuse, while SLSA is useful for provenance and build integrity expectations.

• Disable or tightly govern install and post-install scripts where the ecosystem allows it.
• Run builds in ephemeral, segmented environments with no standing access to production secrets.
• Separate dependency resolution from execution, then inspect what is actually run.
• Restrict outbound network access so build-time code cannot call arbitrary infrastructure.
• Require artifact signing and provenance checks before release promotion.

The best control set also includes log review and telemetry for unexpected process creation, file access, and outbound connections during dependency installation. Where packages need scripts for legitimate reasons, allowlisting and review become essential. These controls tend to break down when legacy build tools require opaque hooks that cannot be disabled because the pipeline depends on them for normal compilation.

Common Variations and Edge Cases

Tighter build controls often increase friction for developers and release engineers, so organisations must balance supply chain assurance against pipeline speed and package compatibility. That tradeoff is real, especially in ecosystems where install scripts are common or where build tools are tightly coupled to language-specific package managers.

One variation is the difference between a first-party dependency and a transitive one. The latter is often more dangerous because teams may not even know the package exists, let alone review its build behaviour. Another edge case is reproducible builds: they improve confidence, but they do not eliminate risk if malicious code executes before the final artifact is assembled. There is no universal standard for what every ecosystem should block at build time, so best practice is evolving toward stronger provenance, clearer policy enforcement, and dependency risk scoring.

For high-trust environments, the right response may be to treat build systems as privileged infrastructure and apply stronger segmentation, approval workflows, and dedicated secrets handling. Where software is delivered across multiple teams, security leaders should also align with CISA software supply chain guidance to standardise controls across repositories and pipelines. The key is not to assume that a dependency is safe just because it was fetched from a registry; if it can run code during build, it has already crossed into execution authority.

Related resources from NHI Mgmt Group

• How should security teams respond when a build may have run malicious dependency code?
• How should security teams handle npm packages that run code during install?
• What breaks when a compromised Python package can run code at interpreter startup?
• What breaks when CI/CD workflows can run untrusted code with privileged tokens?