An install-time script that runs automatically when an NPM package is prepared or installed from a Git source. It is powerful because it executes before many defenders expect code to run, turning dependency resolution into an execution surface if the source is malicious or compromised.
Expanded Definition
A prepare lifecycle hook is an NPM package script that runs during preparation or when a package is installed directly from a Git source. In NHI security terms, it matters because it can turn dependency resolution into an execution path before standard review gates or runtime controls have a chance to intervene. The hook is not inherently malicious, but it is a high-risk trust boundary because package authors can use it to build artifacts, transform source, or execute arbitrary commands. The OWASP Non-Human Identity Top 10 frames this kind of hidden execution as part of the broader problem of trust in automated software supply chains, where credentials, tokens, and build-time permissions are often present long before defenders expect them to be used.
Definitions vary across vendors on whether prepare should be treated as a normal build step or as a privileged pre-install action, but operationally it should be treated as code execution with access to developer and CI context. The distinction matters because Git-based installs can bypass the assurance teams assume they get from registry-mediated package distribution. The most common misapplication is assuming prepare is harmless metadata processing, which occurs when teams allow Git dependencies without reviewing their lifecycle scripts or build-time permissions.
Examples and Use Cases
Implementing controls around prepare hooks rigorously often introduces friction in package consumption, requiring organisations to weigh developer convenience against the risk of unintended code execution during dependency installation.
- A build pipeline installs a package from Git, and the prepare hook compiles or modifies files before the package is pinned, creating a path for hidden payloads to run.
- A developer adds a Git dependency for a utility library, but the package’s prepare script reaches out to a remote endpoint, exposing environment variables or local secrets.
- A malicious dependency uses prepare to stage a post-install payload that only activates in CI, making detection harder during manual testing.
- Teams following the NHI Lifecycle Management Guide treat package scripts like privileged lifecycle events and restrict where Git-sourced installs can execute.
- Security reviewers compare the behavior to supply-chain execution patterns described in the OWASP Non-Human Identity Top 10, especially when build identities already have token access.
For broader lifecycle and secret-handling context, the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Guide to the Secret Sprawl Challenge show why build-time execution paths are especially dangerous when secrets are already distributed across code, CI tools, and local developer environments.
Why It Matters in NHI Security
Prepare hooks matter because they can execute in contexts where service account tokens, CI credentials, and repository secrets are present but not expected to be exposed. That makes them an NHI risk, not just a software packaging quirk. If a package install can run arbitrary code, then any attached secret, token, or certificate becomes potentially reachable during dependency resolution. This is especially dangerous in organisations that already struggle with lifecycle governance: NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 71% of NHIs are not rotated within recommended time frames. Together, those conditions make build-time execution a common path from code import to credential compromise.
The operational lesson is that prepare should be governed like any other privileged automation step. Build identities need restricted permissions, Git-sourced dependencies need review, and secret exposure during install should be treated as a control failure, not an anomaly. The most direct defensive posture combines package policy, source review, and lifecycle discipline from the Top 10 NHI Issues with execution-hardening guidance from the Guide to NHI Rotation Challenges. Organisations typically encounter prepare-hook risk only after a dependency import triggers unexpected command execution, at which point lifecycle control 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 AI RMF 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 | Covers secret exposure and lifecycle misuse in NHI execution paths. |
| NIST CSF 2.0 | PR.AC-3 | Access control applies to automated build and install identities. |
| NIST AI RMF | Addresses operational risk from automated execution and hidden dependencies. | |
| NIST Zero Trust (SP 800-207) | 5.2 | Zero trust limits implicit trust in code execution paths and identities. |
| OWASP Agentic AI Top 10 | A2 | Automated code execution can become an unsafe tool-use or supply-chain vector. |
Block high-risk package scripts and ensure build secrets are not accessible during dependency installs.
