Check that the release is signed or carries a build attestation, verify it with the publisher's documented method, compare checksums, and pin the exact version or digest in your pipeline. A valid signature proves where it was built, not that the code is safe, so treat it as one control of several.
Why this matters more for a scanner
A security scanner is a privileged tool. In CI it often reads your whole repository and sometimes holds tokens to post results. If a tampered copy ran there, the damage would reach every repository it touches. That is reason enough to verify the download rather than pipe an install script straight into a shell.
Step 1: Look for signatures or provenance
The OpenSSF Scorecard Signed-Releases check looks in a project's last release assets for files such as signature files, Sigstore bundles and in-toto provenance. It scores the project higher when signatures are present for each release and highest when SLSA provenance is attached. The documentation is explicit that the check does not verify the signatures. It only reports whether they exist.
So presence is a good sign, but you still have to do the verification yourself.
Step 2: Verify the attestation
GitHub documents artifact attestations as signed claims about how and where software was built, including the workflow, repository and commit. GitHub generates them with Sigstore. If the project publishes them, you can check a downloaded file with the GitHub CLI.
gh attestation verify ./scanner-linux-amd64.tar.gz --repo OWNER/REPO
Replace OWNER and REPO with the project's repository. Read the project's own release notes for the exact artifact names and any extra flags it recommends.
Step 3: Know what verification does not prove
GitHub's documentation warns that attestations are not a guarantee an artifact is secure. They link the artifact to source code and build instructions. You still decide whether you trust that source and that build.
Verification will catch a swapped binary. It will not catch a malicious change that was committed legitimately by a compromised maintainer.
Step 4: Pin what you verified
Once verified, pin it.
- Record the version and the hash you checked.
- Reference that exact version or digest in your pipeline, not a floating tag such as latest.
- Update deliberately: verify the new release, then change the pin in a reviewed pull request.
- If you use a prebuilt container image or action, pin by digest or commit hash as well.
A short checklist
| Check | Done when |
|---|---|
| Signature or attestation exists | Found in release assets |
| You verified it | Command output saved with the ticket |
| Version is pinned | Hash or digest in the pipeline file |
| Upgrades are reviewed | Pull request required for pin changes |
| Token scope is minimal | Read only unless it must comment |
If a project publishes no signatures at all, you can still use it, but record that as an accepted risk and keep its permissions narrow. Safeguard's guardrails and policies can gate what runs in your pipeline, which is a useful second layer around any scanner you adopt.
Quick check
Does a checksum replace a signature?
No. A checksum only proves the file matches a number published somewhere. If the same place was compromised, both can be changed together.
Is a verified scanner safe to run with broad tokens?
Verification says nothing about permissions. Grant the least access the scanner needs regardless.
Sources
- GitHub Docs, Artifact attestations
- OpenSSF Scorecard, Checks documentation
Last reviewed: 19 October 2026.
