Many SCA trials use only public packages, then fail in production on private ones. Test early: include an internal package, a package from a private registry and a name that also exists publicly. Check that the tool resolves them correctly, does not leak names unnecessarily, and does not report false matches.
The problem
Most companies depend on code that is not on a public registry: shared internal libraries, forks, vendored packages. A tool that only knows public packages has three possible reactions. It ignores them, which leaves a blind spot. It reports them as unknown, which is noise. Or worse, it matches the name to an unrelated public package and reports its vulnerabilities, which is wrong.
Cases to include in a trial
- An internal package with a unique name. Expect it to appear in the inventory as internal, with no public advisories matched.
- A package from a private registry that mirrors public ones. Check the version it records and the source.
- A name collision. Add an internal package whose name also exists on a public registry. See whether the tool matches the wrong one.
- A forked package. Your fork has changed code. Does the tool treat it as the upstream version, and does it say so?
- Authentication. Does the scanner need registry credentials to resolve the tree, how are they stored, and can they be scoped read-only?
Privacy and exposure
Ask what is sent out during analysis. If the tool queries a service with your package names, internal names go with it. For some teams that is fine. For others, internal names are sensitive. Find out whether names are sent, whether it can run locally and what that changes.
This also ties to a security question beyond the tool. An internal package name that is not registered publicly can be claimed by an attacker, which tricks a build into fetching the public one. A good scanner or policy can flag names that exist both internally and publicly. Ask whether the tool can.
Handling the results
You need a way to mark something as internal and exclude it from public matching, with the decision recorded. You also want a way to attach your own advisories, because vulnerabilities in your internal libraries matter as much as public ones. Check whether you can add them and have findings appear alongside public ones.
Failure behavior
Remove the registry credentials and rerun. Does the scan fail loudly, or does it complete with a shorter list and no warning? Silent shortening is the failure you least want.
Try it yourself
Open the demo and look at how packages and sources are shown in the inventory. Consider how an internal package would appear there.
Click through it at your own pace, or open it full screen.
Where Safeguard fits: Safeguard provides SBOM and dependency scanning, and the free scan at gold.safeguard.sh/scan is a way to see how your own dependency tree is read.
Quick check
What is a dependency confusion risk?
It is when a build fetches a public package that shares a name with an internal one. Registering names and configuring registries carefully reduces it.
Last reviewed: 19 October 2026.
