Installation-time execution is when malicious code runs during software setup, update, or package installation instead of during normal use. In security analysis, it often signals supply chain compromise, where a trusted installer or dependency triggers scripts, drops payloads, or alters systems before controls fully inspect the software.
What installation-time execution means in practice
Installation-time execution is dangerous because setup workflows often run with elevated trust and broad write access. At that moment, a package or installer can place files, register services, modify configuration, or launch helper processes before normal application controls begin to watch what it is doing.
This matters because the action happens in a control gap: the software is not yet fully in use, but it already has enough authority to change the host. In supply chain cases, that means a malicious update, installer script, or dependency hook can become the first execution path an attacker uses.
Why setup and update phases are high-risk
Installers frequently execute pre-install, post-install, and migration steps automatically. Those steps are intended to prepare the environment, but they also create an opportunity for abuse if a dependency, package repository, build pipeline, or distribution channel has been tampered with.
Attackers value this moment because it is trusted by users, operations teams, and often by endpoint allowlists. A malicious action that occurs during installation may look like routine package behaviour, which makes it easier to blend into expected administrative activity.
Where the software is containerized or delivered as an image, the same problem can appear in image build steps, bootstrap scripts, or init routines. NIST SP 800-190 Container Security is useful here because it treats image, registry, orchestrator, and runtime exposure as one chain rather than separate problems.
Common failure modes and security signals
Installation-time execution often shows up as unexpected script execution, silent payload drops, altered startup tasks, or configuration changes that were not part of the intended install path. It can also surface as new scheduled jobs, modified environment variables, or service registrations created by the installer.
One of the most important signals is that the change happens before the application reaches steady state. That makes post-install review especially important, because compromise may already be present even if the software appears to install successfully.
Broader control frameworks help explain why this is so sensitive. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant where organisations need stronger configuration management, integrity monitoring, and change control around software deployment.
How to reduce exposure and verify integrity
Reducing exposure starts with knowing exactly what is being installed, from where, and with what dependencies. Organisations should treat package sources, build artefacts, and vendor updates as trust boundaries and verify them before allowing privileged execution paths to run.
When installation logic is unavoidable, the safer pattern is to minimise privilege, isolate the install context, and inspect the resulting host state after setup completes. That includes checking for new services, scheduled tasks, persistence mechanisms, and unexpected outbound connections created during the install process.
Supply chain controls are central to this problem. SLSA helps practitioners reason about build provenance and artifact integrity, while OWASP SAMM helps organisations build security checks into the software delivery lifecycle.
Risk and Threat Considerations
Installation-time execution is a classic supply chain risk because it lets malicious code run at a moment when users expect benign setup behaviour. The danger is not only that the payload executes, but that it can change the host before stronger detection, review, or application-level controls are active.
Failure mechanism: A compromised installer, package hook, or dependency script executes with the permissions needed to write files, change startup behaviour, or stage additional malware during deployment.
Impact: The result can be host compromise, persistence, credential theft, or silent system modification that survives the initial install and is discovered only after downstream misuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, SLSA, OWASP ASVS and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Installation-time execution depends on privileged change paths that must be restricted. |
| SI-7 — Software, Firmware, and Information Integrity | This term centers on malicious code executing through trusted installation and update paths. | |
| Recommendation — Restrict who can alter installation and update logic so unexpected setup-time code cannot run unreviewed. Verify software integrity before and during installation to detect tampered packages and scripts. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Installation-time execution is often a supply-chain compromise issue involving artifact provenance and build integrity. |
| Recommendation — Require stronger provenance and integrity guarantees for artifacts that may execute during setup. | ||
| OWASP ASVS | V13 — Configuration | Installer-driven changes often alter system configuration before normal runtime protections apply. |
| Recommendation — Validate deployment-time configuration changes so install steps cannot silently weaken security settings. | ||
| OWASP SAMM | Software Assurance Maturity Model | This term aligns with secure software delivery practices that reduce malicious installer behavior. |
| Recommendation — Build security review into delivery workflows so setup logic is assessed before release. | ||
Practitioner Guidance
Why practitioners should care: Treat installation-time behaviour as part of the trusted computing base for deployment. If you only inspect software after first launch, you can miss the most dangerous stage, when a package is still earning trust and may already have made permanent changes.
What to watch for: Pay close attention to install scripts, package-manager hooks, image build steps, and any setup workflow that can reach the network or write to privileged locations. Post-install validation should confirm both the intended software state and the absence of unexpected persistence mechanisms.
Practitioner takeaway: The safest install is one that is provenance-checked, privilege-minimised, and observable from the first file written to the final reboot.
Related resources from NHI Mgmt Group
- 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?
- Why do package compromises that move from install hooks to import-time execution create a bigger trust problem?