CRACI vs ONEKEY | Firmware Analysis and Build Evidence

The short answer

ONEKEY is a product cybersecurity and compliance platform for connected devices. You upload a firmware image, and it analyzes the binary to find components, known vulnerabilities, likely zero-days and compliance gaps, with no source code needed. CRACI is a GitHub Actions runner that records what each build pulls in while it runs, produces the SBOM from that record, and signs provenance for the result. ONEKEY analyzes the output; CRACI keeps evidence from the build. They fit together well, and neither replaces the other.

At a glance

Capability	CRACI	ONEKEY
Records what the firmware build fetched	Observed by the runner during each job	Analyzes the image after it is built
Runs your CI builds	Jobs run on CRACI runners	Your CI uploads firmware to ONEKEY
Analyzes the finished binary image		Automated binary firmware analysis
Works on firmware you did not build	Needs the build to run on CRACI	No source code or network access needed
Zero-day analysis of binaries		Finds issues like hardcoded credentials
SBOM in CycloneDX and SPDX	From the build, with a completeness state	From the binary, plus SBOM import
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 ONEKEY's documentation
Monitoring after release	Re-evaluates monitored SBOMs continuously	Re-analyzes firmware daily
Guided checks against standards	Evidence and report export, no standards wizard	Compliance Wizard for CRA, IEC 62443 and more
CI systems	GitHub Actions	Documented examples for GitHub, GitLab and Jenkins

Included
Partly
Not included

What ONEKEY does well

Binary analysis without source code. ONEKEY analyzes compiled firmware directly. Its site puts it plainly: "No source code or network access needed." That matters when much of what ships on a device comes from chip vendors, module suppliers and contractors, and you never see their build.

Findings beyond known CVEs. Besides matching components against vulnerability data, ONEKEY runs automated zero-day analysis that looks for issues such as command injection, insecure communication and hardcoded credentials in the binary.

SBOMs from the image. ONEKEY generates an SBOM from the binary, lets you import SBOMs from source scanners or suppliers, and exports CycloneDX and SPDX.

Compliance guidance. The ONEKEY Compliance Wizard walks teams through requirements of the Cyber Resilience Act, IEC 62443-4-2, ETSI EN 303 645 and the Radio Equipment Directive, and exports results for third-party certification.

Monitoring and CI. Its firmware monitoring re-analyzes uploaded firmware daily as new vulnerabilities appear. The ONEKEY docs show how to upload each new build from GitHub, GitLab or Jenkins and fail the pipeline when new findings appear. ONEKEY also maintains unblob, an open-source extraction suite for binary blobs.

Where CRACI is different

A binary scan works backward from the finished image. CRACI works forward from the build, because it is the machine the build runs on.

The build is the source of truth

Your firmware workflow runs on CRACI's runners with a one-line change to runs-on. While a job runs, a package-aware proxy records what it 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. For Yocto, CRACI runs BitBake on runners of up to 32 vCPUs and 96 GB of RAM, and Yocto's own SPDX output stays in place next to CRACI's record. Sources BitBake fetches from the Yocto source mirror are recorded in the CRACI job SBOM.

Control over what the build can reach

An egress policy at the runner decides which hosts a job may connect to. It is validated before the job starts, fails closed, and sends an email alert on a violation. For Yocto it adds a second layer to BitBake's own BB_ALLOWED_NETWORKS.

Provenance and what shipped

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

What CRACI does not do matters just as much here. It does not analyze binaries, so it cannot tell you what is inside a supplier blob your build downloads, only that the build fetched it and from where.

When to use which, and when to use both

You integrate firmware you do not build. ONEKEY. Binary analysis is the way to see inside it.
You build your own Linux image in GitHub Actions. CRACI runs the build, records its inputs and signs the output. Adding ONEKEY gives you a second, independent view of the finished image.
An auditor asks how you know the SBOM matches the product. CRACI's record from the runner answers "what went into this build"; ONEKEY's analysis answers "what is in this image". Together they cross-check each other.
You need guided checks against IEC 62443 or ETSI EN 303 645. ONEKEY has that built in. CRACI exports reports in PDF, HTML, CSV, Excel and JSON for your wider process.

For the CRA

The Cyber Resilience Act asks manufacturers to identify and document the components in their products, including an SBOM, and to handle vulnerabilities for as long as the product is supported. Reporting of actively exploited vulnerabilities applies from September 2026. ONEKEY helps by analyzing the firmware you place on the market and guiding you through requirements. CRACI helps by producing per-build evidence of what went into that firmware, with provenance and ongoing monitoring. 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 ONEKEY

Keep your ONEKEY upload step. Move the firmware job to a CRACI runner by setting runs-on: craci, and the same workflow keeps running in GitHub Actions while CRACI records the build. The upload to ONEKEY then happens from a build you have evidence for. The Yocto example in the CRACI docs shows a full BitBake workflow. CRACI supports GitHub Actions only today, so GitLab or Jenkins pipelines would need to move to use CRACI runners. See how CRACI works for industrial IoT and consumer electronics.