A dependency scanner may send only a list of package names and versions, or it may upload manifests, lockfiles or source code. Ask the vendor exactly which, then verify by watching network traffic during the first scan. Settle this before the PoC, because it decides who has to approve the trial.
Three common models
| Model | What leaves your network | Typical sensitivity |
|---|---|---|
| Package list lookup | Names and versions, sometimes hashes | Low to moderate |
| Manifest and lockfile upload | Full dependency files, maybe repo name | Moderate |
| Source upload or repo access | Code and history | High |
Even the lowest tier is not nothing. A list of internal package names can reveal product plans, and private package names should not be sent to a public service.
A familiar example comes from the package manager itself. The npm documentation says the audit command submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities. That is a lookup model: it works because your dependency list goes to a service. Any scanner that runs a similar lookup does the same in principle.
Questions for the vendor
- What exact fields are sent: names, versions, hashes, file paths, repo URLs?
- Is any source code, or any file other than dependency files, uploaded?
- Can private package names be excluded or hashed?
- Where is data stored, for how long, and who can access it?
- Can the scan run fully inside our network or on a developer machine?
- What is deleted at the end of the PoC, and how do we confirm it?
Write the answers into the PoC kickoff note. They are cheap to ask and costly to learn late.
Verify, do not just ask
Run the first scan on a test machine and capture outbound connections with your usual network tools or proxy logs. Compare the hosts and payload sizes with the vendor's answer. A manifest is kilobytes. A source upload is not.
For a CLI or IDE extension, also check what it reads locally. Does it scan only the project folder you point it at, or does it crawl the home directory?
Access scopes matter as much as data
If the scanner connects to your source host, review the permissions requested. Read only access to selected repos is a different risk from organization wide write access. For the PoC, give the narrowest scope that works, and revoke it at the end. See least privilege for a scanner pilot.
Regulated teams
If you work under customer contracts or internal data rules, your legal or privacy team may need to see the data flow before any scan. Bring them the table above and the vendor's written answers. This post is not legal advice, so check your own obligations with the right people.
What a good answer sounds like
Specific, short and testable: "We send package URLs and versions only; no source leaves your environment; you can run the scan locally." Vague answers such as "data is handled securely" are a reason to ask again.
Try it yourself
Open the demo and note that an inventory is built from package names and versions, which is the minimum a lookup scanner needs.
Click through it at your own pace, or open it full screen.
Quick check
Is a package list safe to share?
Usually lower risk than source, but private package names and versions can still be sensitive. Decide with your data owner.
Can we run a PoC with no data leaving at all?
Only if the tool can run locally with an offline or mirrored advisory database. Ask whether that is supported and how fresh the data is.
Sources
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
