Malicious code that activates when a package is imported or required rather than when it is installed. This design lets attackers avoid simple install-time scanning and blend execution into normal application, build, or CI/CD runtime behaviour.
Expanded Definition
A load-time dropper is malicious code that lies dormant until a package is imported, required, or otherwise loaded by an application runtime. That timing matters because it shifts execution away from the install step, where many scanners focus, and into ordinary application behaviour where it is easier to hide.
In NHI and software supply chain contexts, the threat is not just the payload itself but the trust boundary it crosses. A dependency may look harmless at package installation, then execute hidden logic when a build tool, test runner, server process, or agentic workflow imports it later. This is especially dangerous when code has access to secrets, service account tokens, signing material, or CI/CD credentials. Industry usage of the term is still evolving, but it generally overlaps with dependency injection abuse, package loader abuse, and runtime-triggered supply chain compromise. The operational concern is that import-time execution can blend into legitimate application startup, making forensic timelines harder to reconstruct. For broader governance framing, the NIST Cybersecurity Framework 2.0 remains useful for mapping detection and response responsibilities around this class of threat.
The most common misapplication is treating all malicious package behaviour as install-time malware, which occurs when teams only inspect package installation events and ignore code paths triggered during import or load.
Examples and Use Cases
Implementing detection rigorously often introduces developer friction, because deeper inspection of package entry points and runtime hooks can slow builds and require more precise allowlisting, but that cost is often justified by the reduction in hidden execution paths.
- A Python dependency executes a payload in Python import mechanics when the application starts, not during pip installation.
- A Node.js package triggers malicious code during module loading, allowing the attacker to wait until the CI job or service boots.
- A build plugin reads environment variables at load time and exfiltrates secrets from the pipeline before the main job logic runs.
- An internal utility library appears benign in artifact scanning, but imports a second-stage downloader only when invoked by a production worker.
- NHIMG’s Ultimate Guide to NHIs is useful context here because load-time execution often targets credentials already present in the runtime environment.
These patterns are commonly discussed alongside software supply chain risk and runtime trust assumptions, especially when package managers and automation systems are granted broad execution rights.
Why It Matters in NHI Security
Load-time droppers are especially dangerous in NHI environments because service accounts, API keys, and machine tokens are often available to the process that loads the package. That means a single malicious import can turn a trusted dependency into a credential theft event. 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 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs. Those conditions make runtime-triggered malware far more effective than simple install-time scanners expect.
Security teams should align response with dependency provenance, runtime hardening, least privilege, and secret segregation. A dependency that can execute at load time should be treated as an execution-capable actor, not just a code artifact. That perspective fits the operational intent of NIST Cybersecurity Framework 2.0, especially around asset visibility, protective controls, and anomaly detection. Organisations typically encounter the impact only after a pipeline credential or production token is used outside its normal path, at which point load-time droppers become 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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Load-time droppers exploit secret exposure inside runtime and dependency paths. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access limits the blast radius when loaded code reaches NHI credentials. |
| NIST Zero Trust (SP 800-207) | PA-4 | Zero Trust requires continuously verifying access even for code executing in trusted runtimes. |
| NIST SP 800-63 | Identity assurance concepts help classify machine credentials exposed to malicious loaders. | |
| OWASP Agentic AI Top 10 | A-06 | Agentic and tool-using runtimes can import packages that trigger hidden code execution. |
Bind stronger assurance and lifecycle controls to service credentials used by build and app runtimes.
Related resources from NHI Mgmt Group
- What is Just-in-Time (JIT) access and why is it important for NHI security?
- When do NHI access reviews create more value than a one-time cleanup?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?
- How do organisations reduce the dwell time of exposed credentials at scale?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
