You prepare audit evidence with the Safeguard CLI by scanning your code to produce an SBOM and findings, validating the SBOM against SPDX or CycloneDX, and generating a report from that scan result. Keep the raw files with the report, so the auditor can trace every line back to a build.
What does an auditor actually want to see?
For software supply chain controls, most auditors ask for three things: an inventory of what you ship, proof that you looked for known vulnerabilities, and a record of what you did about them. They also want it dated and repeatable. A screenshot of a dashboard fails the repeatable test. A set of files produced by a command you can run again passes it.
The CLI is built for that shape of evidence. Its documentation describes a scan that builds the SBOM and matches it against an advisory database, plus a report command described as the artifact you hand an auditor. We will walk through the sequence below.
How do you produce the files?
Install the CLI from the installer at cli.safeguard.sh (it is also published as the npm package @safeguard-sh/cli, and needs Node 18 or newer on that route). Sign in with safeguard login, which uses the OAuth 2.0 device flow, so you approve the machine in a browser.
Then run the scan against a directory, a repository URL, a container image or an existing SBOM file:
safeguard scan --dir . --output out/
safeguard validate out/sbom.json
safeguard report
The scan writes sbom.json and findings.json. Per component files such as vuln.json, license.json, secret.json and scorecard.json sit beside them. The validate command checks SBOM documents against the SPDX and CycloneDX specifications, which catches a malformed file before an auditor does. The report command builds a report from an existing scan result. Run safeguard --help to see the flags it accepts on your installed version, since options can change between releases.
What about fixes?
Findings without remediation records look like neglect. The fix command updates vulnerable packages, writes a patched SBOM and emits a fix report. It has a preview option, so you can see what would change before it changes. It can also open a pull request, which gives you a reviewable, timestamped record in your own source control.
Two SBOMs from the same project, one before the fix and one after, make a strong pair. They show the control working: a finding existed, a change was made, the finding is gone.
Where should the evidence live?
Not on a laptop. Commit the artifacts for each release to a locked evidence bucket or a release attachment, named by version and date. Store the report next to the SBOM it came from. If your pipeline runs the scan, the CI job log adds a second timestamp that is hard to forge.
A small convention helps. One folder per release, containing the SBOM, the findings, the report and a short text note saying who ran what and when. An auditor sampling three releases from last year should find the same layout in all three.
What are the limits?
The CLI produces software inventory and vulnerability evidence. It does not replace evidence for access reviews, change approvals or training, which come from other systems. It also does not make you compliant with any framework; it feeds the supply chain portion of the evidence an assessor reviews.
A report is only as good as the scan behind it. If you scan once a quarter, you evidence a quarterly control. Scan on every build if your policy says continuous.
What to do
- Install the CLI and sign in on a build machine or runner, not only on a developer laptop.
- Run a scan on your main branch and read
findings.jsonbefore anyone else does. - Validate the SBOM, and fix format errors at the source.
- Generate the report and store it with the raw files in a per release folder.
- Repeat on every release, and keep the before and after SBOMs when you run a fix.
- Write down which control each artifact supports, so the mapping is not rebuilt from memory at audit time.
Try the same flow in the local runner demo.
Quick check
Does the CLI send my source code to Safeguard?
The CLI documentation says the only payloads sent to the platform are the SBOM and findings files. Check your own policy against that before you scan sensitive repositories.
Can I use the report as proof of a certification?
No. The report is evidence of what you scanned and found. A certification comes from an assessor, not from a tool.
Sources
- Safeguard CLI documentation, fetched 18 October 2026.
- NIST SP 800-218, Secure Software Development Framework 1.1, fetched 18 October 2026.
Last reviewed: 18 October 2026.
