CRACI vs Finite State | Binary Analysis and Build Evidence

The short answer

Finite State is a product security platform for connected devices. It analyzes firmware, binaries, source code and supplier SBOMs, prioritizes vulnerabilities by reachability, and turns the results into evidence for regulations such as the CRA. CRACI is a GitHub Actions runner that records what each build pulls in while it runs, produces the SBOM from that record, controls where the build can connect, and signs provenance for the output. Finite State analyzes what you ship, wherever it came from; CRACI proves what your own build did. They are mostly complementary.

At a glance

Capability	CRACI	Finite State
Runs your builds	Jobs run on CRACI runners	Your CI uploads binaries or SBOMs to it
Records what the build fetched	Observed by the runner during each job	Analyzes source, binaries and supplier SBOMs
Egress policy while the build runs	Checked before the job, fails closed	Outside its scope
Signed build provenance	Ed25519 signatures, including OCI artifacts	Not described in Finite State's documentation
Binary and firmware analysis		50+ binary instruction set architectures
Supplier SBOMs and third-party findings	Vendor SBOMs can be added; no third-party findings	Ingested into one product record
Reachability analysis		Prioritizes what is actually exploitable
Recorded triage decisions	Triage and route findings to teams	VEX decisions with exploitability status
SBOM in CycloneDX and SPDX	Per build, with a completeness state	Per release, from source and binaries
CRA evidence	Reports in PDF, HTML, CSV, Excel, JSON	CRA control mapping and audit-ready reports
CI systems	GitHub Actions	GitHub Actions, GitLab CI, Jenkins and more

Included
Partly
Not included

What Finite State does well

Binary and firmware coverage. Finite State produces SBOMs and a software inventory across firmware, binaries and source code, "with support for 50+ binary instruction set architectures." For a device that runs code from many vendors on unusual chips, that breadth is the point.

One record across suppliers. It brings firmware, binaries, source code, supplier SBOMs and third-party findings into one platform, which helps when you need to reconcile what a supplier says against what is actually in the product.

Less noise. Finite State ranks findings by reachability, exploit intelligence and product context. It reports that since 2024, 40.5% of findings it analyzed for reachability were confirmed unreachable. It records VEX decisions with product impact and exploitability status.

Compliance evidence. Its compliance workflow covers EU CRA control mapping and evidence maintenance, and generates audit-ready reports with SBOM and VEX artifacts. It also addresses frameworks such as FDA guidance, UN R155 and IEC 62443.

CI integrations. Finite State embeds checks in GitHub Actions, GitLab CI and Jenkins. Its Binary Scan action uploads a binary built during CI to the Finite State platform for a quick or full scan.

Where CRACI is different

Finite State starts from artifacts: the finished binary, the source tree, the SBOM a supplier sent. CRACI starts from the build itself, because the build runs on CRACI.

Observed, not inferred

You change runs-on to craci and the job runs in an isolated virtual machine on a CRACI runner. A package-aware proxy records what the 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. Firmware teams can run Yocto on runners of up to 32 vCPUs and 96 GB of RAM. Sources BitBake fetches from the Yocto source mirror are recorded in the CRACI job SBOM.

Control during the build

A scan of the output cannot change what the build was able to reach. CRACI's egress policy can: it is default deny or allow, validated before the job starts, fails closed, and sends an email alert on a violation.

Provenance and monitoring

Signed provenance (Ed25519 over SHA-512) links each artifact to the build that produced it. CRACI aggregates vulnerabilities across builds and repositories and keeps re-evaluating monitored SBOMs as advisories appear.

CRACI does not analyze binaries or do reachability analysis. Its build record covers builds that run on it, and you can add SBOMs your vendors supply. For supplier firmware you receive as a binary without an SBOM, Finite State covers ground CRACI does not.

When to use which, and when to use both

Most of your firmware comes from suppliers. Finite State. Binary analysis and supplier SBOM ingestion are built for that.
You build your own images and apps in GitHub Actions. CRACI records each build and signs the output. Upload the same artifact to Finite State and you have the build record and the binary analysis side by side.
You need a system of record for many products and suppliers. Finite State. CRACI's SBOMs export as CycloneDX or SPDX, formats Finite State accepts through its upload action.
You want to limit what builds can download. CRACI. That control only exists where the build runs.

For the CRA

The Cyber Resilience Act asks manufacturers to identify and document the components in their products, including an SBOM, to handle vulnerabilities through the support period, and, from September 2026, to report actively exploited vulnerabilities. Finite State helps assemble that evidence across a product and its suppliers, with CRA control mapping and reports. CRACI helps by producing per-build evidence of what went into the software you build, with provenance, ongoing monitoring and report export. CRACI automates a significant part of the software supply chain visibility and evidence that manufacturers need for their wider CRA compliance process; it does not make a product compliant on its own. Read what the CRA requires.

Adding CRACI alongside Finite State

Nothing needs to move out of Finite State. Point your build job at runs-on: craci, keep the Finite State upload step, and the same workflow runs on a CRACI runner while CRACI records it. For Yocto, the example in the CRACI docs shows a full BitBake workflow. CRACI supports GitHub Actions only today, so GitLab CI or Jenkins pipelines would need to move to use CRACI runners. See how CRACI works for industrial IoT and consumer electronics.