Because they execute inside the same environments that usually hold API keys, tokens, certificates, and automation accounts. Once malicious code runs in a build runner or developer machine, it can search memory, environment variables, and cached credentials before traditional malware controls notice. That turns package trust into a direct path to NHI exposure.
Why This Matters for Security Teams
Import-time payloads are dangerous because they run as soon as a package is loaded, often before application logic, endpoint detections, or runtime guardrails have a chance to intervene. That timing matters in CI/CD, developer workstations, and build containers where automation frequently holds NHI secrets such as API keys, signing certificates, tokens, and cloud credentials. A trusted dependency can become an execution path into the very environment that is meant to assemble and protect software.
The risk is not limited to classic malware. A malicious import can read environment variables, inspect local caches, hook package managers, and exfiltrate secrets during installation or test execution. This is why the OWASP Non-Human Identity Top 10 is relevant here: NHI secrets are often operationally necessary, but they become a supply chain liability when package trust is treated as equivalent to code trust. Security teams often underestimate how much privilege exists in build systems and developer tools.
In practice, many security teams encounter NHI exposure only after a dependency event has already reached the pipeline, rather than through intentional package verification.
How It Works in Practice
Import-time payloads work by abusing the fact that many ecosystems execute package code during install, import, or metadata resolution. That gives an attacker a short but high-value window to inspect process state, search credential stores, or establish persistence. In an NHI context, the highest-value targets are tokens and secrets that support automation: cloud access keys, signing keys, service account credentials, and secret manager access paths.
Controls need to address both provenance and runtime exposure. The NIST Cybersecurity Framework 2.0 is useful for structuring the response across identify, protect, detect, respond, and recover, but the mechanics are practical:
- Pin and verify dependencies, including transitive packages and lockfiles, before they enter a build.
- Reduce secret availability in install and test stages by using short-lived credentials and scoped tokens.
- Isolate build runners so package execution cannot reach production-grade secrets or trust stores.
- Scan for suspicious install hooks, unexpected network calls, and package behavior changes.
- Separate signing, release, and deployment identities so compromise of one stage does not expose all automation.
Where possible, the safest pattern is to inject NHI secrets only at the moment of use, rather than keeping them present throughout the build lifecycle. That includes tightening secret manager policies, using ephemeral credentials, and ensuring logs, crash dumps, and debug output do not capture secrets. These controls tend to break down when legacy build scripts require long-lived environment variables because package installation, testing, and deployment all share the same privileged execution context.
Common Variations and Edge Cases
Tighter package controls often increase build friction, requiring organisations to balance supply chain assurance against developer velocity. That tradeoff becomes sharper in polyglot repositories, offline build environments, and plugin-based systems where import-time execution is expected rather than suspicious. In those cases, best practice is evolving, and there is no universal standard for how much package code should be allowed to run during install versus first use.
One edge case is internal packages: teams often trust them more than external dependencies, yet internal packages can still carry import-time payloads after a compromised maintainer account, poisoned update, or malicious merge. Another is agentic AI and automation tooling, where import-time code may access model connectors, vector stores, or orchestration credentials. That creates an identity bridge between package risk and NHI governance, because the same secrets used to operate pipelines can also authorize AI agents and downstream services.
Security teams should also treat emergency fixes carefully. Rapid dependency replacements, hot patches, and mirrors can improve availability but may bypass normal review and provenance checks. When a build system is optimized for speed and secrets are broadly mounted, import-time payloads can succeed even if endpoint tooling is mature. In those environments, the assumption that package trust equals safe execution is usually the weakest control.
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, MITRE ATLAS and OWASP Agentic AI 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-2 | Import-time payloads often target exposed automation secrets and tokens. |
| NIST CSF 2.0 | PR.DS | Protecting data and secrets in build environments is central to reducing this risk. |
| MITRE ATLAS | Malicious package execution can support payload delivery and credential theft patterns. | |
| OWASP Agentic AI Top 10 | A5 | Agent and tool credentials can be exposed by code that runs at import time. |
| NIST AI RMF | GOVERN | AI-connected build and automation pipelines need explicit governance over dependencies and secrets. |
Minimise secret exposure during package execution and rotate credentials used in build and deploy paths.
