123% mehr gemeldete CVEs pro Tag in 2026 als im Vorjahr.

Vergleich

CRACI vs. Cybellum

Cybellum erstellt aus den Firmware-Binärdateien ein Modell jedes Produkts und gibt Produktsicherheitsteams einen Ort, an dem sie SBOMs, Schwachstellen, Compliance und Incident Response verwalten. CRACI erstellt seine Aufzeichnung an dem einen Ort, den Sie vollständig kontrollieren: Ihrem eigenen Build.

Aktualisiert am

Die kurze Antwort

Cybellum ist eine Plattform für Produktsicherheit für Gerätehersteller in den Märkten Automobil, Medizintechnik und Industrie. Es analysiert Firmware-Binärdateien, führt sie mit Quellcode und SBOMs von Lieferanten zusammen, gleicht das Ergebnis mit Schwachstellendaten ab und unterstützt die Arbeit, die ein PSIRT nach dem Marktstart leistet: Überwachung, Triage, Untersuchungen und regulatorische Nachweise. CRACI ist ein GitHub-Actions-Runner, der während der Ausführung aufzeichnet, was jeder Build lädt, aus dieser Aufzeichnung die SBOM erzeugt und sie weiter überwacht.

Die erste Frage in jedem PSIRT-Fall lautet, welche Produkte und Versionen die verwundbare Komponente enthalten. Cybellum beantwortet sie durch die Analyse dessen, was Sie ausliefern, egal woher es stammt. CRACI beantwortet sie anhand einer Aufzeichnung dessen, was Ihre eigenen Builds tatsächlich geladen haben. Für Software, die Sie in GitHub Actions bauen, deckt CRACI Inventar, Überwachung und die Triage selbst ab. Für Firmware, die Sie als Binärdateien erhalten, deckt Cybellum Bereiche ab, die CRACI nicht abdeckt.

Auf einen Blick

Funktion CRACI Cybellum
Führt Ihre CI-Builds aus Jobs laufen auf CRACI-Runnern Arbeitet mit Binärdateien, Quellcode und SBOMs
Zeichnet auf, was der Build geladen hat Vom Runner während jedes Jobs beobachtet Führt Binärscans, Quellcode und hochgeladene SBOMs zusammen
Analysiert Firmware-Binärdateien Cyber Digital Twins, aus den Binärdateien erstellt
Funktioniert mit Firmware, die Sie nicht selbst gebaut haben Der Build muss auf CRACI laufen Quellcode optional
Befunde über bekannte CVEs hinaus Zero-Days, Malware und Schwächen im Code
Importiert SBOMs von Lieferanten SBOMs von Herstellern können hinzugefügt werden SPDX, CycloneDX oder CPE-CSV
SBOM in CycloneDX und SPDX Aus dem Build, mit Vollständigkeitsstatus Zusammengeführt, dedupliziert und validiert
Überwachung nach dem Release Bewertet überwachte SBOMs laufend neu Neue Versionen, Branches und Geräte im Feld
Welche Produkte eine neue CVE betrifft Build-Historie und Inventaransicht Betroffene Produkte und Komponenten
Triage und VEX Triage, Zuweisung an Teams und VEX KI-Assistent für die Triage; VEX-Berichte
Egress-Richtlinie während des Builds Vor dem Job geprüft, blockiert im Zweifel (fail closed) Außerhalb seines Bereichs
Regulatorische Vorlagen und Berichte SBOMs in CycloneDX oder SPDX, Aufzeichnungen über die API; kein Berichtsexport FDA PMA, ISO 21434, EU CRA und über 50 Standards
Bereitstellung Verwaltete Runner auf europäischer Infrastruktur; vom Kunden gehostete Runner auf der Roadmap. Public Cloud oder Ihr eigenes Rechenzentrum.
CI-Systeme Heute GitHub Actions; GitLab CI und Jenkins auf der Roadmap Integrationen für GitLab, Jenkins und Bamboo ausgewiesen, dazu Webhooks und API
Preise Bezahlung pro Build-Minute, keine Monatsgebühr Keine Angabe
  • Enthalten
  • Teilweise
  • Nicht enthalten

