What are the signs that dependency confusion exposure is present in an organisation?

How dependency confusion shows up in the build and dependency stack

Signs usually appear first in package resolution behavior, not in the code itself. Watch for dependency manifests that refer to internal package names with no registry restriction, package managers configured to search public registries automatically, and build pipelines that do not pin or verify the source of each dependency. Those conditions make it possible for a public package with the same name to win resolution.

A mature environment also leaves clear provenance traces. You should be able to tell which registry supplied each package, whether the package name is reserved internally, and whether the build is deterministic enough to produce the same dependency set on every run. If that evidence is missing, exposure is often already present even before any malicious package is observed.

When reviewing a build system, the most telling pattern is ambiguity. Internal packages that are not namespace-protected, repository rules that allow fallback to public sources, or CI jobs that install dependencies without an allowlist are all indicators that the organisation is depending on naming conventions rather than explicit trust boundaries.

What operational control gaps usually accompany the exposure

dependency confusion rarely exists alone. It is commonly paired with weak dependency governance, such as inconsistent code review for dependency changes, limited ownership of package namespaces, and incomplete inventory of what the organisation actually publishes internally. Those gaps matter because the attack succeeds when the organisation cannot distinguish an intended internal package from a lookalike public one.

Another common sign is that controls vary by team. One product may lock to an internal registry while another uses default package manager behavior, or one pipeline may verify package source while another accepts whatever is first in the resolver path. That inconsistency creates uneven blast radius and makes the exposure hard to spot through policy alone.

High-risk environments also tend to over-rely on developer memory. If teams have to remember which package names are private, or manually check whether a dependency came from the right source, then the environment has already turned a supply-chain control into a human process. That is usually a sign the exposure is systemic, not isolated.

What evidence confirms the organisation is materially exposed

The strongest confirmation is a reproducible path from dependency name to package source. If an internal build can fetch a package from a public registry because the same name is not reserved or the resolver prefers public sources, the exposure is real, not theoretical. A similar signal is an internal package catalogue that does not match what CI systems actually install.

Look for build logs, resolver output, package lockfiles, and registry settings that disagree with one another. If the lockfile names a dependency but the build cannot prove where it came from, or if multiple pipelines resolve the same package differently, then the organisation lacks the source assurance needed to resist dependency confusion.

At the governance level, the absence of namespace reservation, source verification, and registry policy enforcement is itself evidence. The issue is not only whether an attacker has already published a matching package. It is whether the organisation has made it technically impossible for such a package to be selected during a normal build.

Risk and Threat Considerations

Dependency confusion exposure creates a direct supply-chain compromise path. An attacker who publishes a package name that matches an internal dependency can win package resolution, inject malicious code into the build, and gain access to secrets, build credentials, or downstream deployment paths.

Failure mechanism: Package managers that search public registries by default, combined with unreserved internal names and weak source verification, allow an external package to be selected in place of the intended internal one.

Impact: The result can be code execution in CI, credential theft, poisoned artifacts, and propagation of malicious code into production systems or dependent teams.

Practitioner Guidance

What to verify: Confirm that every internal package name is reserved, every build source is explicit, and every pipeline can prove which registry supplied each dependency. If you cannot produce that evidence quickly, treat the environment as exposed rather than merely untidy.

What to prioritise: Start with the packages that are both internal and high-impact, especially anything used in shared build templates or release pipelines. Those are the dependencies where a naming conflict can affect the widest set of systems.

Practitioner takeaway: Dependency confusion is present when package resolution is allowed to rely on trust by naming convention; the control objective is deterministic provenance, not just good dependency hygiene.

Related resources from NHI Mgmt Group

• What are the signs that dependency poisoning campaigns are targeting an organisation's software supply chain?
• What are the signs that a manufacturing organisation has shadow OT or hidden exposure in its industrial environment?
• What are the signs that an organisation is handling cyber exposure poorly?
• What are the signs that NTLM is creating hidden exposure in an organisation?