According to the Safeguard documentation, the CLI scans on your own machine and uploads only SBOMs and findings, never source code. A separate findings command prints results locally and uploads nothing. Do not take any scanner's word for it, though. You can verify what leaves your network in about ten minutes.
What the documentation says
Three statements, from three places:
- The CLI reference page says source code is not uploaded and only SBOMs and findings leave the machine.
- The usage and CLI docs say the local runner uploads SBOMs and findings but never source code.
- The help text of the findings command, in the build we checked, says nothing leaves the machine: no project is registered and no finding or file is uploaded, even when signed in.
An SBOM is a list of components and versions. Findings are the matched vulnerabilities and rule hits. Both can still be sensitive: package names can reveal internal projects, and file paths in findings can reveal structure. Plan for that.
Local scans versus repository connections
There are two models, and they handle code differently.
CLI on your machine or runner. The scanners run where your code already is. Output files are written to a folder you choose. What gets uploaded depends on the command and whether you are signed in.
Connected repository. You grant the platform access to the repository through an integration, and the platform runs the scan. This is a different trust decision, because the platform reads the code.
Pick based on your data rules. If policy says source must not leave the network, use the CLI model and verify the traffic.
What about the network at all?
The CLI page also says the scan does not need internet access to do its work. In practice a few things do need a network: signing in, refreshing vulnerability databases, and uploading results. The usage docs describe a way to import a database downloaded elsewhere, which helps on restricted hosts. Whether your exact setup runs fully offline is something to test, not assume.
A ten minute verification
- Run the scan on a test machine or container with a throwaway repository.
- Capture outbound connections with your usual tool, such as a proxy log or a packet capture on the host.
- Note every destination and roughly how much data goes to each.
- Repeat while signed out, and again with the findings command.
- Compare the byte counts with the size of the repository. A source upload would be about that big. An SBOM and findings payload is usually far smaller.
Write down what you saw and the CLI version, so the check can be repeated after upgrades.
Reduce what you share anyway
- Scan a directory, not a whole home folder.
- Exclude vendored and generated code where the option exists.
- Keep output folders out of version control. They contain package inventories.
- In CI, mark artifacts as private and set a short retention.
Quick check
Does the CLI send my source files to Safeguard?
The documentation says no. Only SBOMs and findings are uploaded. You can confirm this on your own network by capturing the traffic during a test scan.
Is an SBOM safe to share publicly?
Not automatically. It lists your dependencies and versions, which can reveal internal package names and known weak points. Share it deliberately.
If you would rather not install anything while you evaluate, the free scan at gold.safeguard.sh/scan is another option.
Sources
Last reviewed: 19 October 2026.
