CRACI vs. Exein | Build-Nachweise und Laufzeitsicherheit

Die kurze Antwort

Exein entwickelt Sicherheitsprodukte für eingebettete und vernetzte Geräte. Exein Runtime überwacht und blockiert Bedrohungen direkt auf dem Gerät, und Exein Analyzer scannt Firmware vor dem Release auf Schwachstellen. Der Yocto-Layer von Exein, meta-exein, bringt den Laufzeitagenten in Ihr Image. CRACI ist ein GitHub-Actions-Runner: Ihr Yocto-Build läuft darauf, und CRACI zeichnet auf, was der Build heruntergeladen hat, und begrenzt, wohin er sich verbinden darf. Exein arbeitet am Gerät und an der Firmware, CRACI am Build. Die meisten Teams, die beides brauchen, werden beides einsetzen.

Auf einen Blick

Funktion	CRACI	Exein
Führt Ihre Yocto-Builds aus	BitBake auf Runnern mit bis zu 32 vCPUs	Integriert sich in Ihre bestehende Pipeline
Zeichnet auf, was der Build geladen hat	Vom Runner während jedes Jobs beobachtet	Analysiert die Firmware oder eine von Ihnen bereitgestellte SBOM
Egress-Richtlinie während des Builds	Vor dem Job geprüft, blockiert im Zweifel (fail closed)	Außerhalb des Umfangs
Sicherheitsagent auf dem Gerät		Exein Runtime, auf Basis von eBPF
Yocto-Layer für Ihr Image	CRACI führt den Build aus, fügt dem Image nichts hinzu	meta-exein fügt dem Image Pulsar hinzu
Binäre Firmware-Analyse		Exein Analyzer
Priorisierung nach Erreichbarkeit		Erreichbarkeitsbewertung und LLM-Filterung
SBOM	Aus dem Build, mit Vollständigkeitsstatus	Von Exein Analyzer erzeugt
CRA-Nachweise	SBOMs in CycloneDX oder SPDX, Aufzeichnungen über die API; kein Berichtsexport	Zuordnung von CRA-Nachweisen in Analyzer

Enthalten
Teilweise
Nicht enthalten

Was hinter der Yocto-Integration von Exein steckt

Die beiden Produkte lassen sich leicht verwechseln, weil beide Yocto erwähnen, es lohnt sich also, genau zu sein. meta-exein ist ein Open-Source-Yocto-Layer, der sich so beschreibt: „contains Pulsar and kernel recipes to add the Pulsar security framework to an image“. Sie fügen den Layer zu bblayers.conf hinzu, hängen pulsar an IMAGE_INSTALL an und aktivieren BTF, und Ihr Image wird mit Pulsar ausgeliefert, dem eBPF-basierten Laufzeitsicherheitstool von Exein. Der Layer ist auf Yocto-Releases ab Kirkstone getestet und wurde 2024 ein offizieller Yocto Project Compatible Layer. Exein trat dem Yocto Project 2023 als Platinum Member bei.

Der Layer von Exein ändert also, was auf dem Gerät läuft. Er führt weder Ihren Build aus, noch zeichnet er auf, was der Build geladen hat. Exein sagt außerdem, Exein Analyzer sei „natively integrated into Yocto, Buildroot, and your CI/CD pipeline“, sodass er jeden neuen Build scannt. Das ist eine Analyse der Build-Ausgabe in Ihrer eigenen Pipeline.

Was Exein gut kann

Laufzeitschutz auf dem Gerät. Exein Runtime ist in Rust geschrieben und nutzt eBPF, um bösartiges Verhalten auf Kernel-Ebene zu überwachen und zu blockieren, „the moment it tries to run“. Über eine ganze Flotte hinweg verfolgt es Vorfälle und erzeugt aus der Laufzeit-Telemetrie forensische und Compliance-Berichte. Exein veröffentlicht außerdem Pulsar, „a modular and blazing fast runtime security tool for the IoT, powered by eBPF“, als Open Source.

Firmware-Analyse vor dem Release. Exein Analyzer prüft die fertige Firmware direkt oder nimmt Ihre SBOM auf, wenn die Binärdatei nicht verfügbar ist. Laut Exein deckt er Linux, RTOS, Docker, UEFI, Android und mehr ab und stellt mit Erreichbarkeitsbewertung und LLM-gestützter Filterung ausnutzbare CVEs nach vorn.

Behebung und CRA-Zuordnung. Exein beschreibt eine KI-gestützte Behebung, die in Yocto- und CI/CD-Pipelines läuft, und ordnet Befunde den Anforderungen des Cyber Resilience Act zu.

Worin sich CRACI unterscheidet

Es führt den Build aus

