CRACI vs. NetRise

Die kurze Antwort

NetRise ist ein Unternehmen für Binäranalyse. Sein Produkt Turbine analysiert Firmware, Container-Images und Anwendungs-Binärdateien, um aus dem kompilierten Code eine SBOM zu erzeugen und darin Risiken zu finden, darunter Schwachstellen, offengelegte Secrets, Fehlkonfigurationen und Kryptografie. Dragos gab am 21. September 2026 bekannt, NetRise übernommen zu haben. CRACI ist ein GitHub-Actions-Runner, der während des Laufs aufzeichnet, was jeder Build lädt, aus dieser Aufzeichnung die SBOM erzeugt und sie nach dem Release überwacht. NetRise analysiert das Ergebnis, auch bei Software, die Sie nicht gebaut haben; CRACI bewahrt Nachweise aus den Builds auf, die Sie ausführen. Für ein PSIRT decken beide unterschiedliche Bereiche ab.

Auf einen Blick

Was NetRise gut kann

SBOMs aus dem kompilierten Code. NetRise Turbine erzeugt „a complete, binary-derived SBOM from the software itself“, einschließlich statisch gelinkter und eingebetteter Abhängigkeiten. Es deckt Firmware, Container-Images und Anwendungs-Binärdateien ab, bis hinunter zu Kerneln, RTOS, Treibern und Firmware unterhalb der Anwendungsschicht. So blicken Sie in Software von Chipherstellern, Modullieferanten und anderen Anbietern, deren Builds Sie nie zu sehen bekommen.

Risiken, die ein CVE-Scan nicht zeigt. Turbine meldet Secrets, öffentliche und private Schlüssel, Zertifikate und Fehlkonfigurationen, die im Artefakt mit ausgeliefert werden, dazu Lizenzprobleme und ein Kryptografie-Inventar für die Post-Quanten-Bereitschaft. NetRise ZeroLens sucht in kompilierter Software nach Schwächen, bevor sie ausgenutzt werden.

Priorisierung. Turbine prüft, ob ein nachvollziehbarer Ausführungspfad einen laufenden Einstiegspunkt mit einer verwundbaren Komponente verbindet, und zeigt Signale zur Ausnutzbarkeit wie den CISA-KEV-Status. Laut NetRise durchsucht die Plattform laufend die NVD, den CISA-KEV-Katalog, Gruppen von Bedrohungsakteuren und Botnetze, um Erkenntnisse zur Ausnutzbarkeit zu gewinnen.

Lieferanten-SBOMs und Integrationen. NetRise unterstützt Import, Anreicherung, Normalisierung und Export von SPDX und CycloneDX, sodass sich SBOMs aus mehreren Quellen zusammenführen lassen. Es bietet eine GraphQL-API für CI/CD und führt Integrationen mit Jira, ServiceNow, Splunk, Armis, Brinqa, Nucleus Security, GitHub und Google Cloud auf.

Open-Source-Herkunft. NetRise Provenance betrachtet Herkunft, Maintainer und Repository-Gesundheit von Open-Source-Komponenten und blockiert bösartige und richtlinienwidrige Pakete dort, wo Entwickler sie beziehen, auch in CI/CD und KI-Coding-Assistenten.

Nun Teil von Dragos. Laut der Mitteilung von Dragos ergänzt NetRise den Einblick in Firmware und Software, die auf Geräten der Betriebstechnik laufen, und die Führung von NetRise wird es in die Dragos Platform integrieren und bestehende Kunden weiter betreuen. Finanzielle Details wurden nicht bekannt gegeben.

Worin sich CRACI unterscheidet

Eine Binäranalyse arbeitet rückwärts von dem, was ausgeliefert wurde. CRACI arbeitet vorwärts vom Build aus, weil der Build auf CRACI läuft.

Der Build ist die Quelle der Wahrheit

Ihr 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.

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. Ein Scan des Ergebnisses kann nicht ändern, was der Build erreichen konnte.

Von der CVE zu den betroffenen Produkten

CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs laufend neu, sobald Advisories erscheinen. Der Build-Verlauf zeigt, welche Builds eine verwundbare Abhängigkeit enthielten, direkt oder transitiv, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren, und die Inventaransicht zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind. Sicherheitsteams sichten Befunde und leiten jeden an das Team weiter, das für die Behebung zuständig ist, VEX wird unterstützt, und Policy-Gates können einen Build blockieren, der eine bestimmte CVE enthält. Die API liefert SBOMs, Netzwerk-Traces und Provenienz.

Was CRACI nicht tut, ist ebenso wichtig. Es analysiert keine Binärdateien und kann daher weder in Firmware blicken, die Sie nicht gebaut haben, noch in einen Lieferanten-Blob, den Ihr Build herunterlädt; es sieht nur, dass der Build ihn geladen hat und von wo. Sie können Hersteller-SBOMs ergänzen, damit deren Komponenten überwacht werden, doch ohne SBOM brauchen Sie ein Binäranalyse-Tool wie NetRise. CRACI hat keine Erreichbarkeitsanalyse und sucht im Ergebnis nicht nach Secrets oder Fehlkonfigurationen.

Was ein PSIRT von beiden braucht

Ein Product Security Incident Response Team muss wissen, was in jedem Produkt ausgeliefert wird, einschließlich Firmware Dritter, bei einer neuen Schwachstelle die betroffenen Produkte finden, nach dem Release weiter überwachen, Befunde sichten und angeben, welche Produkte nicht betroffen sind, oft mit VEX.

• Firmware und Binärdateien Dritter, die Sie erhalten. NetRise. Binäranalyse ist der einzige Weg, in sie hineinzusehen, wenn der Lieferant keine SBOM mitliefert.
• Firmware und Software, die Sie in GitHub Actions bauen. CRACI zeichnet jeden Build während des Laufs auf und bewahrt den Verlauf auf, welche Builds eine Komponente enthielten.
• Eine lange Liste von Befunden priorisieren. Die Erreichbarkeits- und Ausnutzbarkeitssignale von NetRise. CRACI zeigt, dass ein verwundbares Paket im Build war, nicht, ob Ihr Code es aufruft.
• Einen Befund an das Team weiterleiten, das für die Behebung zuständig ist. Triage und Weiterleitung von CRACI arbeiten mit den Builds, die es aufzeichnet; NetRise bindet Jira und ServiceNow an.

Siehe CRACI für PSIRT-Teams und PSIRT-Tools im Vergleich.

Wann Sie welches Tool einsetzen und wann beide

• Das meiste, was Sie ausliefern, stammt von Lieferanten. NetRise. Es analysiert Software, die Sie kaufen, ebenso wie Software, die Sie bauen.
• Sie bauen Ihr eigenes Linux-Image oder Ihre Apps in GitHub Actions. CRACI führt den Build aus und zeichnet seine Eingaben auf. Eine Analyse desselben Images in NetRise liefert eine zweite, unabhängige Sicht auf das Ausgelieferte.
• Sie betreiben Geräteflotten der Betriebstechnik. NetRise, nun innerhalb von Dragos, zielt auf die Firmware und Software, die auf diesen Geräten läuft. CRACI ist für Teams gedacht, die die Software bauen.
• 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 ihrer Produkte zu dokumentieren, einschließlich einer SBOM, Schwachstellen während des Unterstützungszeitraums zu behandeln und seit dem 11. September 2026 aktiv ausgenutzte Schwachstellen zu melden. NetRise adressiert den CRA mit Release-Build-SBOMs aus dem kompilierten Artefakt, Schwachstellenbehandlung und Patch-Verifizierung über Versionen hinweg sowie Berichtsausgaben für Konformitätsnachweise. CRACI erzeugt pro Build Nachweise darüber, was in die von Ihnen gebaute Software eingeflossen ist, überwacht sie 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; ein Produkt macht es allein nicht konform. Lesen Sie, was der CRA verlangt.

CRACI neben NetRise einsetzen

Aus NetRise muss nichts herausgelöst werden. Verlegen Sie den Build-Job mit runs-on: craci auf einen CRACI-Runner, und derselbe Workflow läuft weiter in GitHub Actions, während CRACI den Build aufzeichnet. Das Yocto-Beispiel in der CRACI-Dokumentation zeigt einen vollständigen BitBake-Workflow. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. Sehen Sie, wie CRACI für Industrial IoT funktioniert.

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