Was Cybellum gut macht

Die Website von Cybellum
cybellum.com

Analyse der Binärdatei. Die Cyber Digital Twins von Cybellum lassen sich laut Anbieter aus den Binärdateien jedes Produkts oder jeder Komponente extrahieren („can be extracted from the binary files of any product or component“). Die Plattform analysiert die Firmware-Binärdateien jedes Produkts und legt „SBOM, version history, licenses, HW architecture, OS configurations, and more“ offen, also SBOM, Versionshistorie, Lizenzen, Hardwarearchitektur, Betriebssystemkonfiguration und mehr. Den Quellcode fragt sie nur als Zusatz ab: „Have the source code too?“ Das zählt, wenn ein Großteil eines Fahrzeugs oder Medizingeräts Code von Lieferanten ausführt, deren Builds Sie nie sehen.

Eine SBOM aus vielen Quellen. Cybellum kombiniert Daten aus Binärscannern, Quellcode und externen SBOM-Quellen in den Formaten SPDX, CycloneDX oder CPE-CSV, dedupliziert identische Pakete und lässt Teams SBOMs für jedes Produkt, jede Version und jeden Branch automatisch korrigieren, validieren und freigeben, bevor sie als SPDX oder CycloneDX geteilt werden.

Befunde über bekannte CVEs hinaus. Seine Schwachstellendatenbank kombiniert öffentliche und private Feeds, EPSS und Forschungsergebnisse, und Cybellum ergänzt integrierte Engines zur Erkennung von Malware und Schwächen im Code („built-in malware and coding weakness detection engines“). Teams können Bedrohungsmodelle, TARA, Fuzzing- und Pentest-Ergebnisse importieren und dann mit einem KI-Assistenten, dem VM CoPilot, die Triage erledigen.

Für die PSIRT-Arbeit gebaut. Mit seinem Incident-Response-Modul sieht ein Team genau, welche Produkte oder Komponenten von einer neuen Schwachstelle oder Regulierung betroffen sind („see exactly which products or components are affected by a new vulnerability or regulation“). Es erhält eine Workbench zum Anlegen und Verwalten von Untersuchungen, öffnet Tickets und teilt den Schwachstellenstatus bei Bedarf über VEX- oder CSAF-Berichte.

Regulatorische Nachweise. Cybellum verwaltet Nachweise für „FDA PMA, ISO 21434, CRA as well as your own custom policy frameworks“, also auch für eigene Richtlinien-Frameworks, mit vorab zugeordneten Anforderungen aus über 50 Standards, Regulierungen und Best Practices. Es läuft in Public Clouds oder in Ihrem eigenen Rechenzentrum. LG Electronics hat 2021 eine Mehrheitsbeteiligung an Cybellum erworben, und Cybellum besteht als eigene Marke weiter.

Worin sich CRACI unterscheidet

Cybellum geht von Artefakten aus: dem Firmware-Image, dem Quellcode-Baum, der SBOM, die ein Lieferant geschickt hat. CRACI geht vom Build selbst aus, weil der Build auf CRACI läuft.

Beobachtet, nicht abgeleitet

Sie ändern runs-on auf craci, und der Job läuft in einer isolierten virtuellen Maschine auf einem CRACI-Runner. Ein paketbewusster Proxy zeichnet auf, was der Job aus Paketquellen herunterlädt, und Pakete, die aus CI-Caches wiederhergestellt werden, werden mitgeführt. Jede SBOM gibt an, wie vollständig sie ist, pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Firmware-Teams können Yocto auf Runnern mit bis zu 32 vCPUs und 96 GB RAM ausführen. In einem direkten Vergleichsbuild von core-image-sato enthielt die SBOM von CRACI jede Komponente aus der eigenen SPDX-Ausgabe 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 auflistet.

Welche Builds und Produkte eine CVE erreicht hat

