Phantom Dependency

A phantom dependency is a package added to a software supply chain for its side effects rather than for direct use by the application. It can remain invisible in normal code paths while still executing during installation, which makes package metadata and lifecycle scripts part of the attack surface.

Expanded Definition

A phantom dependency is a package included in a build or deployment pipeline for side effects, not because the application directly imports or calls it. In NHI and software supply chain contexts, that distinction matters because the package may still execute install-time logic, alter the environment, or influence downstream tooling without appearing in ordinary runtime traces.

Definitions vary across vendors on whether the term should cover optional dependencies, transitive packages, or only packages with explicit lifecycle scripts. NHI Management Group treats the term narrowly: the risk is not the dependency graph itself, but the hidden execution path created when package metadata, install hooks, or post-install actions run outside developer expectation. This is adjacent to supply chain integrity, but it is not the same as package spoofing or typosquatting. For governance, it should be reviewed alongside NIST Cybersecurity Framework 2.0 software supply chain practices and internal controls over build-time execution.

The most common misapplication is treating a phantom dependency as a benign unused package, which occurs when teams only scan import statements and ignore lifecycle scripts, installer permissions, and CI/CD execution context.

Examples and Use Cases

Implementing controls for phantom dependencies rigorously often introduces build friction, requiring organisations to weigh developer convenience against the security value of reducing hidden execution paths.

• A package is added solely because its installer writes configuration files needed by another tool, even though no application module imports it.
• A CI pipeline pulls in a dependency that runs a post-install script to fetch binaries, creating an execution path that security review never sees in source code.
• An agentic workflow uses a library for packaging-time transformation only, so the dependency affects release artifacts but not runtime logic.
• A compromised install hook in a seemingly unused package can modify environment variables or drop a backdoor during container image creation, similar to patterns seen in the LiteLLM PyPI package breach.
• Teams applying dependency allowlisting may discover that a hidden installer action breaks the build, prompting a review of whether the package should exist at all.

These cases are often evaluated with supply chain guidance from the NIST Cybersecurity Framework 2.0, but no single standard yet defines exactly how to classify every side-effect-only package.

Why It Matters in NHI Security

Phantom dependencies matter because NHI environments increasingly depend on software pipelines that move secrets, tokens, certificates, and service credentials through automation. If a hidden install path can execute during build or deployment, it can expose secrets, alter trust boundaries, or introduce code that later gains access to privileged service accounts. That is especially dangerous in environments already struggling with visibility: NHI Management Group reports that only 5.7% of organisations have full visibility into their service accounts, and 96% store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools.

For NHI governance, the term is a signal to inspect build agents, package managers, and artifact generation steps as identity-adjacent control points. It also connects to lifecycle discipline, because a dependency that exists only for side effects is easy to forget during offboarding, rotation, or incident response. Organisations typically encounter the consequence only after a build compromise, supply chain alert, or unexplained secret exposure, at which point phantom dependency review becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does a dependency compromise become an identity incident?
• How should teams slow down malicious dependency updates without breaking delivery?
• What is the difference between automating dependency updates and granting them blind trust?
• Should organisations allow pull_request_target for automated dependency workflows?