Load-time execution occurs when code runs after a package is imported or required during normal application use, not during installation. This matters because install-time controls do not block it. Malicious logic can remain dormant until the application loads the poisoned module, making detection harder and reducing the value of script-blocking alone.
Expanded Definition
Load-time execution is a software supply chain and application security issue in which code executes when a module is imported, required, or otherwise loaded into a running process. It is distinct from install-time execution, which happens during package installation, and from runtime exploitation that depends on a later user action. The security significance is that a package can appear harmless during build or install checks, then activate only when the application actually loads it in production.
Definitions vary across vendors and platforms because different ecosystems use different loading mechanisms, but the core concern is consistent: code that runs automatically at load time can bypass controls that only inspect installation events. This is especially relevant in modern dependency-heavy systems, where transitive packages, plugin frameworks, and dynamic imports create large trust surfaces. For security teams, the key question is not just whether a package is signed or scanned, but whether it contains hidden behavior that triggers as soon as the application resolves the module. The most common misapplication is treating install-time scanning as sufficient, which occurs when organisations assume a clean installation means the package is safe at load time.
Examples and Use Cases
Implementing load-time inspection rigorously often introduces compatibility and performance constraints, requiring organisations to weigh stronger supply chain detection against slower build pipelines and deeper dependency analysis.
- A Node.js package runs an import-side effect that sends telemetry or downloads a second-stage payload the moment the module is required.
- A Python dependency executes code in package initialisation, so a malicious helper activates only when the application imports the library during startup.
- A plugin-based service loads third-party extensions on demand, and one compromised extension performs unauthorised file access as soon as the host resolves it.
- A build system validates package contents at install time, but a poisoned dependency stays dormant until production traffic triggers the application path that loads it.
- Security engineers compare this behaviour with supply chain guidance in the NIST Cybersecurity Framework 2.0 to prioritise software integrity and anomaly detection across the full lifecycle.
These cases are common in ecosystems that support dynamic import hooks, package initialisers, or auto-loading configuration files, because the execution boundary is tied to application loading rather than installation. In practice, load-time execution can be accidental, benign, or malicious, which is why context matters and why no single standard governs the term uniformly across every language runtime.
Why It Matters for Security Teams
Load-time execution matters because it changes where defenders must look for malicious or unexpected behaviour. If teams only monitor installation events, they can miss the moment code becomes active in memory, where it can steal secrets, alter application logic, or establish persistence. That is particularly important for NHI-adjacent systems, because service accounts, API keys, and tokens often sit in the same process space that loads third-party modules. A poisoned dependency may therefore expose credentials or influence automation without ever touching a traditional interactive login path.
This concept also aligns with broader software assurance practices in NIST Cybersecurity Framework 2.0, especially where organisations need to manage software integrity, detect anomalous code behaviour, and verify trusted dependencies before they are executed in production. Teams should pair package vetting with runtime monitoring, dependency pinning, and controls that observe module loading rather than relying on script-blocking alone. Organisations typically encounter the operational impact only after a compromised package has already been imported in a live system, at which point load-time execution becomes an operationally unavoidable incident response concern.
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 surface, NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | CSF addresses software integrity and protection of code from unauthorized modification. |
| OWASP Non-Human Identity Top 10 | NHI guidance covers executable dependencies that can activate when loaded by automation. | |
| NIST AI RMF | AI RMF applies when model or agent code is triggered through load-time hooks or plugins. | |
| NIST SP 800-53 Rev 5 | SI-7 | Integrity controls help detect unauthorized code that becomes active at load time. |
| ISO/IEC 27001:2022 | ISO 27001 supports secure software acquisition and change control for loaded dependencies. |
Treat loaded modules as privileged execution surfaces and verify their identity and behavior.
Related resources from NHI Mgmt Group
- Who is accountable when a critical platform flaw affects identity and code execution at the same time?
- What do security teams get wrong about hardening only install-time package execution?
- How should security teams handle package install-time execution in CI environments?
- What breaks when a malicious package executes at module load time?
