Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
Expanded Definition
Import-time execution is a Python behaviour where module-level statements run as soon as the module is imported, not when an explicit function call is made. In NHI security reviews, that matters because an import can silently trigger secret reads, network requests, logging setup, client initialisation, or persistence before the application has reached an approved operating state.
Security teams should treat import-time execution as part of the trust boundary, not as harmless setup code. Definitions vary across vendors when the same pattern appears in plug-ins, package installers, or framework hooks, but the core risk is consistent: code paths execute before an operator expects them to. That makes it especially relevant to Python services that load configuration, credentials, or cloud SDKs during startup. The NIST NIST Cybersecurity Framework 2.0 reinforces the need to control software supply chain behaviour and reduce unexpected execution in operational environments.
The most common misapplication is assuming that “imported equals safe,” which occurs when reviewers scan only callable functions and miss module-level side effects.
Examples and Use Cases
Implementing controls for import-time execution rigorously often introduces startup constraints, requiring organisations to weigh developer convenience against stronger change control and blast-radius reduction.
- A package import reads cloud credentials from environment variables and creates a client immediately, which can expose secrets before runtime policy checks are applied.
- A plug-in executes a network call during import to fetch configuration, turning a simple dependency load into an external trust dependency.
- A security library registers handlers and writes audit records on import, which can alter logs even in test or diagnostic contexts.
- A repository’s module import initialises persistence connections, creating side effects that complicate sandboxing and incident triage.
- During code review, teams compare module-level code against the guidance in the Ultimate Guide to NHIs and check whether startup code is touching secrets or service accounts before the application is authorised to run.
One useful lens comes from Python ecosystem guidance and supply chain analysis: any import path that can reach secrets, HTTP calls, or filesystem writes should be treated like executable policy, not just library plumbing.
Why It Matters in NHI Security
Import-time execution becomes an NHI problem when service accounts, API keys, tokens, or certificates are accessed before the system’s intended identity controls are active. That creates hidden credential exposure, makes code reviews incomplete, and can break assumptions about when a workload is actually authenticated. In practice, module-level behaviour can also defeat Zero Trust sequencing because trust decisions are bypassed before the application reaches a verified state. This is one reason NHI Mgmt Group highlights that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, while 79% have experienced secrets leaks, with 77% resulting in tangible damage, according to the Ultimate Guide to NHIs.
For governance teams, the key issue is not whether import-time execution exists, but whether it can activate privileged behaviour without an explicit approval point. That is why secure software review should inspect module bodies, dependency loaders, and framework bootstrap paths alongside secrets handling and identity provisioning. Organisationally, this concern often remains invisible until a package upgrade, incident replay, or credential leak shows that code executed before monitoring, policy enforcement, or runtime controls were in place. Organisations typically encounter the blast radius only after a package import triggers secret use or outbound access, at which point import-time execution 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 Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Import-time code can expose secrets or trigger secret use before runtime controls. |
| NIST CSF 2.0 | PR.DS | Unexpected import behaviour can expose data and weaken software integrity. |
| NIST Zero Trust (SP 800-207) | Import-time execution can bypass intended trust checks before workload verification. |
Require explicit identity and policy validation before any code path can access secrets or network resources.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