Yocto-Builds sind lang und schwer. CRACI führt BitBake aus Ihrem GitHub-Actions-Workflow auf Runnern mit bis zu 32 vCPUs und 96 GB RAM aus, festgelegt mit cracicorp/setup@v1 und size: "32". Jobs laufen in isolierten virtuellen Maschinen, und die Läufe erscheinen weiterhin in GitHub.

Es zeichnet auf, was der Build geladen hat

Während ein Job läuft, beobachtet CRACI den Datenverkehr zu Paket- und Quell-Hosts und bewahrt ihn als Build-Nachweis auf, mit einem Vollständigkeitsstatus pro Job und pro Cache. Für Yocto ist das eine unabhängige Darstellung dessen, was über das Netzwerk kam, einschließlich dessen, was die SPDX-SBOM aus der Yocto-Klasse create-spdx auslässt: In einem direkten Vergleichsbuild von core-image-sato enthielt die SBOM von CRACI jede Komponente aus der von Yocto, 88 weitere wie Host-Pakete und GitHub Actions sowie eine Package-URL für jede der 653 Rust-Crate-Versionen, die Yocto ohne eine solche aufführt. Quellen, die BitBake aus dem Yocto-Source-Mirror lädt, werden in der CRACI-Job-SBOM erfasst.

Es kontrolliert, wohin sich der Build verbinden darf

BitBake kann seinen Fetcher mit BB_ALLOWED_NETWORKS einschränken. CRACI ergänzt eine Egress-Richtlinie auf dem Runner, die vor dem Start des Jobs validiert wird und im Zweifel blockiert (fail closed), sodass auch ein Skript oder Tool, das den Fetcher umgeht, keinen Host erreicht, den Sie nicht erlaubt haben. Bei einem Verstoß warnt Sie CRACI.

Es überwacht das Ausgelieferte

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs laufend neu.

CRACI bringt nichts auf das Gerät und analysiert keine Binärdateien. Wenn Sie Laufzeitschutz oder einen Scan eines fertigen Images brauchen, ist das das Terrain von Exein.

Ein Inventar dessen, was wo im Einsatz ist

Die Inventaransicht von CRACI zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind, weltweit. Wenn eine neue Schwachstelle bekannt wird, sehen Sie, welche Produkte die betroffene Version ausführen, statt es aus Release Notes und Tabellen zusammenzusuchen.

Wann Sie welches Tool einsetzen und wann beide

Sie wollen Bedrohungen auf Geräten im Feld erkennen und blockieren. Exein Runtime. CRACI hat keine Komponente auf dem Gerät.
Ihre Yocto-Builds laufen auf einem Server unter dem Schreibtisch oder dauern auf kleinen CI-Runnern Stunden. CRACI führt sie über GitHub Actions aus und bewahrt von jedem eine Aufzeichnung auf.
Sie liefern ein Yocto-Image mit meta-exein aus. Bauen Sie es auf CRACI. Der Layer lässt sich wie jeder andere bauen, und CRACI zeichnet auf, was der Build geladen hat.
Sie müssen zeigen, woher die SBOM stammt. Die Runner-Aufzeichnung von CRACI verknüpft die SBOM mit einem bestimmten Build. Der Scan der Ausgabe durch Exein Analyzer ist eine nützliche zweite Sicht.

Für den CRA

Der Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, einschließlich einer SBOM, Schwachstellen während des Unterstützungszeitraums zu behandeln und ab September 2026 aktiv ausgenutzte Schwachstellen zu melden. Exein hilft auf der Geräteseite, mit Firmware-Analyse vor dem Release, Zuordnung von CRA-Nachweisen und Laufzeit-Telemetrie aus dem Feld. CRACI hilft auf der Build-Seite, mit Nachweisen pro Build darüber, was in die Firmware eingeflossen ist, Provenienz, laufender Überwachung und SBOM-Export als CycloneDX oder SPDX. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Hersteller für ihren umfassenderen CRA-Compliance-Prozess brauchen; für sich allein macht es ein Produkt nicht konform. Lesen Sie, was der CRA verlangt.

CRACI in einen Yocto-Workflow aufnehmen

Behalten Sie Ihre Layer, einschließlich meta-exein, und Ihren Exein-Analyzer-Schritt. Setzen Sie runs-on: craci beim Build-Job und wählen Sie eine Runner-Größe. Das Yocto-Beispiel in der CRACI-Dokumentation baut core-image-sato mit dem offiziellen Yocto-Source-Mirror und einer passenden BB_ALLOWED_NETWORKS-Einstellung. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. Sehen Sie, wie CRACI für Industrial IoT und Unterhaltungselektronik funktioniert.