CRACI bewahrt jeden früheren Build mit seiner SBOM auf. Wenn ein Advisory erscheint, sehen Sie also, welche Builds die verwundbare Abhängigkeit enthielten, direkt oder transitiv, und wie lange, innerhalb Ihres Aufbewahrungszeitraums. Seine Inventaransicht zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind, weltweit. CRACI bewertet überwachte SBOMs laufend neu, unterstützt VEX und lässt Sicherheitsteams Befunde sichten und jeden an das Team weiterleiten, das für die Behebung zuständig ist. Sie können SBOMs von Herstellern hinzufügen, sodass zugekaufte Komponenten neben Ihren eigenen Builds überwacht werden.

Kontrolle während des Builds

Ein Scan des Ergebnisses kann nicht ändern, was der Build erreichen konnte. Die Egress-Richtlinie von CRACI kann es: Sie blockiert oder erlaubt standardmäßig, wird vor dem Start des Jobs validiert, blockiert im Zweifel (fail closed) und sendet bei einem Verstoß eine Warnung. Policy-Gates können außerdem einen Build stoppen, der eine bestimmte CVE enthält.

Worauf Sie mit CRACI verzichten

CRACI analysiert keine Binärdateien. Es kann Ihnen also nicht sagen, was in einem Blob eines Lieferanten steckt, den Ihr Build herunterlädt, nur dass der Build ihn geladen hat und woher. Es sucht nicht nach Zero-Days, das Scannen von Quellcode auf Schwächen liegt außerhalb seines Bereichs, und es bietet keine geführten Prüfungen gegen Standards und keinen Berichtsexport. Es unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. Es läuft als verwaltete Runner auf europäischer Infrastruktur; vom Kunden gehostete Runner sind auf der Roadmap.

Wann Sie welches einsetzen

  • Der Großteil Ihrer Firmware kommt als Binärdateien von Lieferanten. Cybellum. Die Analyse der Binärdatei ist der Weg, hineinzusehen.
  • Sie bauen Ihre eigene Software und Images in GitHub Actions. CRACI führt den Build aus, zeichnet seine Inputs auf und verfolgt die Schwachstellen im Aufgezeichneten, sodass das Inventar des PSIRT aus dem Build selbst stammt.
  • Sie brauchen Nachweise für regulatorische Einreichungen in der Automobil- oder Medizintechnik. Cybellum hat regulatorische Vorlagen für FDA PMA, ISO 21434 und den EU CRA. CRACI exportiert SBOMs als CycloneDX oder SPDX, und seine API liefert SBOMs, Netzwerk-Traces und Provenienz für Ihren umfassenderen Prozess.
  • Sie wollen begrenzen, was Builds herunterladen können. CRACI. Diese Kontrolle gibt es nur dort, wo der Build läuft.

Für den CRA

Der Cyber Resilience Act verlangt von Herstellern, die Komponenten in ihren Produkten zu ermitteln und zu dokumentieren, einschließlich einer SBOM, Schwachstellen während des Unterstützungszeitraums zu behandeln und ab September 2026 aktiv ausgenutzte Schwachstellen zu melden. Cybellum hilft mit CRA-Vorlagen und Nachweisen über Produkte und Lieferanten hinweg. CRACI hilft mit Nachweisen pro Build darüber, was in die Software eingeflossen ist, die Sie bauen, mit fortlaufender Überwachung und SBOM-Export als CycloneDX oder SPDX, und reicht die CRA-Meldungen in Ihrem Namen ein. 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.

Ihre Builds auf CRACI ausführen

Stellen Sie Ihren Build-Job auf runs-on: craci um, und derselbe Workflow läuft weiter in GitHub Actions, während CRACI ihn aufzeichnet. Für Yocto zeigt das Beispiel in der CRACI-Dokumentation einen vollständigen BitBake-Workflow. Sehen Sie, wie CRACI für Industrial IoT und Unterhaltungselektronik funktioniert.

Neu in der Rolle? Lesen Sie, was ein PSIRT tut, und mehr zu CRACI für PSIRT-Teams. Sie wägen mehr als zwei Tools ab? Siehe PSIRT-Tools im Vergleich und Cybellum-Alternativen.

Sehen Sie die Gefährdung Ihrer Produkte aus dem Build

Buchen Sie eine Demo: Wir lassen einen Ihrer GitHub-Actions-Builds auf CRACI laufen und zeigen, welche Builds eine bekannte CVE erreicht hat.

Demo buchen