What breaks when a Python package can run code on import?

The trust boundary breaks first. Import-time execution lets untrusted code run before the application establishes its own security checks, so any secrets already present on the host become fair game. In practice, that means cloud keys, SSH material, and service account tokens can be stolen before the workload even reaches its intended business logic.

Why This Matters for Security Teams

When a Python package can execute code at import time, the package boundary is no longer a passive dependency boundary. The act of resolving and importing code becomes an execution event, which means supply chain trust, runtime trust, and secret exposure collapse into the same moment. That is exactly why the attack path seen in the LiteLLM PyPI package breach matters: a dependency can become an access path before application controls are in place.

Security teams often focus on post-launch protections such as RBAC, egress filtering, or runtime monitoring, but import-time execution happens earlier than those defenses are effective. If environment variables, mounted tokens, cloud metadata access, or local credential caches are already present, malicious code can read them immediately. NHI Mgmt Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes dependency-originated execution a direct identity-risk issue, not just a software hygiene issue.

The practical implication is simple: trust decisions must move left. If a package can run before the workload establishes its own guardrails, the host becomes the security boundary, and that boundary is usually weaker than teams assume. In practice, many security teams discover this only after a dependency has already accessed secrets, rather than through intentional package review.

How It Works in Practice

Python imports are executable. A malicious or compromised package can place code in module scope, in PyPI Breach style supply chain incidents, or in transitive dependencies that run as soon as a module is imported. That code may scan environment variables, read files, contact remote endpoints, or establish persistence before the main application logic starts.

From a defensive perspective, the question is not whether import-time code can run. It can. The real issue is what is already available to it. Secrets exposed through environment variables, service account tokens on disk, cloud instance metadata, SSH keys, and CI/CD injected credentials are all reachable if they are present when import occurs. This is why guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant: access control, configuration management, and auditability only help if the execution surface is already constrained.

• Minimise secret presence before dependency import, especially in startup code.
• Run package vetting, pinning, and hash verification before installation reaches production.
• Separate build-time, test-time, and runtime credentials so import code cannot reuse privileged material.
• Prefer ephemeral tokens and scoped workload identities over long-lived secrets on the host.
• Monitor import chains, not just final application endpoints, because compromise often starts earlier.

For practitioners, the best mental model is that import-time execution turns package loading into an untrusted bootstrap phase. These controls tend to break down in CI runners, notebook environments, and shared deployment hosts because secrets are commonly preloaded before the first import executes.

Common Variations and Edge Cases

Tighter package controls often increase delivery overhead, requiring organisations to balance supply chain assurance against developer velocity. That tradeoff becomes sharper in environments that rely on rapid plugin loading, dynamic module discovery, or AI toolchains that pull dependencies at runtime.

Not every import-time action is malicious. Some libraries legitimately initialize telemetry, register plugins, or detect platform features during import, and current guidance suggests treating that behaviour as a risk signal rather than a breach by default. The key distinction is whether the code needs to execute before trust is established. If it does, the package is operating inside a sensitive bootstrap window.

There is no universal standard for when import-time side effects are acceptable, but mature teams increasingly treat them as an exception. This is especially important for containers, serverless functions, and notebook-based workflows where secrets, metadata services, and network paths may be available immediately after process start. Stronger controls include pre-import sandboxing, dependency allowlisting, and stripping startup environments down to the minimum required for execution. That approach also aligns with the broader NHI governance perspective in the Ultimate Guide to NHI Management, where reducing standing access is central to limiting blast radius.

Import-time execution breaks down most dangerously in multi-tenant build systems and ephemeral workloads that inherit broad credentials from their parent process because the malicious code gets a brief but highly privileged window.

Related resources from NHI Mgmt Group

• What breaks when a compromised Python package can run code at interpreter startup?
• What breaks when a compromised package can run code during install or import?
• What breaks when package installation can execute code before review?
• What breaks when malicious code can run inside a developer IDE or package install?