Dependency execution is the running of code during software installation or build time, often through package scripts or embedded loaders. It matters because malicious behavior can start before an application ever launches, making build pipelines, developer systems, and package managers part of the attack surface.
Expanded Definition
Dependency execution refers to code that runs as a side effect of installing, resolving, or building software dependencies, including package lifecycle scripts, preinstall hooks, postinstall routines, and embedded loaders. In modern supply chain security, this is distinct from the dependency itself: the risk comes from the execution path created by package managers, build tools, and developer workflows.
The concept is closely related to software supply chain trust, because the executing code may come from a direct dependency, a transitive dependency, or a build-time helper that is not obvious to the developer. Guidance varies across vendors on whether to treat all lifecycle execution as prohibited by default, but the security principle is consistent: execution during install expands the trusted computing base. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames software integrity and supply chain risk as governance issues, not just developer convenience.
The most common misapplication is assuming a package is safe because its source code has been reviewed, when the actual risk is hidden in install scripts or build hooks that run automatically during dependency resolution.
Examples and Use Cases
Implementing controls for dependency execution rigorously often introduces friction in developer workflows, requiring organisations to weigh build speed and convenience against reduced supply chain risk.
- A JavaScript package uses a postinstall script to fetch and run additional code, which creates a path for unexpected execution during CI or on a developer laptop.
- A Python dependency triggers code through setup-time behavior, meaning a seemingly harmless install can alter files, exfiltrate tokens, or modify build outputs.
- A container build pulls in a helper package that runs during image construction, so the build environment becomes part of the attack surface rather than a passive compiler.
- A monorepo uses a package manager that evaluates workspace scripts automatically, making transitive dependency behavior visible only after the pipeline has already executed it.
- Security teams can compare dependency behavior against OWASP guidance on unsafe code execution patterns to decide which installs should be blocked or sandboxed.
Why It Matters for Security Teams
Dependency execution matters because it moves the control point for compromise earlier in the software lifecycle, before application runtime protections, EDR telemetry, or user-facing monitoring may be active. Once install-time code is allowed to run, the build server, developer workstation, package registry, and CI agent all become potential execution environments. That is especially relevant for teams managing NHI, because automated build identities, pipeline tokens, and secret stores can be exposed during dependency resolution if scripts are allowed to access the network or filesystem.
For governance, the practical question is not only whether a dependency is approved, but whether its execution behavior is known, bounded, and auditable. This is where supply chain policy, least privilege, and artifact integrity intersect. Operational controls such as Sigstore and SLSA help teams reason about provenance and build trust, but they do not remove the need to restrict install-time execution.
Organisations typically encounter the impact only after a build or release pipeline has been used to stage malware, at which point dependency execution becomes operationally unavoidable to contain and remediate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Addresses configuration and change control for software and dependencies. |
| NIST SP 800-53 Rev 5 | SI-7 | Supports software integrity checks and protection against malicious code execution. |
| ISO/IEC 27001:2022 | A.8.32 | Covers change management for software and system components affecting installs. |
| NIST AI RMF | AI systems rely on software supply chains that can be altered through executed dependencies. | |
| OWASP Non-Human Identity Top 10 | Build systems and automation identities can be abused when dependency scripts run with secrets. |
Restrict install-time execution through controlled build policies and change-approved dependency handling.
