Use SARIF when a code scanning tab should show results on the right file and line, JSON when a script or archive will read them, and the default table for a person at a terminal. Detect supports all three, with table as the default.
What each format is for
Table is the default. It is readable in a build log and useless to a program. Use it when you run detect by hand or want a quick look in the console.
JSON is for machines. Archive it as a build artifact, parse it with jq, or feed it to another tool. Safeguard's Jenkins example uses JSON for this reason: it writes the file and archives it.
SARIF, the Static Analysis Results Interchange Format, is what GitHub code scanning reads. The GitHub and Azure DevOps examples in the documentation use it. Use it when a platform has somewhere to display results.
How to choose per system
On GitHub, choose SARIF and upload it with the upload-sarif action. The job needs security-events write permission, per GitHub's documentation, and private repositories need code scanning available. See the GitHub Actions recipe.
On Jenkins, choose JSON and archive it, as in the Jenkins recipe.
On Azure DevOps, the documented example writes SARIF to the staging directory and publishes it as an artifact.
On GitLab, the documented example uses scan, not detect, and saves the result folder.
Command lines
# human readable, default
safeguard detect --path .
# for scripts and archives
safeguard detect --path . --format json --output detect.json
# for code scanning
safeguard detect --path . --format sarif --output detect.sarif
The usage page also shows a severity option, with high as an example, and an option to restrict the detection type, with secrets as the documented example. Other type values are not listed on that page, so check the help output for your version.
Redaction
Detected secret values are redacted by default, according to the usage page. There is an option to show them unredacted. Do not use it in CI. A SARIF or JSON file in an artifact store is readable by anyone with pipeline access, and an unredacted secret in an artifact is a new leak.
Size and retention
SARIF files can get large on a big repository. GitHub's page says to check that the file is within the supported size for upload but gives no number, so look at the current limits before you scale up. Set artifact retention to match how long you need the evidence.
Mixing formats
Nothing stops you running detect twice, once for SARIF and once for JSON, if different consumers need them. The cost is a second scan. A cheaper habit is to produce one machine readable file and convert it later where you can. Pick one source of truth, and name the file after the format so nobody opens the wrong one.
Quick check
Is the default output good enough for CI?
Only for reading in the log. Choose JSON or SARIF if anything else needs to use the result.
Does scan support SARIF?
The documentation shows SARIF for detect. Scan writes a folder of files including an SBOM and vulnerability results.
Sources
- Safeguard docs: CLI usage
- Safeguard docs: CI/CD Integration
- Safeguard docs: CLI
- GitHub docs: Uploading a SARIF file to GitHub
Last reviewed: 19 October 2026.
