It depends on the product and how you deploy it, so ask. A scanner might upload whole images, only a package list, only hashes, or nothing at all because it runs locally. Each choice has different privacy and contract consequences. Get the answer in writing, test it on the network, and match it to your data rules.
Why this question comes up in reviews
Security and privacy reviewers ask where data goes before they approve any tool. For a container scanner the concern is concrete: images can hold proprietary code, configuration, internal hostnames and sometimes things nobody meant to include. If the scanner uploads the image, that content leaves your control. If it uploads only a list of packages and versions, much less does, though the list still reveals what you run.
This post gives you questions and a test method. It does not describe any particular product, because the right answer differs by tool and plan.
Four common data flow models
| Model | What leaves your network | Typical use |
|---|---|---|
| Local scan, local data | Nothing, if the vulnerability data is mirrored inside | Air-gapped and regulated sites |
| Local scan, cloud matching | A list of packages and versions, and maybe image hashes | Pipelines that want fresh data |
| Cloud scan from your registry | The image is pulled by the vendor's service | Registry connected services |
| Cloud scan from an upload | The full image or archive | Quick checks and trials |
Most products support more than one. The plan you buy may fix which is allowed.
The checklist
Ask these in the security review, and get answers in the contract or a written statement.
What is sent
- Which exact items leave my network: image layers, file contents, package lists, hashes, image names, tags, registry URLs, labels?
- Are file paths or environment variables from the image config included?
- Is any telemetry sent beyond scan results, such as usage data or error reports?
Where it goes
- Which regions and which subprocessors handle it?
- Is it encrypted in transit and at rest, and who holds the keys?
How long it stays
- How long is the data kept, and can I delete it on request?
- Is the data used to train models or improve other customers' results?
Control
- Can I run the scan entirely inside my network?
- Can I turn off telemetry?
- Can I restrict which images or repositories are scanned?
- What access do vendor staff have to my data, and is it logged?
Evidence
- Can you provide a data flow diagram and a list of subprocessors?
- What is your breach notification process?
How to test it yourself
Do not rely only on answers. A short network test is cheap.
- Set up a test host with outbound traffic logging or a proxy that records destination and size.
- Run the scanner on a small, harmless test image, with a unique marker string inside a file in that image.
- Record every outbound connection: destination, bytes sent and timing.
- Search captured traffic where you can, for the marker string. If the traffic is encrypted, compare byte counts: an upload of a 300 megabyte image looks very different from a 20 kilobyte package list.
- Run it again with the vendor's offline or minimal mode, if any, and compare.
- Write down what you found and share it with your reviewer.
You will not see content inside encrypted traffic without extra tooling, but destinations and sizes already tell a clear story. If sizes do not match the vendor's description, ask why.
A worked example
A team reviews a scanner that claims to send "metadata only." The test shows a single connection to the vendor's API sending about 40 kilobytes per scan of an image that is hundreds of megabytes. That fits a package list, not an upload. The team then asks what the metadata contains. The vendor replies that it includes package names, versions, the image digest and the image name with tag. The team's data rules treat internal image names as internal, so they ask for an option to send the digest only. The vendor offers it on a higher plan. The team now has an informed trade-off, instead of a surprise after launch.
Match findings to your data classes
Write down your own data classes and decide, for each, whether it may leave:
- Source code: usually no.
- Package names and versions: often yes, with a contract.
- Internal hostnames and image names: depends.
- Anything customer related: no.
If a scanner cannot meet the rule for a class you need protected, then choose a local mode, or choose a different tool.
Common mistakes
- Accepting "we only send metadata" without asking what metadata is.
- Testing with a toy image in a lab with open internet and not checking the production path.
- Forgetting that a registry integration lets a vendor service pull your images itself.
- Not revisiting the answer after a product update.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that the report is built from package names and versions. Ask yourself whether those two items alone could be matched without the rest of the image, and what that means for the data you send.
Where Safeguard fits
Safeguard offers a free web scan at gold.safeguard.sh/scan, a CLI and a desktop app. For data handling terms on your plan, ask your Safeguard contact and get them in writing, as you would from any vendor.
Quick check
Is a package list sensitive?
It can be. It shows which software and versions you run, which helps an attacker plan. Many teams accept sending it under a contract, but you should make that decision deliberately.
Can a scanner work with no data leaving my network?
Some can, by running locally with a mirrored copy of vulnerability data. Ask the vendor how the data is refreshed and how stale it can get.
Who should approve the data flow?
Your security and privacy reviewers, with legal where contracts are involved. Give them the vendor's written answers and your own test results.
Last reviewed: 19 October 2026.
