An install-time script is code that executes when a package is installed, before the package has necessarily been validated in context. Attackers abuse these scripts because they can trigger silently in developer machines and CI systems, turning dependency installation into an execution path.
Expanded Definition
An install-time script is executable code that runs during package installation, usually as part of a dependency manager, build tool, or platform installer. In NHI and software supply chain contexts, it matters because the script executes before the package has necessarily been reviewed, isolated, or approved in its final runtime environment. Guidance varies across vendors on how aggressively these scripts should be blocked, but the security principle is consistent: installation should not become an implicit execution grant. The NIST Cybersecurity Framework 2.0 frames this as an integrity and protective control problem, while NHI governance treats it as a trust-boundary issue for code, secrets, and automation credentials.
Install-time scripts are not inherently malicious. They are often used for platform setup, native dependency compilation, or environment checks. The risk emerges when the script is granted broad access to developer workstations, CI runners, secret stores, or package registry tokens without sufficient inspection or policy enforcement. The most common misapplication is assuming a trusted repository makes every install-time script safe, which occurs when organisations conflate package provenance with execution safety.
Examples and Use Cases
Implementing install-time script controls rigorously often introduces friction in build workflows, requiring organisations to weigh developer convenience against the risk of silent code execution during dependency installation.
- A JavaScript package runs a postinstall step that downloads additional binaries, which is useful for setup but dangerous if the package is compromised or typosquatted.
- A CI job installs dependencies with elevated permissions, and an install-time script reads environment secrets exposed to the runner.
- A developer laptop auto-executes package scripts during a routine update, creating a path for credential theft from local token caches.
- A hardened pipeline disables install scripts by default and only allows them for reviewed packages, with exceptions logged for later audit.
- An organisation investigates why a third-party dependency launched network calls during install and maps the event to supply chain exposure documented in the Ultimate Guide to NHIs.
These patterns align with broader software governance guidance in NIST Cybersecurity Framework 2.0, especially where build integrity and access control intersect. They also connect to NHI operations because install-time execution can expose service account tokens, API keys, and CI credentials if those secrets are present at install time.
Why It Matters in NHI Security
Install-time scripts turn dependency management into an execution channel, which means the attack surface extends beyond source code to package metadata, build hooks, and automation environments. For NHI security, this is critical because secrets, ephemeral credentials, and service account tokens are often present in CI/CD systems at exactly the moment a package is installed. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes install-time execution especially dangerous when those locations are reachable during build or install steps. The Ultimate Guide to NHIs also notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage.
Practitioners should treat install-time scripts as part of the trust boundary around NHI credentials, not just as a software packaging concern. That means reviewing whether installation occurs with access to long-lived secrets, whether scripts are allowed to reach the network, and whether CI runners can be assumed clean at install time. When those assumptions fail, package installation becomes a practical route to identity compromise, lateral movement, and pipeline abuse. Organisations typically encounter this consequence only after a dependency compromise or CI incident, at which point install-time script governance 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 | Install-time scripts often expose secrets and credentials during dependency installation. |
| NIST CSF 2.0 | PR.AC-3 | Privilege and access boundaries are at risk when install scripts run in CI or dev environments. |
| NIST Zero Trust (SP 800-207) | SA-5 | Zero Trust requires untrusted code to be treated as hostile until validated. |
| NIST AI RMF | Install-time execution is a governance risk when AI tooling auto-installs dependencies. | |
| OWASP Agentic AI Top 10 | A2 | Agentic systems may execute dependency installs that trigger hidden scripts. |
Apply risk controls to automated installation behavior and review toolchain trust assumptions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
