Give the scanner a dedicated read only account scoped to the internal registries it needs, store the credential in your secrets manager, and test what the scanner reports when access fails. Without access, internal packages and inherited parent versions show up as unresolved.
Why the scanner needs access at all
Legacy monorepos rarely depend only on public packages. They pull internal libraries, company wide parent POMs and mirrored copies of public ones. When a scanner cannot reach these, it cannot read versions or transitive dependencies of internal packages, and the report has holes labelled as unknown.
For Maven projects, a parent POM that lives in an internal repository is a typical case: the module inherits its dependency versions from it. If the scanner cannot fetch it, inherited versions are missing.
Set up access safely
- Create a service account used only by scanning. Do not reuse a developer or build account.
- Grant read access only, on the specific repositories required. Deny publish.
- Use a short lived token or a credential with an expiry, rotated on a schedule.
- Store it in the secrets manager your CI already uses, never in the repository or the scanner config file.
- Log use of the account and review the log after the first week.
- Name an owner for rotation, in writing.
What failure looks like
| Symptom | Likely cause |
|---|---|
| Many components marked unknown | Credential missing or expired |
| Scan passes locally, fails in CI | CI runner cannot reach the internal host |
| Only internal packages missing | Token lacks permission on that repository |
| Intermittent gaps | Registry rate limits or flaky network |
Test failure on purpose during the pilot. Revoke the credential on a test branch and see what the scanner reports. A quiet pass with missing data is worse than a loud failure, so find out which one you have.
Fail closed or open
Decide, per directory, what should happen when resolution fails. For services you gate on, failing the check is safer than passing with unknown data. For report only areas, a warning is enough. Write the rule down so it is not argued in the middle of an incident.
Mirrors and air gaps
Some organizations route all package downloads through a mirror. Point the scanner at the same mirror so it sees what builds see. If the environment has no outbound access, check whether the scanner can work from lockfiles and a local advisory feed, and accept lower freshness in return.
Treat the credential as part of your attack surface
An account that can read every internal package is a target. Limit what it can see, alert on use from unexpected addresses and avoid granting it access to registries that hold unreleased code.
Where Safeguard fits
Safeguard's CLI (1.4.0) can run inside your environment, so registry credentials can stay where they already live. A free scan on a small public project at https://gold.safeguard.sh/scan shows the output format before you wire in private access.
Quick check
Can we skip private registry access for the pilot?
Yes, if you label the results as incomplete. Plan to add access before you gate anything.
Should the scanner account be able to publish?
No. Scanning needs read access only.
Sources
Last reviewed: 19 October 2026.
