Package install execution is the point at which dependency installation runs code on a developer machine or build runner. In supply chain attacks, that execution step becomes the entry point for secret theft, persistence, and propagation because it inherits trust before the workload is fully inspected.
Expanded Definition
Package install execution is the trust boundary where dependency installation can run arbitrary code on a developer machine or build runner. In NHI security, that matters because installation-time scripts can read environment variables, reach package registries, modify build artifacts, and persist before inspection catches anything.
Definitions vary across vendors, but the security meaning is consistent: the risk is not the package itself, it is the execution step embedded in install workflows. That step often happens inside CI/CD, local development, or ephemeral runners where secrets, tokens, and signing material may already be present. This is why package install execution belongs in supply chain governance alongside controls discussed in the Ultimate Guide to NHIs and baseline protection expectations from the NIST Cybersecurity Framework 2.0.
The most common misapplication is treating install-time code as a routine dependency step, which occurs when teams allow postinstall or setup hooks to run with broad runner permissions and access to secrets.
Examples and Use Cases
Implementing package install execution controls rigorously often introduces friction, requiring organisations to weigh build convenience against reduced exposure of secrets and signed artifacts.
- A CI job installs a package that runs a postinstall script and exfiltrates cloud tokens from runner environment variables.
- A developer laptop executes dependency setup code that plants persistence in shell startup files and steals SSH material.
- A build pipeline allows unpinned transitive dependencies, and the install step pulls a malicious version before code review or static analysis can help. The LiteLLM PyPI package breach is a useful reminder that package trust can fail at install time, not only at publish time.
- An internal package manager mirrors external dependencies but still permits lifecycle scripts, so the runner executes unreviewed code during deployment.
- A secure build process disables install hooks for third-party packages unless the package is explicitly approved and isolated to a sandboxed runner.
These patterns align with the NHI lifecycle concerns highlighted in the Ultimate Guide to NHIs and with identity and access expectations in supply chain environments described by NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Package install execution matters because it can expose the exact assets NHI defenders are trying to protect: API keys, signing secrets, registry credentials, and long-lived service-account tokens. Once install-time code runs, it may access secrets before policy engines, reviewers, or scanners can intervene. That is especially dangerous in CI/CD, where runners often hold broad automated privileges and where a single poisoned dependency can propagate across many builds.
NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage. Those conditions make install execution a high-value attacker path rather than a niche supply chain concern. The same risk profile is why NHIMG guidance on NHI governance treats secrets placement and runner trust as operational priorities, not implementation details.
Organisations typically encounter the impact only after a package compromise, stolen token, or poisoned build reveals that install-time code had enough authority to move laterally, at which point package install 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 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 code can steal or expose secrets, matching improper secret management risk. |
| NIST CSF 2.0 | PR.AC-4 | Install execution requires least-privilege access for build and developer environments. |
| NIST AI RMF | Package install execution is a supply chain risk that can introduce harmful AI or software behavior. |
Assess install-time code paths for malicious behavior and add controls that reduce untrusted execution.
