Pin the exact version, download from the project's official release page, verify the signature or provenance file if one is published, compare checksums, and run the scanner with least privilege. These steps reduce the chance that you install a tampered tool, but they do not prove the tool is bug free.
Why this matters
A security scanner is software you run with access to source code, build artifacts and often tokens. If an attacker replaces it, your own pipeline does the work for them. The risk is the same whether the tool is open source or from a vendor.
SLSA, a set of incrementally adoptable guidelines for supply chain security, describes the underlying problem: code can be altered at any step from source to build to packaging and distribution, so scanning source alone does not prove the code you run is the code that was reviewed. Provenance is the tool for narrowing that gap.
Steps
- Pin the version. Name an exact version, not "latest", in your pipeline file. Update deliberately.
- Use the official source. Link from the project's own documentation, not from a search result or a blog.
- Check for signatures. See whether releases include signature files. OpenSSF Scorecard's Signed Releases check looks for files such as .sig, .asc, .sigstore and .intoto.jsonl, and gives its highest score when releases have SLSA provenance files. Note that Scorecard checks that files exist, not that they verify.
- Verify them yourself. Follow the project's instructions to verify with the published key or identity. If instructions are missing, treat that as a finding.
- Compare checksums. If a checksum file is published, compare it, but remember a checksum served from the same place as the file adds little if that place is compromised.
- Mirror internally. Store the verified binary in your own artifact store and have CI pull from there.
- Restrict the job. Give the scanning job read access only, short lived tokens and no production credentials.
What each check proves
| Check | Proves | Does not prove |
|---|---|---|
| Pinned version | You get the same release every time | That the release is safe |
| Signature verifies | Signed by the key holder | That the key holder is trustworthy |
| Provenance file | Where and how it was built, if you verify it | That the build source was clean |
| Internal mirror | Consistency, plus offline resilience | Anything about the original |
For managed platforms
A hosted service may not give you a binary at all, but agents, plugins and CLIs still run in your environment. Ask the vendor how they sign and publish them, and verify what they tell you. Our post on verifying signed releases and attestations from a supplier shows how to ask.
Keep a record
Write the verification steps in the pipeline's README and re-run them at every version bump. Add the scanner to your own software inventory, with its version and source.
Safeguard publishes installers and clients on its download page, and you can run a free scan at gold.safeguard.sh/scan without installing anything.
Quick check
Is a published checksum enough?
It helps against corruption. It adds little against tampering if the checksum sits next to the file, so prefer signatures and provenance.
Should the scanner job have write access to the repository?
Not unless a feature needs it. Start with read only and add scoped permissions deliberately.
Sources
Last reviewed: 19 October 2026.
