CRACI vs Syft and Grype

The short answer

Syft is a popular open-source SBOM generator, and Grype is its companion vulnerability scanner. Together they cover generate and match for free, in any pipeline. CRACI is a GitHub Actions runner that records what each build fetched, states whether that record is complete, controls where the build can connect, signs provenance and keeps monitoring what shipped. The one-line difference: Syft reconstructs the SBOM from files, and how much it finds depends on its configuration and on what is on disk when it runs. CRACI observes it, and tracks the vulnerabilities in what it recorded, so one product does the job of both.

What Syft and Grype do well

Syft is "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems." It recognizes dozens of packaging systems, from Alpine, Debian and RPM to Go, Python, Java, JavaScript, Ruby, Rust, PHP and .NET. It writes CycloneDX, SPDX and its own Syft JSON, converts between formats, and can create signed SBOM attestations using the in-toto specification.

Grype scans container images, filesystems and SBOMs for known vulnerabilities. It prioritizes findings with EPSS, KEV and risk scoring, supports OpenVEX for filtering results, and its --fail-on flag fails a pipeline when it finds vulnerabilities at or above a severity you choose. Anchore notes that Grype "runs entirely locally and doesn't send any data to external services," apart from downloading its database.

Both are Apache-2.0 and sponsored by Anchore, whose commercial platform, Anchore Enterprise, "builds on open source Syft and Grype." This page is about the open-source tools.

Syft is strong when it has the right files in front of it. Pointed at a source tree that commits its dependencies, such as ollama/ollama, its default scan resolves them with versions, package URLs and the dependency edges between them.

One flag changes the answer

Syft chooses its catalogers by scan type, and its documentation explains why: "files that hint at the intent to install software do not have enough information in them to determine the exact version." Catalogers carry tags such as declared, installed, image and directory, and flags like --select-catalogers and --override-default-catalogers change the set.

In syft cataloger list at v1.51.1, the JavaScript cataloger that reads node_modules is tagged for image and installed scans and is not in the default set for a directory scan. So on an installed checkout, one flag decides whether the npm packages in node_modules are read at all. Same tool, same version, same tree.

The flip side matters just as much. No single configuration is right everywhere:

• On a clean express 5.2.1 checkout, which has no lockfile, the default scan has no npm dependencies to resolve and returns whatever else it recognizes, such as GitHub Actions and workflow files.
• Turn the installed catalogers on and point them at source trees as committed, where nothing has been installed yet, and they have almost nothing to read.
• A repository with no dependency manifest at all gives the scan no dependency files to read, whatever the configuration.

Nothing here is a bug. Syft reports what the files in front of it support, as designed. The practical consequence is that the SBOM depends on two decisions someone has to get right in every pipeline: which catalogers run, and whether dependencies were installed before the scan. And Grype can only match what Syft listed. A component missing from the SBOM never reaches the vulnerability lookup, so the scan comes back clean for it.

Where CRACI is different

CRACI does not have catalogers to choose, because it does not read the tree afterward. You change runs-on to craci, and a package-aware proxy records what the job fetches 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 result, in CycloneDX or SPDX, includes the transitive dependencies the build actually used.

• Completeness is explicit. Every job and cache is marked Complete, Complete with connections, Incomplete, Unavailable or Not recorded.
• The build is controlled. An egress policy (default deny or allow, 24 built-in software-source presets) is validated before the job starts and fails closed.
• The artifact is linked. Signed provenance (Ed25519 over SHA-512) ties each artifact, including OCI artifacts, to its build. A Syft attestation signs the SBOM; CRACI's provenance ties the artifact to the build that produced it.
• Monitoring. Monitored SBOMs are re-evaluated continuously, and findings are aggregated across builds and repositories.

Grype still does things CRACI does not. Severity gates in CI, VEX filtering and scanning images you did not build are Grype's territory, and CRACI's threshold alerts and build blocking are on the roadmap.

Moving from Syft and Grype

On CRACI there is no SBOM to generate and no scan step to maintain. The runner records the SBOM while the build runs, and CRACI keeps checking it for new vulnerabilities after the build has finished. Syft and Grype remain the tools for images and third-party software you did not build, and for pipelines outside GitHub Actions.

For the Cyber Resilience Act

The CRA asks manufacturers to document the components in each product, including an SBOM, and to handle vulnerabilities in it. Syft and Grype can produce and check that SBOM, and the evidence trail from each release back to its SBOM is yours to build. CRACI records the SBOM per build, links 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.