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 and limits where it can connect. 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, including what the SPDX SBOM from Yocto's create-spdx class leaves out: in a side-by-side build of core-image-sato, CRACI's SBOM had every component Yocto's did, 88 more such as host packages and GitHub Actions, and a package URL for each of the 653 Rust crate versions Yocto lists without one. 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. CRACI alerts you on a violation.

It watches what shipped

The API returns SBOMs, network traces and provenance. 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.

An inventory of what is deployed where

CRACI's inventory view shows exactly which software versions are deployed to which products, globally. When a new vulnerability lands, you can see which products run the affected version instead of piecing it together from release notes and spreadsheets.

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 CRACI records what the build fetched.
• You need to show where the SBOM came from. CRACI's runner record ties 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 SBOM export as CycloneDX or SPDX. 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, with GitLab CI and Jenkins on the roadmap. See how CRACI works for industrial IoT and consumer electronics.