CRACI vs Cybellum

The short answer

Cybellum is a product security platform for device manufacturers in automotive, medical and industrial markets. It analyzes firmware binaries, merges them with source code and supplier SBOMs, matches the result against vulnerability data, and supports the work a PSIRT does after launch: monitoring, triage, investigations and regulatory evidence. CRACI is a GitHub Actions runner that records what each build pulls in while it runs, produces the SBOM from that record, and keeps monitoring it.

The first question in every PSIRT case is which products and versions contain the vulnerable component. Cybellum answers it from analysis of what you ship, wherever it came from. CRACI answers it from a record of what your own builds actually fetched. For software you build in GitHub Actions, CRACI covers the inventory, the monitoring and the triage itself. For firmware you receive as binaries, Cybellum covers ground CRACI does not.

At a glance

What Cybellum does well

Analysis of the binary. Cybellum's Cyber Digital Twins "can be extracted from the binary files of any product or component." The platform analyzes each product's firmware binaries to reveal "SBOM, version history, licenses, HW architecture, OS configurations, and more," and asks only as an extra: "Have the source code too?" That matters when much of a vehicle or medical device runs code from suppliers whose builds you never see.

One SBOM from many sources. Cybellum combines "data from binary scanners, source code and external SBOM sources in SPDX, CycloneDX or CPEs CSV formats," deduplicates identical packages, and lets teams auto-fix, validate and approve SBOMs for any product, version or branch before sharing them as SPDX or CycloneDX.

Findings beyond known CVEs. Its vulnerability database combines public and private feeds, EPSS and research findings, and Cybellum adds "built-in malware and coding weakness detection engines." Teams can import threat models, TARA, fuzz and pen test results, then triage with an AI assistant, the VM CoPilot.

Built for PSIRT work. Its incident response module lets a team "see exactly which products or components are affected by a new vulnerability or regulation," gives it "a workbench for creating and managing investigations," opens tickets, and shares vulnerability status "via VEX/CSAF reports as needed."

Regulatory evidence. Cybellum manages evidence for "FDA PMA, ISO 21434, CRA as well as your own custom policy frameworks," with pre-mapped requirements from "50+ standards, regulations, and best practices." It runs on public clouds or in your own datacenter. LG Electronics bought a majority stake in Cybellum in 2021, and Cybellum continues as its own brand.

Where CRACI is different

Cybellum starts from artifacts: the firmware image, 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. In a side-by-side build of core-image-sato, CRACI's SBOM had every component in Yocto's own SPDX output, 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.

Which builds and products a CVE reached

CRACI keeps every past build with its SBOM, so when an advisory lands you can see which builds contained the vulnerable dependency, direct or transitive, and for how long, within your retention period. Its inventory view shows exactly which software versions are deployed to which products, globally. CRACI re-evaluates monitored SBOMs continuously, supports VEX, and lets security teams triage findings and route each one to the team that owns the fix. You can add vendor SBOMs, so bought-in components are monitored next to your own builds.

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 alert on a violation. Policy gates can also stop a build that contains a specific CVE.

What you give up with CRACI

CRACI 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. It does not look for zero days, scanning source code for coding weaknesses is out of its scope, and it has no guided checks against standards and no report export. It supports GitHub Actions only today, with GitLab CI and Jenkins on the roadmap, and runs as managed runners on European infrastructure, with customer-hosted runners on the roadmap.

When to use which

• Most of your firmware comes from suppliers as binaries. Cybellum. Analysis of the binary is the way to see inside it.
• You build your own software and images in GitHub Actions. CRACI runs the build, records its inputs, and tracks the vulnerabilities in what it recorded, so the PSIRT's inventory comes from the build itself.
• You need evidence for automotive or medical regulatory submissions. Cybellum has regulatory templates for FDA PMA, ISO 21434 and the EU CRA. CRACI exports SBOMs as CycloneDX or SPDX, and its API returns SBOMs, network traces and provenance, for your wider process.
• 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. Cybellum helps with CRA templates and evidence across products and suppliers. CRACI helps by producing per-build evidence of what went into the software you build, with ongoing monitoring and SBOM export as CycloneDX or SPDX, and it submits the CRA notifications on your behalf. 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.

Running your builds on CRACI

Point your build job at runs-on: craci and the same workflow keeps running in GitHub Actions while CRACI records it. For Yocto, the example in the CRACI docs shows a full BitBake workflow. See how CRACI works for industrial IoT and consumer electronics.

New to the role? Read what a PSIRT does and CRACI for PSIRT teams. Weighing more than two tools? See PSIRT tools compared and Cybellum alternatives.