A scanner job runs third party code, often with repository read access and sometimes more. Pin what it installs, give its token the least permission, keep secrets out of logs and treat its output as sensitive. The checklist below covers the five main CI systems.
1. Pin what you install
Pin the scanner version. For the Safeguard CLI, set SAFEGUARD_VERSION on the install step. Pin pipeline actions to a full commit SHA from the action's own repository, as GitHub advises. GitHub's guide notes that a lockfile is the stronger protection where you can use one.
If your policy forbids piping a script into a shell, download the release archive and verify its checksum. Safeguard publishes a SHA256SUMS file with each release.
2. Give the job the least permission
On GitHub, default the token to read only and raise it per job. The SARIF upload needs security-events write and nothing more. A compromised action can use the token to write to the repository, so do not hand it more than needed.
Use a different, narrower identity for the job than for deployments.
3. Keep secrets out of logs and files
Do not store secrets in the pipeline file. GitLab advises masking, protecting variables on protected branches and tags, and noting that masking is not a guaranteed boundary. Jenkins advises the credentials helper and single quotes in shell steps so Groovy does not interpolate the secret. GitHub advises registering derived values as secrets and rotating any secret that reaches a log.
4. Treat output as sensitive
An SBOM lists everything you ship. A detect report points at where secrets were. Restrict who can download artifacts and set a short retention. Keep detect redaction on.
5. Review changes to the pipeline file
GitLab warns that malicious changes to the CI file, especially from forks, can compromise masked and protected variables. Require review for pipeline file changes. Do not run pipelines with secrets on untrusted fork code.
6. Do not let the scan be the only gate
The Safeguard CLI exits zero when a scan runs. A green job proves the tool ran, not that the code is clean. Pair it with a platform gate, as in the gating post, and read the exit code properly using the exit codes reference.
7. Log what the job did
Keep the tool version and scan time in the archived output. When something goes wrong, you want to know exactly what ran.
Review it on a schedule
Put the checklist in your calendar. Once a quarter, check that pins are current, tokens are still the narrowest that work, artifact retention matches policy, and nobody added a new secret to the job without a reason. Pipelines drift, and security jobs drift just as much as build jobs.
Quick check
Is pinning to a tag enough?
Tags can move. A full commit SHA, taken from the right repository, cannot.
Who should be able to download scan artifacts?
The people who act on them. Default to a small group and short retention.
Sources
- GitHub docs: Security hardening for GitHub Actions
- GitLab docs: CI/CD variables
- Jenkins: Using a Jenkinsfile
- Safeguard docs: CI/CD Integration
- Safeguard CLI site
- Safeguard download page
Last reviewed: 19 October 2026.
