A supply chain attack where malicious code executes when a package is imported, not when it is installed. The risk is that ordinary application startup, tests, and build steps can trigger hidden payloads before teams realise the dependency is untrusted.
What import-time dependency compromise means
Import-time dependency compromise is a software supply chain attack pattern in which malicious code executes when a package is imported, rather than when it is installed. That timing makes the attack easy to miss because normal application startup, test runs, and build steps can trigger the payload.
The key distinction is execution timing. A package can look harmless during installation yet still run attacker-controlled logic the moment an application imports it. That makes the compromise especially relevant in environments that rely on automated startup paths, CI jobs, or dependency-heavy services where imports happen repeatedly and at scale.
How the attack works
Most import-time compromises exploit the fact that many ecosystems permit code to run during module loading. In Python, for example, import hooks, package initializers, or side-effectful top-level code can execute before the rest of the application has fully started. If the dependency has been swapped, trojaned, or updated with malicious behaviour, the import becomes the activation point.
This is why the issue is broader than a simple bad package. The attacker is taking advantage of a trusted execution path inside the dependency ecosystem. A developer may review the package name, install source, or version pin and still miss that the imported module performs network calls, credential access, process injection, or environment inspection as soon as it is loaded.
Why it is dangerous
The risk is not only that malicious code can run, but that it runs early and under ordinary application trust. That can let an attacker steal secrets, alter runtime behaviour, or establish persistence before security tools or developers have a chance to observe suspicious post-install activity. The wider the dependency footprint, the more likely one compromised package can affect many projects at once.
This pattern also undermines a common assumption in software review, namely that package installation is the critical checkpoint. In import-time attacks, the real trigger is operational execution, so build pipelines and test harnesses can become the first victims rather than the last line of defence. Open-source supply chain controls from OpenSSF are relevant because they focus on the broader integrity of package ecosystems, not just installation-time checks.
Practical security implications
Import-time compromise pushes defenders to think about package trust, runtime behaviour, and dependency review as a single problem. A dependency that is safe to install is not necessarily safe to execute, and that matters in languages and frameworks that routinely execute module-level code during normal operation.
Teams should treat dependency provenance, code review, and runtime observation as complementary controls. A package may pass signature checks or version pinning and still be unsafe if its import path contains hidden side effects. That is why supply chain visibility tools, sandboxed testing, and careful review of newly introduced dependencies are so important in modern build and deployment workflows. For a real-world example of package abuse, see LiteLLM PyPI package breach.
Risk and Threat Considerations
Import-time compromise is particularly dangerous because it turns a routine software action into an execution trigger. The attacker benefits from trusted execution context, broad reach across development and production workflows, and the chance to act before defenders notice that the dependency has been tampered with.
Failure mechanism: Malicious code is placed in the package’s import path, then runs automatically when the module is loaded, allowing the payload to execute through normal application behaviour, tests, or build steps.
Impact: Secrets can be exposed, application logic can be altered, and the compromised dependency can become a launch point for lateral movement or further supply chain abuse.
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 MITRE ATT&CK address the attack and risk surface, while SLSA and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Import-time compromise can expose secrets when code runs on import. |
| NHI-03 — Vulnerable Third-Party NHI | Supply chain abuse of third-party packages maps to dependency compromise risk. | |
| Recommendation — Scan imported dependencies for secret-handling side effects and block packages that access credentials during load. Vet third-party packages with provenance and integrity checks before allowing them into builds. | ||
| SLSA | Supply chain integrity | This attack is a software supply chain integrity problem at package execution time. |
| Recommendation — Increase artifact provenance and dependency integrity checks before packages reach runtime. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Package loading behaviour and third-party code review are part of application security. |
| Recommendation — Review dependency behaviour and restrict untrusted package execution in application pipelines. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Malicious package import is a supply chain compromise technique. |
| Recommendation — Map affected dependencies to supply chain compromise and hunt for compromised package execution. | ||
Practitioner Guidance
What to watch for: Treat any new or changed dependency that executes code at import time as a higher-risk change, especially when the package has broad transitive reach or touches sensitive startup paths. Side effects in top-level module code are a common sign that the dependency deserves closer scrutiny.
Governance implication: Ownership of dependency risk should extend beyond the security team to the teams that approve, update, and run packages in build and runtime environments. The practical question is not only whether a package is approved, but whether its import behaviour is acceptable in the places it will actually execute.
Related resources from NHI Mgmt Group
- Who is accountable when dependency compromise or import-time execution reaches production systems?
- When does a dependency compromise become an identity incident?
- How should organisations reduce MFA compromise from real-time phishing?
- How should teams choose between bulk import and just-in-time CIAM migration?