A scanner can cover private registries only if it can authenticate to them, resolve internal package versions, and avoid matching them against public packages that share a name. Ask vendors how credentials are stored, what happens to unresolved packages, and how they prevent name confusion.
Why this matters
Most companies publish some code only inside their own network: shared libraries, internal SDKs, build plugins. They are hosted on a private registry or artifact repository. If the scanner cannot reach it, one of two things happens. The packages are silently skipped, which hides risk, or they are treated as unknown and flagged noisily. Neither is acceptable at scale.
Three problems to probe
Access. The scanner needs read access to resolve versions. Ask whether it uses a stored credential, a token from your CI, or runs inside your network so nothing is shared. Prefer scoped, read-only, expiring credentials.
Matching. An internal package named like a public one is a classic trap. The scanner may attach a public advisory to your private code, which produces a false alert, or worse, ignore a real issue. This ties to dependency confusion, where an attacker publishes a public package with your internal name. Our post on dependency confusion and private registries explains the attack.
Visibility. Even if resolution works, ask whether internal packages appear in the inventory with their own versions and owners, so a vulnerability inside one of them is traceable to every consumer.
Questions to ask
| Question | Good sign |
|---|---|
| Which registry types can be reached? | Named list and documented setup |
| How are credentials held? | Encrypted, scoped, rotatable, or never leave your network |
| What is reported when a package cannot be resolved? | Explicit "unresolved" entry, not silence |
| How are internal names protected from public matching? | Namespace or source aware matching |
| Do internal packages appear in the SBOM? | Yes, with origin noted |
| Can internal packages carry their own advisories? | Yes, so your teams can warn each other |
Steps to test
- Choose a repository that depends on at least two internal packages.
- Scan with the registry connection disabled and note the output. You want a clear warning.
- Enable the connection using a read-only token and rescan.
- Compare the dependency counts with your package manager.
- Rename a test internal package to match a public one and see whether the scanner mislabels it.
Step 2 is the most revealing. A good tool tells you what it could not see. A weak one reports a clean result.
Do not forget the SBOM
If you share SBOMs with customers, decide how internal package names are handled before they leave the building. See redacting an SBOM before sharing it.
Quick check
Do private packages need vulnerability scanning?
Yes. Internal code has bugs too, and every project that consumes it inherits them.
Is it safe to give a scanner registry credentials?
It can be, with read-only, scoped and rotated tokens. Ask how they are stored and who can retrieve them.
Safeguard offers SBOM and dependency scanning and asset discovery. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
