Code that runs during package installation or build preparation before the application is imported or started. This is a high-risk phase because it can access the host environment, read files, and contact external services. Security teams must treat install-time logic as active execution, not inert metadata.
Expanded Definition
Setup-time execution refers to code paths that run before an application is imported or started, typically during package installation, build preparation, or environment setup. NHI Management Group treats this as active execution because the code can inspect the host, access environment variables, read local files, and make network calls while trust controls are often weakest. In software supply chain terms, this is distinct from ordinary runtime behaviour: the package may not have been launched by a user, yet its install hooks, build scripts, or dependency preparation steps are already executing with meaningful authority. Guidance across ecosystems is still evolving, so definitions vary across vendors and packaging communities, but the security principle is stable: install-time logic must be handled like code, not metadata. That framing aligns with the governance intent of the NIST Cybersecurity Framework 2.0, which treats secure software handling as part of overall risk management. The most common misapplication is assuming installation scripts are inert because they are embedded in package metadata, which occurs when teams review only application source and ignore build or dependency execution paths.
Examples and Use Cases
Implementing controls around setup-time execution rigorously often introduces friction in packaging workflows, requiring organisations to weigh developer convenience against supply chain assurance.
- Python packaging may run build backends and installation hooks before the application is available, so CI pipelines should inspect those paths separately from source imports.
- JavaScript dependency installation can trigger preinstall or postinstall scripts, which means a package manager may execute code as soon as a dependency is added, not when the application starts.
- Container image builds can execute shell commands during image construction, so a malicious base layer or build step may exfiltrate secrets from the build environment.
- Native extensions compiled during setup may contact external services or read local configuration files, creating exposure even if the final application logic is benign.
- Security review tools and policies should treat package installation as an execution event, consistent with software supply chain guidance from NIST Secure Software Development practices, rather than waiting for a production launch.
Why It Matters for Security Teams
Setup-time execution matters because it collapses the traditional boundary between acquisition and execution. A package that looks safe on inspection can still run arbitrary logic while being installed, which makes dependency trust, build isolation, and secret handling critical security concerns. For teams managing developer platforms, this term intersects with broader software supply chain controls, artifact provenance, and CI/CD hardening. It also has a direct identity security angle: if build systems expose credentials, API keys, or workload tokens through environment variables, install-time code can harvest those secrets before runtime protections are in place. That is why organisations should pair package review with build sandboxing, least-privilege execution, and explicit controls over what the installer can reach. The security implications are often reflected in ecosystem guidance such as the OpenSSF Secure Software Development guidance and SLSA provenance practices, even though no single standard fully governs setup-time execution itself. Organisations typically encounter the damage only after a compromised dependency has already touched build secrets or modified the supply chain, at which point setup-time execution becomes operationally unavoidable to address.
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 and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-1 | Risk identification covers software supply chain exposure during installation execution. |
| NIST SP 800-53 Rev 5 | CM-7 | Least functionality limits what install-time code may execute on trusted systems. |
| NIST AI RMF | AI RMF is relevant where packages or tooling execute code in AI build pipelines. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant when installers can access workload secrets or tokens. | |
| NIST AI 600-1 | GenAI supply chain guidance applies when setup scripts affect AI artifacts or tools. |
Validate build and install steps before they can alter AI model or toolchain integrity.
Related resources from NHI Mgmt Group
- What breaks when certificate governance is treated as a one-time setup?
- Who is accountable when a critical platform flaw affects identity and code execution at the same time?
- 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?
