To tell whether a CI build was tampered with, check four things: whether the artifact matches a clean rebuild, whether its provenance matches the expected source and builder, whether the pipeline definition changed, and whether a cache fed it unverified files. No single check proves a build clean.
What tampering looks like
The SLSA threat model lists how builds get compromised: forging provenance, a compromised build project owner, malicious builds interfering with others on shared infrastructure, stolen signing keys, and a poisoned build cache that makes a benign build use a malicious artifact. It also lists modifying an artifact after CI and reusing the original provenance.
The checklist
| Check | Question | Evidence |
|---|---|---|
| Source | Does the commit built match the reviewed commit? | Build metadata, git history |
| Pipeline | Did workflow files change near the build? | Commit and audit history |
| Cache | Did the build restore a cache? | Job logs |
| Artifact | Does a clean rebuild match? | Digest comparison |
| Provenance | Is it signed by the expected builder? | Attestation |
| Runner | Was it shared or long lived? | Runner records |
Steps
- Identify the build and artifact digest in question.
- Read the pipeline definition as it was at that commit. Look for added steps, new network calls and changed permissions.
- Check job logs for cache restores. GitHub's documentation notes cache contents are not signed or verified.
- Rebuild the same commit on a fresh, isolated runner and compare digests. If the build is not reproducible, compare file lists and dependency lists instead and treat differences as leads.
- If you have provenance, verify the builder identity and source reference rather than only that a signature exists. A signature on a malicious artifact is still a valid signature.
- Check whether the runner was reused between jobs.
Interpreting results
A matching rebuild is strong evidence, not a proof, if the clean rebuild used the same compromised dependencies. A mismatch is a lead, since timestamps and ordering differ in builds that are not reproducible. Either way, record what you compared.
What to record
Keep a short table of the builds you checked: commit, artifact digest, runner, cache use, clean rebuild result and your conclusion. If you cannot check a build, mark it unverified rather than clean, and plan to rebuild it. A written list makes it easy to explain to customers and auditors which releases you can vouch for and which you replaced.
Quick check
Is a valid signature proof the build was clean?
No. It shows who signed, not that the build process was uncompromised.
What if the build is not reproducible?
Compare dependency lists, file inventories and behavior, and treat unexplained differences as leads for investigation.
Safeguard's policies and gates can block a pull request that adds a risky dependency before it builds. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
