A malicious component that executes after a package is imported, not during installation. It delays its actions until runtime, which can help it evade controls that only inspect install scripts. In practice, this pattern is dangerous because normal application use becomes the trigger for payload delivery and persistence.
Expanded Definition
An import-time dropper is a supply chain abuse pattern in which a malicious package component waits until the package is loaded by an application, then executes code as part of the normal import path. It is distinct from an install-time payload, because the harmful behaviour is delayed until runtime and often appears only after a legitimate dependency is imported. That timing matters in Python and similar ecosystems where modules can run initialization code automatically, making the boundary between “library” and “execution” easier to exploit.
For security teams, the key distinction is that the package may look harmless during build or installation checks, yet still activate when the application starts or reaches a specific code path. This makes the threat especially relevant to software supply chain review, dependency trust, and runtime monitoring. The concept aligns naturally with the NIST Cybersecurity Framework 2.0 emphasis on protective governance and detection across the full lifecycle, not only at admission time. Guidance across vendors is still evolving on how broadly to classify these payloads, but the operational concern is consistent: code execution is deferred, not absent. The most common misapplication is treating a clean installation log as proof of safety, which occurs when teams do not inspect module import behaviour or runtime side effects.
Examples and Use Cases
Implementing import-time protections rigorously often introduces review overhead and runtime testing cost, requiring organisations to weigh delivery speed against the risk of hidden code execution.
- A dependency contains a module-level function that contacts an external server as soon as the application imports it, turning ordinary startup into the trigger for command-and-control traffic.
- A package used in a data pipeline silently stages additional files on import, so the payload only appears when the pipeline worker loads the dependency in production.
- A developer tests installation in a sandbox and sees no alerts, but the malicious behaviour appears later when the application imports the library during a scheduled task.
- A build system permits a dependency because its install script is benign, yet the package executes credential theft logic through import hooks once a service starts.
- Security teams use static inspection and runtime observation to compare what a package does during install against what it does at import, informed by supply chain controls in the NIST Cybersecurity Framework 2.0.
These examples matter because import-time execution can be triggered by ordinary application paths, not by obvious admin actions. That makes the malicious behaviour hard to reproduce in pre-production if the relevant module path is never exercised.
Why It Matters for Security Teams
Import-time droppers expose a blind spot in package screening: teams that only verify installation behaviour can miss code that activates after deployment, when real users and services begin loading dependencies. That gap is particularly dangerous in CI/CD environments, serverless functions, and agentic AI stacks where third-party modules may be imported automatically as part of routine execution. For identity-heavy systems, the risk can extend to secrets, tokens, and API keys present in process memory or accessible through environment variables at runtime.
Security programs should treat package provenance, dependency minimisation, and runtime detection as a combined control set. The NIST Cybersecurity Framework 2.0 helps frame that approach as an ongoing governance problem rather than a one-time ingest decision. For teams building with autonomous agents or LLM-adjacent tooling, OWASP Agentic AI Top 10 is also relevant when imported tooling can execute with tool access or workspace permissions. Organisations typically encounter the impact only after a production import unexpectedly triggers outbound connections, secret exposure, or persistence, at which point import-time 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 Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.SC-1 | Supply chain risk management covers malicious dependency behavior that appears after deployment. |
| OWASP Agentic AI Top 10 | Agentic AI guidance addresses tool-use and execution risks from imported components. | |
| NIST AI RMF | AI RMF applies where imported code can affect AI system trust, safety, and monitoring. | |
| OWASP Non-Human Identity Top 10 | NHI guidance is relevant when imports can expose secrets, tokens, or service identities. | |
| NIST SP 800-53 Rev 5 | SI-7 | System integrity controls address malicious code that activates after installation. |
Track imported packages as supply chain assets and verify them beyond installation checks.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
