CRACI vs Kusari | Supply Chain Graph and Build Evidence

The short answer

Kusari is a software supply chain security platform from the team that co-created GUAC, the open-source graph for supply chain metadata. It builds a continuously updated knowledge graph from your source, SBOMs, VEX documents and existing scanner output, ranks what is exploitable, reviews pull requests and opens fixes. CRACI is a GitHub Actions runner. It records what each build pulls in while it runs, controls what the build can reach, signs provenance and keeps monitoring what shipped. Any graph reflects the SBOMs it is given; CRACI produces SBOMs from the build itself. The two compete for the same supply chain budget. For software you build yourself, CRACI covers the CI, the SBOM and the vulnerability tracking in one product.

At a glance

Capability	CRACI	Kusari
Runs your builds	Jobs run on CRACI runners	Ingests SBOMs and metadata from your pipelines
How dependencies are found	Observed fetches at the runner, including CI caches	SBOMs from waybill (lockfiles, caches, images, binaries) or your own tool
SBOM completeness state	Per job and per cache, five states	Not described in Kusari's documentation
Build network egress policy	Default deny or allow, fails closed	Outside its scope: Kusari does not run builds
Signed provenance and attestations	Ed25519 signatures, including OCI artifacts	SBOMs and attestations in SPDX, CycloneDX, in-toto
Monitoring what shipped	Monitored SBOMs re-evaluated continuously	Continuously updated graph with blast radius
Graph across many sources	API links artifact, build, SBOM and trace	Knowledge graph of SBOMs, VEX and scanner output
Ingests other scanners		Snyk, Black Duck, Dependabot, GitHub Advanced Security
Pull request security review		Inspector flags malicious packages, secrets, code weaknesses
Reachability analysis		Checks whether vulnerable code is actually called
CI systems	GitHub Actions	GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, Bitbucket, TeamCity

Included
Partly
Not included

Kusari and GUAC, precisely

GUAC (Graph for Understanding Artifact Composition) is an OpenSSF incubating project under the Supply Chain Integrity working group, licensed under Apache 2.0. It aggregates software security metadata into a graph database. Its documented inputs include CycloneDX and SPDX SBOMs, in-toto and SLSA attestations, OpenVEX and CSAF documents, OpenSSF Scorecard results, OSV and deps.dev data. GUAC aggregates metadata that other tools produce; it does not run builds.

Kusari's co-founders co-created GUAC with Google, and a Kusari co-founder is GUAC's lead maintainer. Kusari says it uses and curates GUAC, SLSA, OpenSSF Scorecard, ClearlyDefined and other open-source projects in its commercial products. GUAC also has other contributors, including Google, Red Hat, Purdue University and Citi. Kusari is the commercial platform; GUAC is the community project.

What Kusari does well

A graph built from open standards. Kusari's platform ingests source, build artifacts, CycloneDX and SPDX SBOMs, VEX and existing scanner output, including results from Snyk, Black Duck, Prisma Cloud, Dependabot and GitHub Advanced Security. It maps direct and transitive dependencies with provenance and lineage, and shows the blast radius of a new vulnerability across your estate.

Fewer, better findings. Reachability and exploitability analysis look for evidence that vulnerable code is actually called, so the queue holds what matters. AutoFix generates fix pull requests and validates them before they reach your repository.

Checks at the pull request. Kusari Inspector reviews every pull request on GitHub or GitLab for transitive vulnerabilities, leaked secrets, malicious and typosquatted packages, license risk, end-of-life dependencies, insecure GitHub Actions workflows and common code weaknesses. Kusari says Inspector is free to install, with no sales call required.

Standards and frameworks. Kusari produces SBOMs and attestations in SPDX, CycloneDX and in-toto formats, and lists support for frameworks including the EU CRA, FDA 524B, SSDF, IEC 62443 and DORA. Its uploader works across GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, Bitbucket Pipelines and TeamCity.

Where CRACI is different

Kusari describes its graph as built from source code and build systems as software is created, rather than reconstructed from finished binaries. That is the right instinct, and it is also where the two products diverge. Kusari's SBOMs come from a generator: its docs describe generating them with waybill, its open-source SBOM toolkit, when pull requests merge, or bringing your own tool. A generator reads lockfiles, manifests, caches and images. CRACI does not read the build's files to infer what it used. It is the machine the build runs on.

A record, not a reconstruction

With a one-line change to runs-on, your workflow runs on CRACI. A package-aware proxy records what each job downloads from package sources, and packages restored from CI caches are carried forward. Each SBOM states how complete it is, per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded. Monitoring starts from what the build actually fetched, and knows where the gaps are.

Control during the build

A graph helps you find what is affected after the fact. An egress policy at the runner decides, while the job runs, which hosts it may reach. CRACI policies are default deny or default allow, with 24 built-in software-source presets, and they are validated before the job starts and fail closed.

Provenance and monitoring from the same record

Signed provenance (Ed25519 over SHA-512) links each artifact, including OCI artifacts, to its build. Through the API you can go from an artifact to its build, its CycloneDX SBOM and the job network trace. CRACI keeps re-evaluating monitored SBOMs.

CRACI does not do what makes Kusari distinctive: it does not ingest other scanners, analyze reachability, or review pull requests for malicious packages and code weaknesses. It supports GitHub Actions only today.

Replacing Kusari with CRACI

For the software you build and ship, CRACI covers what a graph platform is usually bought for. It runs the build, records the SBOM with a stated completeness, signs provenance, keeps re-evaluating monitored SBOMs as new vulnerabilities are published, aggregates findings across builds and repositories, and lets security teams triage them and route each one to the team that owns the fix. Egress policy limits what a build can reach in the first place, which no graph can do.

Be clear about what you give up. Kusari connects one graph across many scanners and SBOM sources, ingests VEX, analyzes reachability, and reviews pull requests for malicious packages, leaked secrets and code weaknesses. CRACI does none of that today, and it supports GitHub Actions only. If correlating findings from many existing tools is your main need, Kusari remains the stronger fit.

For the CRA

The Cyber Resilience Act asks manufacturers to document the components in their products, including an SBOM, and to handle vulnerabilities for as long as a product is supported. Reporting of actively exploited vulnerabilities applies from September 2026. Kusari connects SBOMs, VEX and findings in one graph, and it lists the CRA among the frameworks it supports. CRACI produces the per-build evidence and keeps monitoring it: what each release was built from, with provenance, ongoing monitoring, and report export in PDF, HTML, CSV, Excel and JSON. CRACI automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process; neither tool makes a product compliant on its own. Read what the CRA requires.

Moving to CRACI

Set runs-on: craci on the workflows that build what you ship. CRACI replaces the runner, not GitHub Actions, and runs still appear in the GitHub UI. Learn more about build-time SBOM generation and vulnerability tracking.