A consultant arrives with a short window and a client who is nervous about sharing code. The useful tools are the ones that produce evidence quickly without moving source around. Safeguard has several, and it also has limits you should state in your report.
What it is
For consulting, four capabilities matter: the CLI that scans locally, SBOM scanning for files the client already has, Gold lookups for public packages, and exports you can attach to a deliverable.
How to use it
Scan on the client's machine, not yours
The CLI builds an SBOM, finds vulnerabilities and license risks, and writes results as files, all locally. Install it on a client provided machine:
curl -fsSL https://cli.safeguard.sh/install | bash
safeguard scan --dir .
Results land in ./output, in a folder per scan, with files such as vuln.json, license.json and collection.json. If you scan from the signed in interactive terminal, the runner uploads the SBOM and findings but never the source. That matters when the client's contract forbids sharing code.
For a private repository, the CLI accepts a git token, and for a private registry, registry credentials, as documented. Prefer short lived, read only credentials and tell the client to revoke them afterwards.
Start from the client's SBOM
If they already produce an SBOM, skip the scan of source:
safeguard validate sbom.json
safeguard scan --sbom sbom.json
validate checks CycloneDX, SPDX and VEX documents against their specifications, which is a useful finding on its own when the SBOM is incomplete. For a quick look with no install, the free scan at gold.safeguard.sh/scan accepts CycloneDX or SPDX files, runs in the browser, needs no login and covers up to 100 dependencies.
Check public components
Use gold.safeguard.sh to look up a package, container image or CVE. Each CVE page includes an Am I affected check against the version the client runs, and the KEV status. Each package page with known vulnerabilities shows a recommended safe version. Cite the page in your report so the client can reproduce your check.
Secrets and misconfigurations
safeguard detect --detect secrets --format sarif --output detect.sarif
Values are redacted in the output unless you ask otherwise. Keep it that way in anything you send around.
Control what you can see
If the client gives you an account, the Auditor role is read only across audit records, findings and compliance evidence. Ask for that rather than Admin. Client administrators can also switch off client types you should not be using.
Where assistants fit
You can connect Claude or ChatGPT to mcp.safeguard.sh. The assistant acts as the signed in user and sees only what that role allows. Do not point an assistant at a client tenant unless the client has agreed.
Limits to write into your report
The CLI does not fail on findings and has no severity threshold flag, so a clean exit code is not a clean result. A readiness score in the platform is not an audit opinion. Reachability results can be unknown, and unknown is treated conservatively. State these plainly.
Try it yourself
Take any public project you have permission to test. Generate an SBOM, validate it, scan it, and write a one page summary that cites the Gold page for its worst finding.
Click through it at your own pace, or open it full screen.
Quick check
What does the signed in CLI terminal upload after a scan?
The SBOM and findings, not the source.
Which command checks that a client SBOM is well formed?
safeguard validate, which checks CycloneDX, SPDX and VEX documents.
Which Safeguard role is read only for evidence and findings?
Auditor.
