Subscribe to the Non-Human & AI Identity Journal

Preinstall Execution

Preinstall execution is code that runs before a package finishes installing. In supply chain attacks, that timing matters because it lets malicious logic execute before many scanners, policy checks, and human reviews can intervene, turning installation into a compromise point rather than a delivery step.

Expanded Definition

Preinstall execution refers to code that runs before a package completes installation, which means it can act while trust is still being established rather than after controls have settled. In software supply chain and NHI-adjacent environments, that timing makes it especially dangerous because installation paths often carry elevated permissions, transient trust, and weak inspection coverage. The concept is not a distinct identity control standard; definitions vary across vendors and package ecosystems, and no single standard governs this yet. Practitioners should treat preinstall logic as part of the trust boundary for NIST Cybersecurity Framework 2.0 and related build hygiene, because code that runs during installation can prepare persistence, alter dependencies, or stage credential theft before normal reviews complete. In NHI security, the concern is not only malicious application code but also installer scripts that reach into secrets, token stores, or CI/CD context. The most common misapplication is assuming installation-time code is harmless boilerplate, which occurs when teams review only the final package contents and ignore the execution path that occurs before the package is fully trusted.

Examples and Use Cases

Implementing controls around preinstall execution rigorously often introduces release friction, requiring organisations to weigh faster installs against stronger inspection, sandboxing, and provenance checks.

  • A package manager runs a preinstall script that attempts to read environment variables, exposing tokens injected into build jobs.
  • A malicious dependency modifies local configuration before the main application is installed, creating persistence that later survives routine patching.
  • A CI pipeline installs an internal tool with a preinstall hook that reaches out to an external endpoint, making outbound validation an essential control.
  • A registry review flags a package whose preinstall logic is unnecessary for functionality, prompting the team to block execution during installation and compare it with the patterns highlighted in the Ultimate Guide to NHIs.

For supply chain governance, teams often align this review with NIST Cybersecurity Framework 2.0 practices for code integrity and controlled execution, especially when installers can inherit privileged context or reach service credentials.

Why It Matters in NHI Security

Preinstall execution matters because NHI compromise often begins where automation is least supervised: build systems, package managers, and deployment runners. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes any code that runs before installation complete a high-value attack surface. The problem is amplified when secrets are stored in code or passed into installation jobs, because preinstall logic can exfiltrate them before detection tools finish scanning. This is why the Ultimate Guide to NHIs is so relevant: it shows how identity sprawl, excess privilege, and weak visibility create conditions where small execution windows become compromise events. Organisations should pair package review with execution controls, provenance checks, and secret minimisation in build environments. Practitioners typically encounter this term only after a dependency incident or CI compromise reveals that the installer, not the application, was the initial point of execution, at which point preinstall 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-02 Installer scripts can expose or misuse secrets before trust is established.
NIST CSF 2.0 PR.DS-6 Preinstall execution threatens software integrity and controlled execution paths.
NIST Zero Trust (SP 800-207) AC-3 Zero trust limits implicit trust in code running during installation.
NIST AI RMF AI-driven build and automation flows need risk controls for execution before validation.
OWASP Agentic AI Top 10 A10 Agentic toolchains can be tricked by preinstall code that runs before policy checks.

Validate package provenance and restrict installer execution in build and deployment workflows.