What data leaves your network during a dependency scan?

A dependency scan usually sends a description of your dependencies, meaning package names and versions, to a service that returns known vulnerabilities. It should not send source code. Depending on the tool it may also send repository names, file paths, or metadata, so check each one rather than assuming.

The common cases

The package manager's own audit command is a useful reference point. 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 the baseline pattern: a dependency description goes out, a report comes back.

Other tools vary:

Why a dependency list is sensitive

It looks harmless, but a list of dependencies can reveal:

• Internal package names that point to private projects
• Private registry URLs and scopes
• Exact versions, which show which known flaws you may still have
• Product architecture, such as which frameworks and SDKs you use

For most teams this is acceptable with a vendor under contract. For some it is not. The point is to decide knowingly.

How to find out what your tool sends

1. Read the data handling documentation. Look for named fields, not general statements like "metadata".
2. Run a scan behind a logging proxy. Capture the requests and read the payloads on a test repository.
3. Check what the CLI uploads versus what the CI plugin uploads. They sometimes differ.
4. Look at the SBOM export. If the SBOM contains file paths or internal names, so might the upload.
5. Check retention. Ask how long results and inputs are stored and how to delete them.
6. Check telemetry. Many CLIs report usage by default. Find the switch.

Reducing what goes out

• Use an offline or local database mode for the most sensitive repositories.
• Strip internal package names from reports you share externally.
• Scope tokens so a scan credential cannot read more than it needs to.
• Route scans through an egress proxy with an allow list so a misconfiguration cannot send data to an unexpected host.
• Keep private package scopes configured so the scanner does not query public services for them.

That last point matters for a second reason: querying a public service with an internal package name can leak the name and also invites dependency confusion attempts. Treat internal names as sensitive in both directions.

Questions for your security review

• Which exact fields are transmitted on each scan?
• Where is the data processed and stored, and for how long?
• Can we delete our data on request?
• Is source code ever uploaded, and under which features?
• Can the same capability run without sending anything?

Safeguard provides dependency scanning, SBOM generation, and reachability analysis; ask for the data handling details for each surface you plan to use, and try the free scan on a non sensitive project first.

Quick check

Sources

• npm Docs, npm audit

Last reviewed: 19 October 2026.