What breaks when a trusted SDK can execute on import?

Why This Matters for Security Teams

Import-time execution changes the trust model for software supply chains. A package can behave like a normal dependency during review, then execute code as soon as it is imported, before application-level policy, logging, or runtime guards have a chance to intervene. That makes this a governance issue as much as a code-quality issue, because approval based only on provenance or version pinning can miss the first malicious action.

Security teams often focus on whether a library is signed, scanned, or popular, but those signals do not answer the more important question: what happens before the first explicit function call. Current guidance suggests reviewing initialization paths, top-level module code, transitive install hooks, and any automatic network or file-system activity. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to connect software acquisition controls with continuous monitoring and incident response, rather than treating dependency approval as a one-time event.

In practice, many security teams encounter import-time abuse only after a trusted package has already been pulled into production and the first suspicious outbound request has already occurred.

How It Works in Practice

In a healthy design, importing a module should define symbols and expose functions, not perform privileged work. Import-time execution breaks that expectation by allowing code to run during dependency loading, interpreter startup, plugin discovery, or framework registration. That can include reading environment variables, exfiltrating secrets, altering configuration, spawning subprocesses, or weakening later checks by tampering with runtime state.

Practical review needs to go beyond package metadata. Teams should inspect top-level statements, setup and build hooks, dynamic import chains, and any code executed as part of object construction or registration. The OWASP Top 10 for Large Language Model Applications is not a direct fit for every SDK issue, but its emphasis on unsafe tool invocation and supply chain assumptions is helpful when a library is trusted to mediate sensitive actions. For broader software assurance, the Secure Software Development Framework reinforces that dependencies must be assessed as executable components, not just named artefacts.

• Inventory packages that execute code on import, install, or plugin registration.
• Review top-level module statements for network, filesystem, and credential access.
• Block or alert on unexpected process creation, external calls, and config mutation during startup.
• Test in a sandbox that traces import-side effects before promoting the SDK.
• Require a change review when a package adds new initialization logic, even if the API is unchanged.

For environments with agents or automation workers, the risk is higher because import-time execution may occur before the agent identity, tool permissions, or secret scoping controls are fully established. These controls tend to break down when a framework performs eager plugin loading at application start because the code executes before the platform has established any meaningful runtime boundary.

Common Variations and Edge Cases

Tighter dependency control often increases review overhead, requiring organisations to balance developer speed against the need to inspect executable startup behavior. There is no universal standard for exactly how much initialization logic is acceptable, so best practice is evolving toward risk-based approval for packages that touch secrets, identity flows, or outbound connectivity. The MITRE ATLAS knowledge base is useful when the import-time action resembles an adversarial technique such as credential access, persistence, or command execution.

Edge cases matter. Some SDKs legitimately perform environment detection, telemetry registration, certificate loading, or plugin discovery during import. That does not make them malicious, but it does mean the trust boundary is narrower than many teams assume. For AI-enabled applications, this becomes more sensitive when the SDK also mediates model prompts, tool calls, or retrieval pipelines, because an import-time action can alter guardrails before a large language model ever receives input. Emerging practice is to treat these packages as high-risk when they run in build systems, serverless cold starts, CI pipelines, or automated agent runtimes.

Where the package is used in regulated or high-trust environments, teams should pair static review with controlled execution testing and runtime monitoring. If import-time behavior cannot be explained, contained, and monitored, it should not be treated as a routine dependency.

Related resources from NHI Mgmt Group

• What breaks when a trusted AI package can execute code on import?
• What breaks when a malicious dependency can execute on import in a build or ML pipeline?
• What breaks when an SDK generator is a black box?
• What breaks when remote access is trusted because it looks familiar?