A build can use packages from both a public registry and an internal registry. The package manager's resolution rules determine which source supplies each name. If those rules are ambiguous, an internal dependency may be resolved from a location the organization did not intend.
The review starts with the actual installation configuration used by developers, CI, and release jobs. A rule present on one engineer's laptop does not establish the behavior of every build environment.
Scope and registry are separate properties
npm supports associating a package scope with a registry through its configuration. Authentication entries also need appropriate registry scoping so credentials are sent to the intended service. npm's configuration documentation explains these mechanisms.
An illustrative company publishes internal libraries under a dedicated scope. Its CI configuration routes that scope to the company registry. The review can inspect the effective configuration and lockfile URLs to verify that the intended packages resolve from that registry.
Check behavior when the private source is unavailable
An installation failure can be safer and more explainable than silently obtaining a similarly named package from another source. The intended behavior needs to be explicit. Caching may obscure the result because an install can succeed without contacting the registry at all.
Use a clean, isolated test environment to exercise a missing internal package and an unavailable internal registry. Observe the requested destinations and failure result. Do not publish lookalike packages to public registries as a test; controlled local registries can reproduce the resolution question without affecting other users.
Review configuration precedence
Package managers can read project, user, environment, and command-line settings. The effective value may differ from the file a reviewer first opens. Record which settings are present in the release environment and how secrets are injected without including their values in the report.
Also inspect direct archive URLs and Git dependencies, which may bypass ordinary registry selection. A policy covering scoped registry packages does not automatically cover every source type allowed by the manifest.
Connect resolution to the released artifact
Retain the reviewed dependency state and verify that release jobs use it. Compare a representative developer install with CI, then account for intended differences. This can identify cases where an internal package works locally because of a personal registry setting that is missing in automation.
The resulting evidence explains where the organization's dependencies come from and how unexpected sources are rejected. It can support a remediation such as correcting scope routing or removing an unintended fallback. It does not establish that packages from the approved registry are inherently safe; publisher permissions, package review, and credential handling remain separate controls.
Sources
OWASP: NPM Security. The company scope and registry-failure tests are illustrative.
