CRACI vs Trivy

The short answer

Trivy is one of the most useful free security tools there is. It scans container images, filesystems, repositories, virtual machine images and Kubernetes for vulnerabilities, misconfigurations, secrets and licenses, and it emits SBOMs as a side effect. CRACI is a GitHub Actions runner that records what each build fetched, controls where the build can connect, signs provenance and monitors what shipped. The core difference: Trivy infers the component list from files, while CRACI observes it. For the SBOM and dependency vulnerabilities of the software you build, CRACI replaces Trivy. For the rest of what Trivy scans, it does not.

What Trivy does well

Trivy's own description is "a comprehensive and versatile security scanner," and that is accurate. One binary covers several jobs that would otherwise need separate tools:

• Many targets. Container images, filesystems, remote Git repositories, virtual machine images and Kubernetes.
• Many scanners. OS packages and software dependencies, known vulnerabilities, infrastructure as code misconfigurations, secrets and software licenses.
• SBOMs in and out. trivy fs --format cyclonedx or --format spdx-json writes an SBOM, and trivy sbom scans an existing SBOM for vulnerabilities.
• Runs anywhere. It is open source under Apache-2.0, works as a CLI, and has a GitHub Action and a Kubernetes operator.

CRACI does none of the IaC, secret or cluster scanning. If you need to check a Terraform plan, catch a committed token or scan a third-party image you did not build, Trivy is the right tool and stays in your stack.

2:07

Where CRACI is different

Trivy reads files; CRACI watches the build

Trivy's documentation is clear about its method: "If the target is a pre-build project, like a code repository, Trivy will analyze files used for building, such as lock files." For a post-build target such as a container image, it reads installed package metadata and binaries instead. For Node.js repositories, that means package-lock.json, yarn.lock, pnpm-lock.yaml or bun.lock.

That design is reasonable, and it has a predictable edge. expressjs/express 5.2.1 commits no lockfile, and the anthropics/claude-code repository has no dependency manifest of any kind, so for a pre-build scan of either there is nothing for Trivy to read. That is Trivy working as documented, not failing. The versions a real install would resolve are decided at build time.

CRACI starts from the other end. You change runs-on to craci, and a package-aware proxy records what the job pulls from npm, PyPI, RubyGems, Cargo, Go, Nix and OCI sources, plus OS and download sources. Packages restored from a CI cache carry their evidence forward. The SBOM (CycloneDX or SPDX) describes what the build actually used, with or without a lockfile.

It says when the record is incomplete

Every CRACI job and cache has a completeness state: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. An empty or thin SBOM is visible as such, rather than looking the same as a project with few dependencies.

It controls and signs the build

Because CRACI runs the job, it can enforce a network egress policy: default deny or default allow, with 24 built-in software-source presets, validated before the job starts and failing closed. Signed provenance (Ed25519 over SHA-512) links each artifact, including OCI artifacts, to the build that produced it. Egress control is outside Trivy's scope. For signing, Trivy's docs show a two-tool flow: Trivy writes the SBOM and Cosign signs it as an attestation.

It keeps watching

Trivy scans when you run it. CRACI aggregates vulnerabilities across builds and repositories and keeps re-evaluating monitored SBOMs as new advisories are published, and security teams can triage findings and route them to the right team. Threshold alerts and build blocking are on CRACI's roadmap, so if you gate pull requests on a severity threshold today, keep doing that with your scanner.

Moving from Trivy

On CRACI there is no SBOM to generate and no dependency scan to maintain for the builds you ship. The runner records the SBOM while the build runs, and CRACI keeps checking it for new vulnerabilities after the build has finished.

Be clear about what CRACI does not do. It does not scan infrastructure as code, Kubernetes clusters or virtual machine images, it does not look for secrets or misconfigurations, and it does not scan images or software you did not build. It does not gate pull requests on a severity threshold today; threshold alerts and build blocking are on the roadmap. It runs GitHub Actions only. If you rely on Trivy for any of that, keep it for that.

For the Cyber Resilience Act

The CRA asks manufacturers to document the components in each product, including an SBOM, and to handle and report vulnerabilities in what they ship. Trivy helps by finding vulnerabilities and misconfigurations and by producing SBOMs, and the evidence trail from release to SBOM is yours to build. CRACI records the SBOM per build, ties it to the artifact and exports reports in PDF, HTML, CSV, Excel and JSON. It automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process. See what the CRA is and build-time SBOM generation.