CRACI vs. ONEKEY | Firmware-Analyse und Build-Nachweise

Die kurze Antwort

ONEKEY ist eine Plattform für Produkt-Cybersicherheit und Compliance bei vernetzten Geräten. Sie laden ein Firmware-Image hoch, und die Plattform analysiert die Binärdatei, um Komponenten, bekannte Schwachstellen, wahrscheinliche Zero-Days und Compliance-Lücken zu finden, ganz ohne Quellcode. CRACI ist ein GitHub-Actions-Runner, der während des Laufs aufzeichnet, was jeder Build lädt, und aus dieser Aufzeichnung die SBOM erzeugt. ONEKEY analysiert das Ergebnis; CRACI bewahrt Nachweise aus dem Build auf. Beide passen gut zusammen, und keines ersetzt das andere.

Auf einen Blick

Funktion	CRACI	ONEKEY
Zeichnet auf, was der Firmware-Build geladen hat	Vom Runner während jedes Jobs beobachtet	Analysiert das Image nach dem Build
Führt Ihre CI-Builds aus	Jobs laufen auf CRACI-Runnern	Ihr CI lädt Firmware zu ONEKEY hoch
Analysiert das fertige Binär-Image		Automatisierte binäre Firmware-Analyse
Funktioniert bei Firmware, die Sie nicht gebaut haben	Der Build muss auf CRACI laufen	Ohne Quellcode oder Netzwerkzugriff
Zero-Day-Analyse von Binärdateien		Findet Probleme wie fest codierte Zugangsdaten
SBOM in CycloneDX und SPDX	Aus dem Build, mit Vollständigkeitsstatus	Aus der Binärdatei, dazu SBOM-Import
Egress-Richtlinie während des Builds	Vor dem Job geprüft, blockiert im Zweifel (fail closed)	Außerhalb des Umfangs
Überwachung nach dem Release	Bewertet überwachte SBOMs laufend neu	Analysiert Firmware täglich neu
Geführte Prüfungen anhand von Standards	SBOM-Export und API, kein Berichtsexport oder Standards-Assistent	Compliance Wizard für CRA, IEC 62443 und weitere
CI-Systeme	Heute GitHub Actions; GitLab CI und Jenkins auf der Roadmap	Dokumentierte Beispiele für GitHub, GitLab und Jenkins

Enthalten
Teilweise
Nicht enthalten

Was ONEKEY gut kann

Binäranalyse ohne Quellcode. ONEKEY analysiert kompilierte Firmware direkt. Die eigene Website sagt es klar: „No source code or network access needed.“ Das ist wichtig, wenn vieles, was auf einem Gerät ausgeliefert wird, von Chipherstellern, Modullieferanten und Auftragnehmern stammt und Sie deren Build nie zu sehen bekommen.

Befunde über bekannte CVEs hinaus. Neben dem Abgleich von Komponenten mit Schwachstellendaten führt ONEKEY eine automatisierte Zero-Day-Analyse aus, die in der Binärdatei nach Problemen wie Command Injection, unsicherer Kommunikation und fest codierten Zugangsdaten sucht.

SBOMs aus dem Image. ONEKEY erzeugt eine SBOM aus der Binärdatei, ermöglicht den Import von SBOMs aus Quellcode-Scannern oder von Lieferanten und exportiert CycloneDX und SPDX.

Compliance-Anleitung. Der ONEKEY Compliance Wizard führt Teams durch die Anforderungen des Cyber Resilience Act, von IEC 62443-4-2, ETSI EN 303 645 und der Radio Equipment Directive und exportiert Ergebnisse für die Zertifizierung durch Dritte.

Überwachung und CI. Die Firmware-Überwachung analysiert hochgeladene Firmware täglich neu, da laufend neue Schwachstellen erscheinen. Die ONEKEY-Dokumentation zeigt, wie Sie jeden neuen Build aus GitHub, GitLab oder Jenkins hochladen und die Pipeline fehlschlagen lassen, wenn neue Befunde auftreten. ONEKEY pflegt außerdem unblob, eine Open-Source-Extraktionssuite für Binär-Blobs.

Worin sich CRACI unterscheidet

Ein Binär-Scan arbeitet rückwärts vom fertigen Image. CRACI arbeitet vorwärts vom Build aus, weil es die Maschine ist, auf der der Build läuft.

