An indirect import is a code-loading pattern where a package pulls in functionality through another module rather than calling it directly. Attackers use this to obscure the real execution path and hide malicious behaviour inside otherwise ordinary dependency chains. It makes static analysis harder because the dangerous action is separated from the visible entry point.
How Indirect Import Works
Indirect import is a dependency-loading pattern, not a separate execution engine. A package reaches functionality through an intermediary module, wrapper, or transitive dependency, which means the visible entry point can look benign while the real logic arrives later in the chain.
This matters because software review tools often reason from direct calls, explicit imports, and obvious package names. When execution is routed through another module, the trust decision shifts from the top-level file to the entire dependency path, including what is fetched, bundled, or resolved at install time.
Why Attackers Use It
Attackers value indirect import because it helps them hide malicious behaviour inside ordinary-looking dependency relationships. The code that performs the harmful action may not appear in the first file a reviewer opens, and it may be several steps removed from the package that an application developer intentionally imported.
That separation can make malicious code harder to spot in code review, static analysis, and dependency auditing. It also creates room for dependency confusion, typosquatting-style placement, or compromised transitive packages to blend into a legitimate build path before the payload is reached.
Security Implications
Indirect import changes the inspection problem from “what does this module do?” to “what does the full resolution chain do?” Reviewers need to understand the provenance of each module in the chain, the conditions under which it executes, and whether a seemingly harmless helper can trigger privileged or sensitive behaviour downstream.
For supply-chain security, the key issue is trust propagation. A single imported package can drag in nested dependencies, and each additional hop expands the attack surface for tampering, malicious updates, hidden executables, or unexpected runtime side effects. This is why dependency graphs and provenance checks matter as much as line-by-line code review.
When imports are indirect, the most important security question is whether the loaded component is constrained to the intended function or can reach filesystem access, network access, code execution, or sensitive configuration. If those capabilities are reachable through an unvetted intermediary, the import path itself becomes part of the risk.
What To Review In Practice
Practitioners should treat indirect import as a cue to inspect the full dependency tree, not just the package named in source code. A useful review asks whether each intermediary module is expected, maintained, pinned, and traceable to a trusted source, and whether its behaviour changes between install time and runtime.
Pay particular attention to transitive packages that are small, obscure, newly published, or outside the normal ownership path of the application. Those are common places for hidden functionality to enter a build unnoticed, especially when the direct import looks routine and the dangerous code sits behind an abstraction layer.
Where supply-chain controls already exist, SLSA helps frame the provenance and integrity side of the problem, while OWASP API Security Top 10 is useful when indirect imports expose API-driven paths that need authorization scrutiny. For broader build and dependency governance, NIST Cybersecurity Framework 2.0 provides a practical governance lens.
Risk and Threat Considerations
Indirect import is attractive to attackers because it can conceal malicious logic in a dependency chain that defenders may not trace completely. The risk is highest when organisations trust package names, module boundaries, or direct imports more than the resolved code that actually executes.
Failure mechanism: A hidden or compromised intermediary module introduces unexpected code paths, and the payload executes after normal dependency resolution or build-time trust checks have already passed.
Impact: This can produce stealthy code execution, poisoned builds, data exposure, or supply-chain compromise that is difficult to attribute quickly because the visible source file is not the real execution source.
Where indirect imports are used to mask malicious behaviour in package ecosystems, defenders should assume that static review alone is insufficient unless it is paired with provenance validation, lockfile discipline, and dependency inspection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 16 — Application Software Security | Indirect import is a software supply-chain and code-review problem. |
| CIS Control 2 — Inventory and Control of Software Assets | Managing indirect imports depends on knowing what software is actually present. | |
| Recommendation — Inspect dependency chains and verify imported code before release. Maintain an accurate software inventory and remove unapproved dependencies. | ||
| NIST CSF 2.0 | ID.SC-3 — Supply Chain Risk Management | Indirect imports alter trust in third-party and transitive software dependencies. |
| PR.DS-6 — Data Integrity is Protected | Hidden dependency paths can tamper with code integrity during delivery. | |
| Recommendation — Assess supplier and dependency provenance before accepting imported code. Verify build artifacts and dependency integrity before deployment. | ||
| OWASP Agentic AI Top 10 | A2 — Supply Chain Attacks | The term describes hidden execution through dependency chains, a supply-chain abuse pattern. |
| Recommendation — Trace transitive dependencies and block untrusted code paths before runtime. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | Attackers use dependency chains to hide malicious code before execution. |
| Recommendation — Map suspicious dependency insertion to T1195 and hunt for compromised packages. | ||
Related resources from NHI Mgmt Group
- How should security teams reduce indirect prompt injection risk in AI systems?
- When does indirect prompt injection become a business risk rather than a technical curiosity?
- Why do indirect prompt injections matter for IAM and NHI governance?
- Why is indirect prompt injection harder to defend than XSS?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
