CRACI and Chainguard

The short answer

Chainguard builds open-source software from source and ships it hardened: minimal container images with few or no known vulnerabilities, rebuilt language libraries, VM images and hardened GitHub Actions, each with a signed SBOM and provenance. If your problem is that the base images and packages you start from carry too many CVEs, Chainguard goes straight at it.

CRACI is a CI runner for GitHub Actions. Your jobs run on it, and while they run it records every external dependency they fetch, enforces an egress policy and signs provenance for what you produce. Chainguard secures the inputs. CRACI secures and records the build. There is very little overlap, and the two fit together naturally.

At a glance

What Chainguard does well

Chainguard Containers is, in Chainguard's words, a zero-CVE, built-from-source container image catalog. Every image comes with a signed SBOM attestation in SPDX format and a SLSA 1.0 provenance attestation that describes the build environment, all verifiable with cosign. Customers can also get CycloneDX SBOMs on newer builds.

The CVE policy is concrete. For customers with an order, Chainguard commits to remediating critical CVEs within 7 calendar days and high, medium and low CVEs within 14 calendar days of a qualifying patch becoming publicly available, for the supported version streams of its images.

Chainguard Libraries takes the same approach to language packages. It is a catalog of Java, Python and JavaScript dependencies rebuilt from verified source instead of downloaded as prebuilt artifacts, delivered as an upstream to JFrog Artifactory, Sonatype Nexus Repository or Cloudsmith. Each package carries Sigstore signatures, a signed SBOM and SLSA Level 3 provenance. Chainguard Actions offers hardened versions of popular GitHub Actions, built from source and continuously scanned, and Chainguard VMs apply the model to virtual machine images.

CRACI does not produce hardened images or libraries and makes no promise about the CVE count of anything you pull. That is Chainguard's job.

Where CRACI is different

It watches your build, not Chainguard's

Chainguard's SBOMs and provenance describe Chainguard's artifacts, built in Chainguard's factory. Your build still runs somewhere, and it pulls in more than a base image: your own dependencies, toolchains, tools fetched by install scripts and whatever a workflow step downloads. CRACI records that. A package-aware proxy on the runner observes traffic to package sources across npm, PyPI, RubyGems, Cargo, Go, Nix and OCI, plus OS packages. Evidence travels with CI caches, and each SBOM states its completeness per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.

It limits what the build can reach

Hardened inputs help only if the build actually uses them. CRACI's egress policy is default deny or default allow, with 24 built-in software-source presets and typed custom sources for registries, including OCI registries and Git. Policies are validated before the job starts and fail closed. A policy that allows your Chainguard registry and your artifact repository, and little else, turns "we use Chainguard" from a convention into something the runner enforces.

It proves what you shipped

Signed provenance links each of your artifacts, including OCI images, to the CRACI build that produced it, with Ed25519 signatures over SHA-512. CRACI keeps re-evaluating monitored SBOMs for new vulnerabilities. Reports export in PDF, HTML, CSV, Excel and JSON.

Using them together

A typical setup:

• Chainguard supplies base images and, through your artifact repository, rebuilt libraries.
• CRACI runs the GitHub Actions jobs that build on them, with an egress policy that allows your approved sources, and records what each job fetched.

OCI is among the ecosystems CRACI detects, and CRACI works with JFrog Artifactory mirrors for npm and PyPI, so images and Python or JavaScript packages that arrive that way are part of the build record. Maven support, which covers Chainguard Libraries for Java, is on the roadmap.

Which one fits

• Scanners keep flagging CVEs in your base images: Chainguard replaces those images with hardened ones.
• You need evidence of what went into each release: CRACI records it from the build and ties it to the artifact.
• You want builds that can only reach approved sources: CRACI's egress policy enforces it at the runner.
• You want both clean inputs and a provable build: use them together, as above.

For the Cyber Resilience Act

Starting from components with few known vulnerabilities, a documented remediation SLA and signed SBOMs makes a manufacturer's vulnerability handling easier. Chainguard helps there. CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process: what went into each release, proof that the artifact came from that build, and ongoing vulnerability tracking. Neither makes a product compliant by itself. See what the CRA is and CRA compliance.

Adding CRACI to a Chainguard setup

Install the CRACI GitHub App, then change runs-on to craci in the workflows you want recorded. Your Dockerfiles and package configuration stay as they are. CRACI supports GitHub Actions today; GitLab, Jenkins and CircleCI are not yet supported. Learn more about build-time SBOM generation and CI/CD integration.