Der Build ist die Quelle der Wahrheit

Ihr Firmware-Workflow läuft mit einer einzeiligen Änderung an runs-on auf den Runnern von CRACI. Während ein Job läuft, zeichnet ein paketbewusster Proxy auf, was er von Paketquellen herunterlädt, und aus CI-Caches wiederhergestellte Pakete werden fortgeschrieben. Jede SBOM gibt an, wie vollständig sie ist, pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Für Yocto führt CRACI BitBake auf Runnern mit bis zu 32 vCPUs und 96 GB RAM aus. In einem direkten Vergleichs-Build von core-image-sato enthielt die SBOM von CRACI jede Komponente aus Yoctos eigener SPDX-Ausgabe, 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.

Kontrolle darüber, was der Build erreichen kann

Eine Egress-Richtlinie am Runner entscheidet, mit welchen Hosts sich ein Job verbinden darf. Sie wird vor dem Start des Jobs validiert, blockiert im Zweifel (fail closed) und sendet bei einem Verstoß eine Warnung. Für Yocto ergänzt sie BitBakes eigenes BB_ALLOWED_NETWORKS um eine zweite Ebene.

Provenienz und das Ausgelieferte

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

Was CRACI nicht tut, ist hier ebenso wichtig. Es analysiert keine Binärdateien und kann Ihnen daher nicht sagen, was in einem Lieferanten-Blob steckt, den Ihr Build herunterlädt, sondern nur, dass der Build ihn geladen hat und von wo.

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 integrieren Firmware, die Sie nicht selbst bauen. ONEKEY. Binäranalyse ist der Weg, in sie hineinzusehen.
Sie bauen Ihr eigenes Linux-Image in GitHub Actions. CRACI führt den Build aus und zeichnet seine Eingaben auf. ONEKEY liefert zusätzlich eine zweite, unabhängige Sicht auf das fertige Image.
Ein Auditor fragt, woher Sie wissen, dass die SBOM zum Produkt passt. Die Aufzeichnung von CRACI vom Runner beantwortet „Was ist in diesen Build eingeflossen?“; die Analyse von ONEKEY beantwortet „Was steckt in diesem Image?“. Zusammen prüfen sie sich gegenseitig.
Sie brauchen geführte Prüfungen anhand von IEC 62443 oder ETSI EN 303 645. ONEKEY hat das integriert. CRACI exportiert SBOMs als CycloneDX oder SPDX, und seine API liefert Netzwerk-Traces und Provenienz für Ihren umfassenderen Prozess.

Für den CRA

Der Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu ermitteln und zu dokumentieren, einschließlich einer SBOM, und Schwachstellen zu behandeln, solange das Produkt unterstützt wird. Die Meldepflicht für aktiv ausgenutzte Schwachstellen gilt ab September 2026. ONEKEY hilft, indem es die Firmware analysiert, die Sie in Verkehr bringen, und Sie durch die Anforderungen führt. CRACI hilft, indem es pro Build Nachweise darüber erzeugt, was in diese Firmware eingeflossen ist, mit Provenienz und laufender Überwachung. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Hersteller für ihren umfassenderen CRA-Compliance-Prozess brauchen; ein Produkt macht es allein nicht konform. Lesen Sie, was der CRA verlangt.

CRACI neben ONEKEY einsetzen

Behalten Sie Ihren ONEKEY-Upload-Schritt. Verlegen Sie den Firmware-Job mit runs-on: craci auf einen CRACI-Runner, und derselbe Workflow läuft weiter in GitHub Actions, während CRACI den Build aufzeichnet. Der Upload zu ONEKEY erfolgt dann aus einem Build, für den Sie Nachweise haben. Das Yocto-Beispiel in der CRACI-Dokumentation zeigt einen vollständigen BitBake-Workflow. CRACI unterstützt heute nur GitHub Actions, GitLab- oder Jenkins-Pipelines müssten also umziehen, um CRACI-Runner zu nutzen. GitLab CI und Jenkins sind auf der Roadmap. Sehen Sie, wie CRACI für Industrial IoT und Unterhaltungselektronik funktioniert.

Sie wägen mehr als zwei Tools ab? ONEKEY-Alternativen vergleicht neun Optionen nebeneinander.