Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
Expanded Definition
Install-time execution describes code that runs during dependency installation, package bootstrapping, or build-time hooks rather than at application launch. In NHI and software supply chain contexts, the distinction matters because install phases often inherit broad access to secrets, build agents, and CI/CD tokens. Definitions vary across vendors, but the security concern is consistent: hidden execution at install time can act as an escalation path before normal runtime controls are active.
For practitioners, this is not the same as a standard startup script or a post-deploy runtime hook. It is closer to a privilege boundary that exists while packages are being resolved and prepared, which is why guidance from the NIST Cybersecurity Framework 2.0 is often used to frame it as a supply chain integrity issue, not just an application hygiene issue. Install-time execution becomes especially risky when dependency managers can invoke arbitrary code, fetch transitive packages, or expose environment variables that include secrets.
The most common misapplication is treating install-time behavior as harmless because it occurs before production deployment, which occurs when build pipelines run with over-privileged credentials and no execution review.
Examples and Use Cases
Implementing controls around install-time execution rigorously often introduces pipeline friction, requiring organisations to weigh developer velocity against the cost of stricter verification and sandboxing.
- A malicious package runs a pre-install script that reads CI environment variables and exfiltrates API keys before the build completes.
- A transitive dependency executes code during installation to alter lockfiles or inject a backdoor into generated artifacts.
- A build tool runs helper binaries at install time, but the agent has access to signing keys and deployment tokens that should have been isolated.
- A developer workstation uses permissive package hooks, allowing unreviewed code to execute with access to local credentials and cached secrets.
- A security team correlates package install events with secret exposure after reviewing guidance in the Ultimate Guide to NHIs and applying package provenance checks informed by the NIST Cybersecurity Framework 2.0.
In modern CI/CD, the main use case is defensive: security teams inspect package manager behavior, isolate build steps, and remove secret exposure from the install path. The Ultimate Guide to NHIs is especially relevant where service accounts and automation tokens are present during dependency resolution.
Why It Matters in NHI Security
Install-time execution matters because it often occurs in the same environment where NHI secrets, ephemeral credentials, and pipeline identities are already in memory or on disk. That makes it a direct bridge between software supply chain compromise and NHI compromise. NHI Mgmt Group research shows that Ultimate Guide to NHIs notes 96% of organisations store secrets outside secrets managers in vulnerable locations, including code, config files, and CI/CD tools, which turns install phases into high-value interception points.
This term also matters for governance. If install-time behavior is not reviewed, teams may believe they are enforcing least privilege while build-time automation is actually running with broad access. That misalignment weakens Zero Trust controls, undermines NIST Cybersecurity Framework 2.0 practices, and increases the chance that compromised dependencies can pivot into service accounts or signing workflows. The operational lesson is simple: install-time code is part of the trust boundary, not outside it.
Organisations typically encounter credential theft, poisoned builds, or unexpected artifact tampering only after a dependency incident or pipeline compromise, at which point install-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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Install-time code can expose or abuse secrets during dependency install. |
| NIST CSF 2.0 | PR.DS | Protecting data and secrets in transit and at rest applies to build-time execution risk. |
| NIST Zero Trust (SP 800-207) | 3.4 | Zero Trust requires limiting implicit trust in build and install execution paths. |
Treat installers as untrusted and verify each execution path before granting access.
Related resources from NHI Mgmt Group
- What is Just-in-Time (JIT) access and why is it important for NHI security?
- When do NHI access reviews create more value than a one-time cleanup?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- How do organisations reduce the dwell time of exposed credentials at scale?
