Verify Build Artifacts with SHA Hash in CI/CD Pipelines
Generate and verify SHA-256 checksums for build artifacts, Docker images, and release files in GitHub Actions. Prevents tampered binaries from reaching production.
The Problem
Your CI pipeline builds a binary, uploads it to S3, and a separate deployment job downloads it. How do you know the file wasn't corrupted or tampered with in transit? Missing checksum verification is a common supply chain attack vector.
Why This Matters
SHA-256 hash verification is a foundational supply chain security practice. It's required by SLSA (Supply-chain Levels for Software Artifacts), recommended by NIST, and used by every major package registry (npm, PyPI, Homebrew). A 2-line checksum step in your pipeline prevents binary tampering attacks like those that compromised SolarWinds and XZ Utils.
Step-by-Step Instructions
Use the Hash Generator to fingerprint your artifact
Paste the content of your build artifact or file into the SHA hash generator below. This gives you the expected checksum to embed in your workflow or publish alongside your release.
Generate the checksum in your build job
After building, run sha256sum myapp-linux-amd64 > myapp-linux-amd64.sha256. Upload both the binary and the .sha256 file as artifacts. The checksum file is your tamper-evident seal.
Verify the checksum in your deploy job
Download both files, then run sha256sum -c myapp-linux-amd64.sha256. If the file was modified, this command exits with code 1 and the deployment halts.
Attach checksums to GitHub Releases
Include the .sha256 file in your release assets. Users can verify downloads with sha256sum -c. This is standard practice for Go, Rust, and Python release tooling.
Try It Now — SHA Hash Generator
Open full page →All processing happens in your browser — no data is sent to any server.
Before & After Example
# Build job
- name: Upload artifact
uses: actions/upload-artifact@v4
with:
name: myapp
path: dist/myapp-linux-amd64
# Deploy job (separate run, possibly minutes later)
- name: Download artifact
uses: actions/download-artifact@v4
with:
name: myapp
# Question: how do you know this binary hasn't been tampered with?
# ── Build job ──────────────────────────────────────────
- name: Build binary
run: go build -o dist/myapp-linux-amd64 ./cmd/myapp
- name: Generate SHA-256 checksum
run: |
cd dist
sha256sum myapp-linux-amd64 > myapp-linux-amd64.sha256
echo "Checksum: $(cat myapp-linux-amd64.sha256)"
- name: Upload artifact + checksum
uses: actions/upload-artifact@v4
with:
name: myapp-with-checksum
path: |
dist/myapp-linux-amd64
dist/myapp-linux-amd64.sha256
# ── Deploy job ──────────────────────────────────────────
- name: Download artifact
uses: actions/download-artifact@v4
with:
name: myapp-with-checksum
- name: Verify artifact integrity
run: |
sha256sum -c myapp-linux-amd64.sha256
echo "✓ Artifact verified — safe to deploy"
- name: Deploy (only runs if verification passed)
run: ./deploy.sh myapp-linux-amd64
Frequently Asked Questions
SHA-256 vs MD5 — which should I use in CI/CD?
Always use SHA-256 or SHA-512. MD5 is cryptographically broken and should not be used for integrity verification. SHA-256 is the current standard and is required by SLSA level 1+.
Does GitHub Actions cache artifacts between jobs?
Artifacts uploaded with actions/upload-artifact are stored in GitHub's artifact storage and available to all jobs in the same workflow run. They are NOT shared between different workflow runs.
How do I verify Docker image integrity?
Use Docker Content Trust (DOCKER_CONTENT_TRUST=1) or compare image digests: docker inspect --format='{{.Id}}' myimage:tag. Store the digest as an artifact output and compare in deployment jobs.
Related Workflows
Want the full SHA Hash Generator experience?
Open the standalone tool for more space, keyboard shortcuts, and additional features.
Open SHA Hash Generator →