Import-time dependency compromise

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.

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?