Treat any host that loaded the affected package as potentially compromised, even if it only ran tests or a CI job. The first actions are to inventory where the package landed, remove or pin the affected versions, and rotate all reachable credentials. Then clean the runtime artifacts, review outbound connections, and check whether any publish tokens were abused.
What changes when a package runs at import time instead of install time?
A package that executes on import has crossed from passive dependency into active runtime code. That means the first load, including tests, build jobs, notebooks, and CI tasks, can trigger the same trust and exposure issues you would treat as an endpoint or pipeline compromise. In AI tooling supply chains, that shift matters because import happens earlier, more often, and in more places than install.
The practical difference is timing and blast radius. Install-time abuse usually depends on a packaging event, while import-time abuse can wait until a developer, runner, or agent simply references the module. That creates a broader set of reachable systems, more chances to touch credentials or network resources, and a harder forensic problem because the malicious action may look like ordinary program startup.
This is why responders should treat the execution event as a compromise indicator, not just a bad dependency behavior. A package that runs on import can read environment variables, reach outbound services, alter local state, or seed later persistence before any explicit application logic starts. In AI builds, that can affect code generation tools, eval harnesses, agent runtimes, and even disposable CI environments if they expose tokens or cached secrets.
How should teams contain the blast radius fast?
Start by inventorying every place the affected package landed, then remove or pin the bad version wherever it appears. If the package loaded anywhere with reachable credentials, assume those secrets may be exposed and rotate them before you spend time proving abuse. That includes publish tokens, CI tokens, API keys, and any credentials that the process could read from the environment or filesystem.
Containment should also include cleaning the runtime artifacts that the import may have touched. Wipe temporary workspaces, caches, local build outputs, and any generated files that could preserve malware, tokens, or altered configuration. For AI tooling pipelines, also check whether the package executed inside reusable runners, shared notebooks, or agent workspaces that may have left behind context for the next job.
Review outbound connections from the affected host or pipeline step, because import-time execution often uses the first few seconds to beacon, exfiltrate, or fetch a second stage. If the package had access to a package registry, git remote, artifact store, or model hub, validate whether any publish or deployment action occurred from that environment. The question is not only what loaded, but what that runtime could reach before anyone noticed.
How do you decide whether it became a supply-chain incident?
The deciding factor is whether the package execution had a path to material trust assets, not whether the host “looked infected.” If the code ran in a context with secrets, signing material, registry access, or deployment permissions, treat the event as a supply-chain compromise until proven otherwise. A benign-seeming test job can still become the source of token theft, malicious publication, or follow-on tampering.
That is why package behavior needs to be tied to identity, credential, and publishing reach. A package that runs on import is especially dangerous when it can inherit the privileges of a developer shell, CI runner, or agent session. The same behavior on an isolated analysis box is a smaller event than the same behavior inside a build workflow that can mint artifacts or push to a registry.
Teams should also distinguish cleanup from assurance. Removing the package does not answer whether secrets left the environment, whether published artifacts were altered, or whether downstream consumers pulled a compromised release. For AI tooling, the follow-up often includes checking whether model prompts, agent instructions, or tool configurations were modified in ways that could affect later runs.
Risk and Threat Considerations
An import-time payload can execute before the operator expects any meaningful work to begin, which makes it attractive for secret theft, registry abuse, and quiet persistence. In supply-chain cases, the fastest path is often not code execution in production, but theft of credentials from the environments where packages are tested, built, or published.
Failure mechanism: The package uses import-side effects to read environment variables, access local files, or make outbound calls before defenders treat the session as suspicious, then abuses any reachable tokens or artifacts.
Impact: Attackers may gain reusable credentials, poison later builds, publish malicious updates, or widen compromise from one host to an entire dependency or release pipeline.
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 addresses the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Import-time code can read and exfiltrate exposed secrets from CI or dev runtimes. |
| NHI-05 — Overprivileged NHI | Package execution becomes more dangerous when runtime credentials can publish or deploy. | |
| NHI-07 — Long-Lived Secrets | Long-lived CI or publish tokens expand the blast radius of import-side execution. | |
| Recommendation — Rotate exposed secrets immediately and scope the search to all environments that loaded the package. Reduce package-runtime privileges so imported code cannot reach publish or deployment paths. Replace long-lived tokens with short-lived credentials and rotate any token reachable from the runtime. | ||
| SLSA | Supply-chain integrity | The issue is a dependency supply-chain compromise affecting build and publish trust. |
| Recommendation — Verify provenance and block affected artifacts until you can trust the dependency chain again. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Import-time package execution is a malicious-code exposure in build and runtime environments. |
| Recommendation — Scan, quarantine, and remove the affected package from every environment that loaded it. | ||
Practitioner Guidance
What to prioritize: Treat the first hour as a containment-and-credential problem, not a code-quality review. If the package executed in CI, a notebook, or an agent workspace, rotate the reachable credentials first and assess blast radius before chasing full behavioral details.
What to verify: Confirm where the package was imported, what secrets were present in that runtime, and whether any registry, repo, or artifact write action was possible from the same context. If you cannot prove the environment was isolated from publish or deploy paths, assume the exposure was material.
What good looks like: The affected version is blocked, reachable secrets are rotated, outbound activity is reviewed, and all downstream consumers are checked for contamination. The response is complete only when you can show that the import event could no longer be used to repeat the same compromise path.
Practitioner takeaway: Import-time execution collapses the boundary between “using a dependency” and “running untrusted code,” so the safe response is to contain the environment as if it were already part of the incident.
Related resources from NHI Mgmt Group
- How should security teams respond when a trusted JavaScript SDK only steals secrets at runtime instead of during install?
- How should security teams respond when a widely used package is compromised and executes malware at import time?
- How should security teams contain a supply-chain worm that executes during package preinstall phases?
- How should security teams detect trojanized npm packages that execute at import time instead of during install?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
