Look for three signals: scripts are blocked or tightly governed during install, runner memory and local secrets are minimized, and package provenance is checked before deployment. If developers can still install arbitrary lifecycle hooks with broad credentials present, the risk is not under control. Strong secrets hygiene alone is not enough if execution itself remains trusted.
Why This Matters for Security Teams
Package installation is often treated as a build-time convenience, but it is really an execution pathway with privilege, network reach, and access to developer or runner secrets. That makes it a supply-chain control point, not just a dependency-management task. When install-time scripts can run freely, a malicious or compromised package can execute before any application code is deployed. NIST’s NIST Cybersecurity Framework 2.0 reinforces that asset, identity, and change controls must be governed together, which is exactly where package risk usually slips through.
NHI Management Group’s research on the Top 10 NHI Issues and the LiteLLM PyPI package breach both show the same pattern: compromise often comes through trusted automation paths, not obvious perimeter failures. The question is not whether secrets are stored securely in general, but whether the installation process itself can be trusted to execute unknown code without broad privilege. In practice, many security teams discover package-installation exposure only after a dependency or lifecycle hook has already touched production-like credentials.
How It Works in Practice
Security teams know package installation risk is under control when the install path is intentionally narrow and observable. That means install scripts are blocked by default or allowed only through explicit policy, runtime credentials are ephemeral, and build agents do not carry long-lived tokens that survive a failed or malicious install. Provenance checks matter as well: the package should be verified before it reaches the environment, not after it has already executed.
A practical control set usually includes:
- Disabling or tightly governing lifecycle hooks such as preinstall and postinstall steps.
- Running builds with minimal local secrets and no standing cloud or registry credentials.
- Using short-lived, task-scoped credentials for package retrieval and signing verification.
- Requiring package provenance, checksum validation, or signed attestations before deployment.
- Logging install-time behavior so unexpected network calls or file writes are detectable.
This is not just a secrets hygiene issue. If a package can still execute arbitrary code during installation, that execution path becomes part of the trust boundary. The The 2024 ESG Report: Managing Non-Human Identities reports that 72% of organisations have experienced or suspect a breach of non-human identities, which helps explain why pipeline trust is now treated as an identity problem as much as a software problem. Current guidance suggests aligning package controls with Ultimate Guide to NHIs — Standards and established software-supply-chain controls rather than relying on developer discipline alone.
These controls tend to break down when package managers are allowed outbound internet access with broad tokens present, because the install step can fetch, execute, and exfiltrate before detection tools have meaningful context.
Common Variations and Edge Cases
Tighter install controls often increase build friction and can slow dependency onboarding, so organisations have to balance developer velocity against the blast radius of a compromised package. That tradeoff becomes sharper in monorepos, ephemeral CI runners, and AI-assisted build pipelines, where dependency churn is high and package behavior may vary by platform or architecture.
There is no universal standard for this yet, but best practice is evolving toward context-aware approval. For example, a package used only in test jobs may tolerate different controls than one installed in a release pipeline. Some teams also separate “fetch” from “execute,” allowing package retrieval in a constrained network zone while deferring any execution until the artefact is scanned, attested, and promoted. The Ultimate Guide to NHIs — Why NHI Security Matters Now is useful here because it frames package-install identities as machine identities that should be bounded, monitored, and rotated like any other non-human access.
Edge cases also matter. Some ecosystems still depend on install-time compilation or native extensions, so blocking all scripts may not be operationally feasible. In those environments, current guidance suggests compensating with hardened sandboxes, package allowlists, and strict provenance enforcement rather than granting broad installer trust. The control is under control only when exceptions are visible, time-bound, and rare, not when “temporary” allowances have become the default.
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-03 | Install-time credentials and scripts are classic NHI exposure points. |
| NIST CSF 2.0 | PR.AC-4 | Package installs need least privilege and controlled access to execution paths. |
| NIST AI RMF | Provenance and runtime trust decisions are part of AI-assisted supply-chain risk. |
Restrict install-time permissions so package execution cannot inherit broad system or secret access.
