CRACI vs. Kusari

Die kurze Antwort

Kusari ist eine Plattform für Software-Lieferkettensicherheit des Teams, das GUAC mitentwickelt hat, den Open-Source-Graphen für Lieferketten-Metadaten. Sie baut aus Ihrem Quellcode, SBOMs, VEX-Dokumenten und vorhandenen Scanner-Ausgaben einen laufend aktualisierten Knowledge Graph, ordnet ein, was ausnutzbar ist, prüft Pull Requests und öffnet Fixes. CRACI ist ein GitHub-Actions-Runner. Es zeichnet während des Laufs auf, was jeder Build lädt, kontrolliert, was der Build erreichen kann, und überwacht das Ausgelieferte weiter. Jeder Graph spiegelt die SBOMs wider, die er erhält; CRACI erzeugt SBOMs aus dem Build selbst. Die beiden konkurrieren um dasselbe Budget für die Lieferkette. Für Software, die Sie selbst bauen, deckt CRACI CI, SBOM und Schwachstellenverfolgung in einem Produkt ab.

Auf einen Blick

Kusari und GUAC im Einzelnen

GUAC (Graph for Understanding Artifact Composition) ist ein OpenSSF-Inkubationsprojekt unter der Arbeitsgruppe Supply Chain Integrity, lizenziert unter Apache 2.0. Es führt Software-Sicherheitsmetadaten in einer Graphdatenbank zusammen. Zu seinen dokumentierten Eingaben gehören CycloneDX- und SPDX-SBOMs, in-toto- und SLSA-Attestierungen, OpenVEX- und CSAF-Dokumente, Ergebnisse von OpenSSF Scorecard sowie Daten von OSV und deps.dev. GUAC führt Metadaten zusammen, die andere Tools erzeugen; es führt keine Builds aus.

Die Mitgründer von Kusari haben GUAC gemeinsam mit Google entwickelt, und ein Kusari-Mitgründer ist der Lead Maintainer von GUAC. Laut Kusari nutzt und pflegt das Unternehmen GUAC, SLSA, OpenSSF Scorecard, ClearlyDefined und andere Open-Source-Projekte in seinen kommerziellen Produkten. GUAC hat auch andere Mitwirkende, darunter Google, Red Hat, die Purdue University und Citi. Kusari ist die kommerzielle Plattform, GUAC das Community-Projekt.

Was Kusari gut kann

Ein Graph auf Basis offener Standards. Die Plattform von Kusari nimmt Quellcode, Build-Artefakte, CycloneDX- und SPDX-SBOMs, VEX und vorhandene Scanner-Ausgaben auf, darunter Ergebnisse von Snyk, Black Duck, Prisma Cloud, Dependabot und GitHub Advanced Security. Sie bildet direkte und transitive Abhängigkeiten mit Provenienz und Herkunft ab und zeigt den Blast Radius einer neuen Schwachstelle über Ihren gesamten Bestand.

Weniger, bessere Befunde. Erreichbarkeits- und Ausnutzbarkeitsanalysen suchen nach Belegen dafür, dass verwundbarer Code tatsächlich aufgerufen wird, sodass in der Warteschlange steht, was zählt. AutoFix erzeugt Fix-Pull-Requests und validiert sie, bevor sie Ihr Repository erreichen.

Prüfungen am Pull Request. Kusari Inspector prüft jeden Pull Request auf GitHub oder GitLab auf transitive Schwachstellen, geleakte Secrets, bösartige und per Typosquatting getarnte Pakete, Lizenzrisiken, Abhängigkeiten am Ende ihres Lebenszyklus, unsichere GitHub-Actions-Workflows und verbreitete Code-Schwächen. Laut Kusari lässt sich Inspector kostenlos installieren, ohne Vertriebsgespräch.

Standards und Frameworks. Kusari erzeugt SBOMs und Attestierungen in den Formaten SPDX, CycloneDX und in-toto und nennt die Unterstützung von Frameworks wie EU CRA, FDA 524B, SSDF, IEC 62443 und DORA. Sein Uploader funktioniert mit GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure DevOps, Bitbucket Pipelines und TeamCity.

