Setup-Time Execution

What setup-time execution really means

Setup-time execution is not passive metadata, it is active code running before an application is fully imported or started. That means the install or build step can already influence the host, inspect the environment, and reach out over the network, so the security boundary begins much earlier than many teams assume.

This matters because package installation often has broader ambient access than runtime code, including filesystem visibility, build variables, shell invocation, and dependency resolution. A malicious or compromised setup hook can therefore become an entry point for tampering, data access, or supply-chain abuse before normal application controls are even engaged.

Why setup-time execution is dangerous

The danger is not only that code runs, but that it runs at a privileged moment in the software lifecycle. Install-time logic can execute in developer laptops, CI pipelines, image builds, or deployment jobs, where secrets, tokens, and source material may be present and where defenders may be expecting a harmless install rather than real execution.

That makes this phase attractive for dependency attacks, build compromise, and hidden exfiltration. If a package author, maintainer account, or transitive dependency is abused, setup-time code can perform actions that look like ordinary packaging work while quietly reading files, modifying artifacts, or contacting external infrastructure.

How organisations should think about exposure

Exposure starts with inventory and trust boundaries: know which packages can run setup logic, where they are installed, and in which environments they are allowed to execute. Build systems, container images, and developer workstations should be treated differently, because the same hook can have very different consequences depending on what data and permissions are present.

It is also important to distinguish safe packaging metadata from executable behaviour. Dependency review should include the installation path, build backend behaviour, and any code that runs as part of preparation, because that code can matter as much as the application itself. Guidance for containerised environments in NIST SP 800-190 Container Security is useful here because it reinforces that software supply-chain stages and runtime stages both need explicit control.

Controls and safer handling of install-time code

The most effective control is to reduce or eliminate unexpected execution during installation and to isolate any execution that remains necessary. That means preferring packages and build steps with transparent, reviewable behaviour, limiting network and filesystem reach during builds, and applying least-privilege principles to the environment that performs installs.

Supply-chain controls should also cover provenance, dependency approval, and repeatable builds. A package that is safe to import is not automatically safe to install, so teams should review build and install pathways separately and treat them as part of software integrity rather than as a convenience feature. SLSA is directly relevant because it frames build provenance and integrity as first-class supply-chain concerns, while OWASP SAMM helps teams build secure delivery practices that account for this class of risk.

Risk and Threat Considerations

Setup-time execution creates a high-value attack window because code can run before normal application defences, review workflows, or runtime containment fully apply. If attackers can place or modify package behaviour at this stage, they may gain access to build secrets, sensitive files, or outbound channels that are harder to monitor than application traffic.

Failure mechanism: a dependency, build backend, or package hook executes during installation and abuses that early trust to read local data, alter artifacts, or establish external communication before the application is operational.

Impact: the result can be supply-chain compromise, secret exposure, poisoned builds, or persistence in downstream artifacts and deployment pipelines.

Practitioner Guidance

Why practitioners should care: teams often focus on runtime security and miss the fact that installation itself can be an execution surface. If install-time logic is allowed to run unreviewed, the build process can become the easiest place to smuggle in unwanted behaviour.

What to watch for: packages that execute code during install, build, or wheel preparation deserve extra scrutiny, especially when they are new, lightly maintained, or pull in many transitive dependencies. Treat any install step that needs network access, filesystem access, or environment inspection as active software behaviour, not a passive setup action.

Related resources from NHI Mgmt Group

• Execution (MITRE ATT&CK Tactic)
• Why do background agents need policy checks at execution time instead of only at setup time?
• 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?