CI/CD Checksum Validation: Verify Build Artifacts Match Source
Your production deployment might not match what you built. Here's how to automatically verify build artifacts using checksums, detect supply chain tampering, and satisfy OWASP CICD-SEC-9 requirements without slowing down your pipeline.
Founder of ARCED Foundation, ARCED International, and Solutions of Things Lab (SoTLab). Built FolderManifest to help teams protect file integrity and stay audit-ready.
Key Takeaways
- →Checksums verify artifacts haven't been tampered with between build and deployment
- →OWASP CICD-SEC-9 requires integrity verification for high-assurance systems
- →SHA256 is the industry standard for artifact fingerprinting
- →FolderManifest provides reproducible integrity evidence for release artifact folders
- →Store checksums in immutable storage separate from your artifacts
What is CI/CD Integrity Verification?
Every time your CI pipeline builds a Docker image, compiles a binary, or packages an application, it creates an artifact. That artifact travels through your pipeline: build → test → stage → production. At each step, something could modify it.
Integrity verification means proving the artifact you deployed matches what you built. Not kind of matches. Exactly matches. Byte-for-byte identical.
Most teams don't check this. They assume their artifacts are safe. But we've seen build caches poisoned, dependencies substituted mid-pipeline, and deployment scripts modified binaries in transit.
Real Attack: SolarWinds Supply Chain Compromise
Attackers compromised SolarWinds' build system and inserted malicious code before compilation. The resulting Orion binaries had legitimate digital signatures but contained backdoors. If SolarWinds had verified checksums at multiple pipeline stages, they would have detected artifacts changing between approved builds and public releases.
Lesson: Digital signatures verify origin. Checksums verify integrity. You need both.
OWASP CICD-SEC-9: Artifact Integrity Requirements
The OWASP CI/CD Security Top 10 lists artifact integrity validation as CICD-SEC-9: Improper Artifact Integrity Validation. It's not a theoretical risk - real attackers exploit this.
OWASP requires:
- Verify artifacts before deployment using cryptographic checksums or digital signatures
- Store checksums in immutable storage where attackers can't modify them
- Block deployment if verification fails (don't warn, actually fail the pipeline)
- Automate verification so humans don't forget or skip it
FolderManifest supports integrity verification when release artifact folders are accessible on Windows. Teams typically pair it with their existing CI platform for orchestration and approval gates.
How Build Artifact Tampering Happens
Attackers have several opportunities to modify your artifacts. Understanding these attack vectors helps you design better defenses.
1. Developer Machine Compromise
If an attacker compromises a developer's laptop, they can modify source code before it's committed. The artifact built from this code is malicious, but everything looks legitimate in your CI logs.
Defense: Generate checksums of source files before build. Compare pre-build and post-build artifact checksums against known-good baselines.
2. CI/CD Server Breach
Attackers who access your Jenkins, GitHub Actions, or GitLab CI can modify build scripts, replace build dependencies, or alter artifacts after build completes.
Defense: Verify artifacts in a separate environment. Don't trust the CI server's word. FolderManifest running on a secured verification server can double-check every artifact.
3. Dependency Substitution Attacks
Your build pulls dependencies from npm, PyPI, Maven Central, or internal package repositories. Attackers who compromise these repositories can serve malicious packages that your build blindly trusts.
Example: NPM typosquatting attack
A developer accidentally installs cross-env instead of cross-env (notice the extra 's'). The malicious package downloads cryptocurrency miners in production builds. Checksum verification of package-lock.json catches this immediately.
4. Deployment Pipeline Injection
Between staging and production, artifacts pass through deployment scripts, configuration management tools, or orchestration systems. Any of these can modify files.
Defense: Verify checksums immediately before deployment, not just after build.
Checksum-Based Verification Workflow
Here's the workflow we recommend for CI/CD teams. It adds seconds to your pipeline but prevents production disasters.
Four-Step Verification Process
| Step | Action | Tool |
|---|---|---|
| 1. Generate Checksums | Create SHA256 checksums immediately after build completes | FolderManifest desktop app |
| 2. Store Checksums | Save checksums to immutable storage (separate from artifacts) | S3, GCS, Azure Blob with WORM |
| 3. Verify Before Deploy | Recalculate checksums, compare to stored values | FolderManifest desktop comparison workflow |
| 4. Block on Mismatch | Fail deployment if checksums don't match | CI/CD pipeline (Jenkins, GitHub Actions) |
Critical: Never Store Checksums with Artifacts
If your checksums and artifacts live in the same location, an attacker who modifies one can modify the other. Store checksums in separate, immutable storage before artifacts ever leave your build environment.
Wrong: Checksum file in same directory as artifact
Right: Checksums pushed to separate bucket with write-once storage
Implementation Examples
FolderManifest is a desktop app, not a CI CLI. Use it as a controlled release-gate step after your pipeline builds artifacts.
Recommended Release-Gate Pattern
- Build in Jenkins, GitHub Actions, Azure DevOps, or your existing CI system.
- Export release artifacts to a controlled verification folder on a Windows workstation.
- Generate a FolderManifest baseline for the approved release candidate.
- Store the generated manifest and HTML report in immutable evidence storage.
- Before production deploy, rescan artifacts and compare to the approved baseline.
- Block release if checksums do not match and escalate for investigation.
Tooling Boundary
Your CI platform handles orchestration. FolderManifest handles evidence-grade folder integrity snapshots and comparisons on Windows-accessible release artifacts.
FolderManifest for CI/CD Teams
FolderManifest wasn't built for CI/CD originally - we created it for audit teams who needed to prove file integrity. But DevOps engineers discovered it solves their artifact verification problems too.
Release Artifact Manifests
FolderManifest desktop scans entire release folders and creates manifests with SHA256 checksums, sizes, and timestamps. Use these manifests as signed-off release evidence before deployment.
Integration with Build Tools
FolderManifest works with any build system that produces files:
- .NET/msbuild: Verify `bin/Release` output folders before release.
- Node.js/npm: Verify packaged build output (`dist/`, installers, assets).
- Docker workflows: Verify extracted image artifacts and deployment bundles.
- Java/Maven: Verify `target/` build outputs and release archives.
- Python/pip: Verify wheel/package output folders before distribution.
Compliance Evidence for Audits
When SOC 2 or ISO 27001 auditors ask about your change management process, FolderManifest provides the evidence:
- Manifests showing exactly what changed between deployments
- Checksum verification logs proving integrity
- Automated evidence of verification before each production release
- Tamper-evident documentation of approved artifact states
Pricing
Keep quick checks free, then scale verification with desktop automation:
- Free forever: Web tools for lightweight verification workflows.
- Desktop one-time licenses: $39 (single device). Team licensing via contact@foldermanifest.com.
- Use case: Local artifact verification and HTML evidence reports.
Secure Your CI/CD Pipeline
Free forever web tools | Desktop one-time license: $39 (single device). Team licensing via contact@foldermanifest.com.