To see Safeguard CLI detect results in GitHub code scanning, run the detect command with SARIF output in a workflow, then upload the file with GitHub's upload action. The job needs permission to write security events. Detect covers secrets and misconfigurations, not dependency vulnerabilities.
What SARIF gives you
SARIF is a standard JSON format for static analysis results. Code hosts that read it can show findings next to the code, track them over time and let reviewers dismiss them with a reason. That beats a log line nobody reads.
The CLI's detect command can write table, JSON or SARIF, so no conversion step is needed.
A workflow outline
The CI documentation describes this shape for GitHub Actions: install the CLI, run detect with SARIF output, and upload with the standard CodeQL upload action at version 3. The permissions block needs security events set to write.
permissions:
contents: read
security-events: write
steps:
- uses: actions/checkout@v4
- name: Install the CLI
run: curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION=VERSION_HERE bash
- name: Detect
run: safeguard detect --format sarif --output safeguard.sarif
- name: Upload
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: safeguard.sarif
Replace the version placeholder with a release you have tested. Check the action versions against what your organization allows, since the checkout version shown here is only an example.
Things to check
- Permissions. Without security events write, the upload step fails. Forked pull requests get a read only token, so uploads from forks may not work.
- Code scanning availability. The view depends on your repository plan and settings. Confirm it is enabled before debugging the workflow.
- Redaction. Detect redacts values by default, so the SARIF will not contain the secret itself. Keep it that way.
- Always upload. Add a condition so the upload runs even if an earlier step reports a problem, otherwise the findings disappear when they matter.
Keep the build behaviour clear
Detect returns 0 whenever the scan ran, so findings alone will not fail the job. The upload shows them in the security view, and your branch protection or code scanning rules decide whether a pull request can merge. Check how your repository treats code scanning alerts so the outcome is what you intend.
Tuning noise
Set a minimum severity and exclude folders that contain fixtures. Review the first run by hand. Dismiss false positives in the view with a reason, which gives you a record, rather than lowering the severity for everyone.
Other CI systems
The same SARIF file works in Azure DevOps, where the documented example writes it to the artifact staging directory. Jenkins uses JSON archived on the build page. See the comparison post for all four.
Quick check
Why did the upload step fail with a permissions error?
The job lacks the security events write permission, or the run came from a fork with a read only token. Add the permission or run the upload on a trusted event.
Will this show vulnerable dependencies?
No. Detect finds secrets and misconfigurations. Use the scan command for dependency vulnerabilities.
Safeguard also offers a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