Worin sich CRACI unterscheidet

Kusari beschreibt seinen Graphen als aus Quellcode und Build-Systemen aufgebaut, während Software entsteht, statt aus fertigen Binärdateien rekonstruiert. Das ist der richtige Ansatz, und genau hier gehen die beiden Produkte auseinander. Die SBOMs von Kusari stammen aus einem Generator: Laut Dokumentation entstehen sie mit waybill, dem Open-Source-SBOM-Toolkit von Kusari, wenn Pull Requests gemergt werden, oder Sie bringen Ihr eigenes Tool mit. Ein Generator liest Lockfiles, Manifeste, Caches und Images. CRACI liest nicht die Dateien des Builds, um abzuleiten, was er genutzt hat. Es ist die Maschine, auf der der Build läuft.

Eine Aufzeichnung, keine Rekonstruktion

Mit einer einzeiligen Änderung an runs-on läuft Ihr Workflow auf CRACI. Ein paketbewusster Proxy zeichnet auf, was jeder Job von Paketquellen herunterlädt, und aus CI-Caches wiederhergestellte Pakete 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. Die Überwachung beginnt bei dem, was der Build tatsächlich geladen hat, und weiß, wo die Lücken sind.

Kontrolle während des Builds

Ein Graph hilft Ihnen, nachträglich zu finden, was betroffen ist. Eine Egress-Richtlinie auf dem Runner entscheidet während des Jobs, welche Hosts er erreichen darf. Richtlinien von CRACI sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen, und sie werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed).

Provenienz und Überwachung aus derselben Aufzeichnung

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht. Es bewertet überwachte SBOMs laufend neu.

CRACI leistet nicht, was Kusari auszeichnet: Es nimmt keine anderen Scanner auf, analysiert keine Erreichbarkeit und prüft Pull Requests nicht auf bösartige Pakete und Code-Schwächen. Es unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap.

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.

Kusari durch CRACI ersetzen

Für die Software, die Sie bauen und ausliefern, deckt CRACI ab, wofür eine Graph-Plattform üblicherweise gekauft wird. Es führt den Build aus, zeichnet die SBOM mit angegebener Vollständigkeit auf, bewertet überwachte SBOMs laufend neu, sobald neue Schwachstellen veröffentlicht werden, führt Befunde über Builds und Repositories hinweg zusammen und lässt Sicherheitsteams sie sichten und jeden an das Team weiterleiten, das für die Behebung zuständig ist. Die Egress-Richtlinie begrenzt von vornherein, was ein Build erreichen kann, und das kann kein Graph.

Seien Sie sich im Klaren darüber, worauf Sie verzichten. Kusari verbindet einen Graphen über viele Scanner und SBOM-Quellen, nimmt VEX auf, analysiert Erreichbarkeit und prüft Pull Requests auf bösartige Pakete, geleakte Secrets und Code-Schwächen. CRACI leistet heute nichts davon und unterstützt derzeit nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. Wenn Ihr Hauptbedarf darin besteht, Befunde aus vielen vorhandenen Tools zu korrelieren, bleibt Kusari die bessere Wahl.

Für den CRA

Der Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, einschließlich einer SBOM, und Schwachstellen zu behandeln, solange ein Produkt unterstützt wird. Die Meldepflicht für aktiv ausgenutzte Schwachstellen gilt ab September 2026. Kusari verbindet SBOMs, VEX und Befunde in einem Graphen und führt den CRA unter den unterstützten Frameworks auf. CRACI erzeugt die Nachweise pro Build und überwacht sie weiter: woraus jedes Release gebaut wurde, mit Provenienz, laufender Überwachung und SBOM-Export als CycloneDX oder SPDX. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen; keines der beiden Tools macht ein Produkt allein konform. Lesen Sie, was der CRA verlangt.

Zu CRACI wechseln

Setzen Sie runs-on: craci in den Workflows, die bauen, was Sie ausliefern. CRACI ersetzt den Runner, nicht GitHub Actions, und Läufe erscheinen weiterhin in der GitHub-Oberfläche. Mehr über SBOM-Generierung während des Builds und Schwachstellenverfolgung.

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