CRACI vs Exein

The short answer

Exein makes security products for embedded and connected devices. Exein Runtime watches and blocks threats on the device itself, and Exein Analyzer scans firmware for vulnerabilities before release. Its Yocto layer, meta-exein, puts the runtime agent into your image. CRACI is a GitHub Actions runner: your Yocto build runs on it, and CRACI records what the build downloaded, limits where it can connect, and signs the result. Exein works on the device and the firmware; CRACI works on the build. Most teams that need both will use both.

At a glance

What Exein's Yocto integration is

The two products are easy to confuse because both mention Yocto, so it is worth being precise. meta-exein is an open-source Yocto layer that "contains Pulsar and kernel recipes to add the Pulsar security framework to an image." You add the layer to bblayers.conf, append pulsar to IMAGE_INSTALL and enable BTF, and your image ships with Pulsar, Exein's eBPF-based runtime security tool. The layer is tested on Yocto releases from Kirkstone onward and became an official Yocto Project Compatible layer in 2024. Exein joined the Yocto Project as a Platinum Member in 2023.

In other words, Exein's layer changes what runs on the device. It does not run your build or record what the build fetched. Exein also says Exein Analyzer is "natively integrated into Yocto, Buildroot, and your CI/CD pipeline" so that it scans every new build, which is analysis of the build output inside your own pipeline.

What Exein does well

Runtime protection on the device. Exein Runtime is written in Rust and uses eBPF to monitor and block malicious behavior at the kernel level, "the moment it tries to run." Across a fleet it traces incidents and generates forensic and compliance reporting from runtime telemetry. Exein also publishes Pulsar, "a modular and blazing fast runtime security tool for the IoT, powered by eBPF," as open source.

Firmware analysis before release. Exein Analyzer inspects the final firmware directly, or ingests your SBOM when the binary is not available. Exein says it covers Linux, RTOS, Docker, UEFI, Android and more, and uses reachability scoring and LLM-powered filtering to put exploitable CVEs first.

Remediation and CRA mapping. Exein describes AI-driven remediation that runs inside Yocto and CI/CD pipelines, and maps findings to Cyber Resilience Act requirements.

Where CRACI is different

It runs the build

Yocto builds are long and heavy. CRACI runs BitBake from your GitHub Actions workflow on runners of up to 32 vCPUs and 96 GB of RAM, set with cracicorp/setup@v1 and size: "32". Jobs run in isolated virtual machines, and the runs still appear in GitHub.

It records what the build fetched

While a job runs, CRACI observes traffic to package and source hosts and keeps it as build evidence, with a completeness state per job and per cache. For Yocto that is an independent account of what came over the network, next to the SPDX SBOM that Yocto's create-spdx class already writes. CRACI does not replace that SBOM. Sources BitBake fetches from the Yocto source mirror are recorded in the CRACI job SBOM.

It controls where the build can connect

BitBake can restrict its fetcher with BB_ALLOWED_NETWORKS. CRACI adds an egress policy at the runner, validated before the job starts and failing closed, so a script or tool that goes around the fetcher still cannot reach a host you did not allow. Violations can be sent by email.

It signs and watches what shipped

Signed provenance (Ed25519 over SHA-512) links each artifact to its build. CRACI aggregates vulnerabilities across builds and repositories, and keeps re-evaluating monitored SBOMs.

CRACI does not put anything on the device and does not analyze binaries. If you need runtime protection or a scan of a finished image, that is Exein's ground.

When to use which, and when to use both

• You want threat detection and blocking on devices in the field. Exein Runtime. CRACI has no on-device component.
• Your Yocto builds run on a server under a desk, or take hours on small CI runners. CRACI runs them from GitHub Actions and keeps a record of each one.
• You ship a Yocto image with meta-exein. Build it on CRACI. The layer builds like any other, and signed provenance ties the protected image to the build that produced it.
• You need to show where the SBOM came from. CRACI's runner record and signed provenance tie the SBOM to a specific build. Exein Analyzer's scan of the output is a useful second view.

For the CRA

The Cyber Resilience Act asks manufacturers to 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. Exein helps on the device side, with pre-release firmware analysis, CRA evidence mapping and runtime telemetry from the field. CRACI helps on the build side, with per-build evidence of what went into the firmware, 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 to a Yocto workflow

Keep your layers, including meta-exein, and your Exein Analyzer step. Set runs-on: craci on the build job and choose a runner size. The Yocto example in the CRACI docs builds core-image-sato with the official Yocto source mirror and a matching BB_ALLOWED_NETWORKS setting. CRACI supports GitHub Actions only today. See how CRACI works for industrial IoT and consumer electronics.