Run dated scans with the Safeguard CLI on the machine that holds the code, keep the output files, and map them to the controls your auditor asks about. The local runner keeps source code on your machine and pushes only the SBOM, findings and job status to the platform.
What is the local runner?
Per the Safeguard docs, the runner is built into the CLI. It polls the platform for jobs assigned to its machine over outbound HTTPS, executes each job with its own local scan server, and uploads result files. Source code is never uploaded. The pushed items are the SBOM and findings, plus job status. It suits private repositories and restricted networks that allow only outbound HTTPS.
What evidence can it produce?
The docs say result files are the SBOM and findings, and they do not describe other evidence formats. The CLI itself writes sbom.json, findings.json and per component files such as vuln.json, license.json, secret.json and scorecard.json into the folder you pass with the output option. There is also a safeguard report command that generates a report from an existing scan result.
That gives you an inventory, a findings list and a time. Auditors usually want more than that: who reviewed the findings, what you did about them, and proof of the process.
How do you make it audit-ready?
Date and freeze. Run scans on a schedule, from a clean checkout at a known commit, and store the output folder under that commit and date. Do not overwrite earlier runs.
Record the tool state. Run safeguard update to refresh the vulnerability databases, and note the CLI version. Version pinning is available with the SAFEGUARD_VERSION variable.
Add the human part. For each critical or high finding, record the decision: fixed, accepted with reason and owner, or false positive with reason. A spreadsheet or ticket link works.
Map to controls. Your auditor's framework determines the questions. Typical ones ask for a software inventory, a vulnerability management process and proof it runs regularly. Write one line per control saying which artifact answers it.
What does it not do?
The runner is a scanning tool. It does not certify you for any framework, and the docs do not describe a built-in evidence package. Safeguard has a wider compliance automation platform, but this post covers only what we confirmed about the runner and CLI.
What to do
- Install the CLI and sign in with safeguard login.
- Start the runner for a workspace with safeguard runner start and check it with safeguard runner status.
- Pin the CLI version and run safeguard update before each scan.
- Scan from a clean checkout and save the output folder under the commit hash and date.
- Log a decision and owner for every critical and high finding.
- Keep a control to artifact table, one line per control.
- Repeat on a fixed schedule and keep every run.
- Share the folder with your auditor through your normal secure channel.
What does a control table look like?
Keep it to one line per control. For example:
- Control: we maintain an inventory of software components. Artifact: sbom.json from the scan at commit abc123 on the stated date. Owner: the platform lead.
- Control: we identify known vulnerabilities in our software on a regular schedule. Artifact: findings.json and vuln.json from each scheduled run, with the run dates listed. Owner: the security lead.
- Control: we review and decide on high severity findings. Artifact: the decision log, with a fix, exception or false positive reason for each. Owner: the engineering manager.
- Control: we detect exposed secrets. Artifact: secret.json from each run. Owner: the security lead.
The table lets an auditor find your evidence without a call. It also shows you where evidence is missing. If a line has no artifact, that is a finding for your own backlog.
Quick check
Does the runner send my source code to Safeguard?
Per the docs, no. It uploads the SBOM and findings plus job status, and source stays on your machine.
Will this satisfy my auditor on its own?
Rarely. It supplies inventory and findings. You add the review decisions and the control mapping.
Sources
Last reviewed: 18 October 2026.
