Was CRACI in Ihrem Stack ersetzt und was es ergänzt

Die kurze Antwort: was wechselt und was bleibt

Ordnen Sie Ihren eigenen Stack mit dieser Tabelle ein. Jede Zeile ist eine Aufgabe, die heute ein Tool in Ihrem Stack erledigt, was diese Aufgabe sehen muss und ob CRACI sie von seiner Position aus übernimmt.

Aufgabe in Ihrem Stack	Was die Aufgabe sehen muss	CRACI	Was Sie behalten und warum
CI-Runner für Linux-Jobs auf GitHub Actions: GitHub-gehostet, von einem Drittanbieter oder eine selbst gehostete Flotte	Einen Ort, an dem der Job läuft	Ersetzt	Runner für Windows, macOS, GitHub Enterprise Server und andere CI-Systeme als GitHub Actions, die CRACI heute nicht unterstützt
Netzwerküberwachung oder Egress-Agents auf Runnern, die Sie behalten	Den ausgehenden Datenverkehr des Jobs	Ersetzt auf CRACI Runnern	Agents auf Runnern, die Sie anderswo behalten
SBOM-Generatoren in der CI, Team für Team: Manifest-, Lockfile- oder Image-Scanner, mit denen SBOMs erzeugt werden	Was der Build tatsächlich geladen hat	Ersetzt für Builds auf CRACI	Generatoren für Software, die Sie nicht auf CRACI bauen, etwa Images, die Sie beziehen und nie selbst bauen
Yoctos integrierte SBOM-Generierung (create-spdx) für die Abdeckung der Lieferkette	Jede Quelle und jedes Tool, das der BitBake-Build geladen hat	Ersetzt für die Abdeckung der Lieferkette	create-spdx, wenn Sie auf seine Rezept-Metadaten angewiesen sind: angewendete Patches und als behoben markierte CVEs
Schwachstellen-Tracking auf Basis von SBOMs: SBOMs hochladen, Advisories abgleichen, neue beobachten	Eine genaue, aktuell gehaltene SBOM pro Release	Ersetzt für Builds auf CRACI; Hersteller-SBOMs lassen sich hinzufügen	Ein spezialisiertes Tool, wenn Sie brauchen, was CRACI nicht bietet: Erreichbarkeitsanalyse, Behebungskennzahlen wie MTTR oder Fristen pro Schweregrad
SBOMs und Komponentenlisten in Tabellen	Eine genaue, aktuell gehaltene SBOM pro Release	Ersetzt	Nichts
Prüfung deklarierter Lizenzen und Lizenzrichtlinien	Die deklarierte Lizenz jeder Komponente	Teilweise	Lizenzscans auf Volltext- und Snippet-Ebene, Lizenzhinweise
SAST und Code-Scanning	Ihren Quellcode	Ergänzt	Behalten; es läuft unverändert als Workflow-Schritt auf einem CRACI Runner
Secret-Scanning und Push-Schutz	Ihr Repository und Ihre Commits	Ergänzt	Behalten
DAST und API-Tests	Ihren laufenden Dienst	Ergänzt	Behalten
Binär- und Firmware-Analyse von Binärdateien Dritter	Eine fertige Binärdatei, die Sie nicht gebaut haben	Ergänzt	Behalten
Snippet- und Signatur-Scanning für kopierten oder eingebundenen Code	Dateiinhalte im Repository	Ergänzt	Behalten
Priorisierung nach Erreichbarkeit	Ihren Aufrufgraphen	Ergänzt	Behalten, wenn Sie darauf angewiesen sind
IaC-, Cluster- und Fehlkonfigurations-Scanning	Konfiguration und laufende Infrastruktur	Ergänzt	Behalten
CI/CD-Posture-Prüfungen der Workflow-Konfiguration	Workflow-Dateien und Einstellungen	Ergänzt	Behalten
Ticketing, PSIRT-Fallbearbeitung, Veröffentlichung von Advisories	Ihren Prozess	Ergänzt	Behalten
Compliance-Automatisierung: Nachweise für SOC 2- oder ISO 27001-Audits sammeln	Ihre Kontrollen über Systeme hinweg	Ergänzt	Behalten; die Aufzeichnungen von CRACI sind Nachweise, die es sammeln kann

Vorher und nachher

Vorher: GitHub-gehostete Runner, in jedem Team-Workflow ein anderer SBOM-Generator, Yoctos create-spdx, das Build-Zeit kostet, und SBOMs, die in einen Tracker oder eine Tabelle hochgeladen werden, umgeben von Code-Scanning, Secret-Scanning, Binäranalyse und Ticketing. Nachher: CRACI Runner, die jeden Job ausführen, seine Egress-Richtlinie durchsetzen, seine SBOM aufzeichnen und sie überwachen. Die Tools, die Code, Repositories, Binärdateien und Ihren Prozess lesen, bleiben unverändert.

Was CRACI ersetzt und warum

Jede dieser Aufgaben fällt während des Builds an. CRACI kann sie übernehmen, weil dort der Build läuft. Zu jeder Aufgabe: der Mechanismus, worauf Sie verzichten, und ein Beispiel.

Ihre Runner

CRACI ist ein Runner für GitHub Actions. Sie ändern runs-on auf craci, und die Läufe erscheinen weiterhin in GitHub wie jeder andere Actions-Job. Jeder Job erhält eine eigene virtuelle Maschine, unter Linux x86-64 oder ARM64, in einer Größe von 1 bis 32 vCPUs, sekundengenau abgerechnet. Sie müssen keine Workflows umschreiben: Ihre bestehenden Schritte laufen weiter, Scan-Schritte eingeschlossen.

CRACI berechnet nur Build-Minuten: $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPUs), sekundengenau abgerechnet, ohne Monatsgebühr und ohne Gebühr pro SBOM. Damit gehört es zu den günstigsten CI-Runnern. Builds laufen etwa doppelt so schnell wie auf GitHub-gehosteten Runnern, dank schnellerer Hardware, kürzerer Wartezeiten und Caching.

Runner, pro Minute	CRACI	GitHub-gehostet	Unterschied
2 vCPU x64	$0.004	$0.006	CRACI etwa 33 % günstiger
2 vCPU ARM64	$0.004	$0.005	CRACI 20 % günstiger
32 vCPU x64	$0.064	$0.082	CRACI etwa 22 % günstiger
32 vCPU ARM64	$0.064	$0.050	CRACI 28 % teurer

GitHub-Listenpreise mit Stand September 2026. GitHub rundet jeden Job auf eine volle Minute auf; CRACI rechnet sekundengenau ab. Beispiel: Ein 10-minütiger Build auf einem GitHub-gehosteten x64-Runner mit 2 Kernen kostet $0.060. Bei etwa doppelter Geschwindigkeit dauert er auf einem CRACI Runner mit 2 vCPUs 5 Minuten und kostet $0.020, etwa 67 % weniger. Siehe Preise und Preise für CI-Runner.

Worauf Sie verzichten. Windows- und macOS-Runner, andere CI-Systeme und vom Kunden gehostete Runner sind heute nicht verfügbar; GitLab CI, Jenkins, Windows, macOS und vom Kunden gehostete Runner sind auf der Roadmap. GitHub Enterprise Server wird nicht unterstützt. Die Runner werden verwaltet und laufen auf europäischer Infrastruktur. Wenn Sie verwaltete Runner gegen Ihre eigene Flotte abwägen, lesen Sie verwaltete vs. selbst gehostete Runner.

Egress-Agents auf Runnern, die Sie behalten

Ein Egress-Agent beobachtet oder begrenzt den Datenverkehr eines Runners, den jemand anderes betreibt. Bei CRACI setzt der Runner selbst die Egress-Richtlinie durch: standardmäßig verweigern oder erlauben, 24 integrierte Presets für Softwarequellen, typisierte eigene Quellen für Paket-Registries und Git sowie explizite Netzwerkregeln. Die Richtlinie wird vor dem Start des Jobs validiert und schlägt sicher fehl (fail closed), und CRACI alarmiert bei Richtlinienverstößen. Auf CRACI Runnern ist kein separater Agent nötig.

Beispiel: Eine kompromittierte Abhängigkeit versucht, die Secrets des Jobs an einen Host zu senden, den der Build nie gebraucht hat. Mit einer Default-Deny-Richtlinie wird die Verbindung blockiert, selbst bei einem Angriff, den noch niemand gesehen hat, denn die Richtlinie erlaubt nur, was der Build braucht, statt nach bekannten schädlichen Hosts zu suchen.

Worauf Sie verzichten. Die Richtlinie gilt für Jobs auf CRACI Runnern. Runner, die Sie anderswo behalten, brauchen weiterhin ihre eigene Kontrolle.

Der SBOM-Generator in jedem Team-Workflow

Ein Generator liest die Dateien, die vor ihm liegen, etwa ein Manifest, ein Lockfile oder ein Image, und rekonstruiert, was eingeflossen ist. Verschiedene Generatoren liefern aus demselben Checkout verschiedene Listen, und Teams wählen meist ihren eigenen. Am Ende hat die Organisation mehrere Inventare, die nicht zueinander passen.

CRACI zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich der aus CI-Caches wiederhergestellten Pakete, sowie die versteckten Abhängigkeiten, die Lockfile-basierte Tools übersehen: Code, den npm-Install-Hooks herunterladen, Rust-Build-Skripte, die zur Build-Zeit herunterladen, und das Basis-Image mit seinen Betriebssystem-Layern in einem Container-Build. Jede Komponente in der SBOM war im Build. Die SBOM jedes Jobs gibt ihre Vollständigkeit an, als Complete, Complete with connections, Incomplete, Unavailable oder Not recorded, sodass eine Lücke sichtbar ist, statt unbemerkt zu bleiben. Das Ergebnis ist ein einziges Inventar für jedes Repository, das auf CRACI baut, exportiert als CycloneDX oder SPDX. Heute aufgezeichnete Ökosysteme: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen, dazu Yocto- und OpenEmbedded-Downloads.

Beispiel: expressjs/express 5.2.1 committet kein Lockfile. Ein Generator, der Abhängigkeiten aus Lockfiles auflöst, hat dort nichts aufzulösen und kann trotzdem ein Dokument liefern, das keine der in package.json deklarierten npm-Abhängigkeiten aufführt. Ein Build desselben Projekts auf CRACI zeichnet die Pakete auf, die npm install geladen hat. Mehr zur Methode unter SBOMs zur Build-Zeit und SCA- und SBOM-Tools im Vergleich; für einen selbst gebauten Generator-Stack siehe den DIY-SBOM-Stack.

Worauf Sie verzichten. Ökosysteme, die CRACI noch nicht aufzeichnet. Maven und Java sind auf der Roadmap, und alles, was nicht in der obigen Liste steht, ist nicht abgedeckt. Behalten Sie für diese Builds einen Generator.

Yoctos integrierte SBOM-Generierung

Yocto schreibt über create-spdx eine eigene SPDX-SBOM und ist dabei gründlich, was BitBake baut. Was außerhalb der BitBake-Metadaten passiert, sieht es nicht. CRACI führt den BitBake-Build aus und zeichnet auf, was er geladen hat. In einem direkten Vergleichs-Build von core-image-sato auf einem nativen ARM64-Runner mit 32 vCPUs enthielt die SBOM von CRACI jede Komponente aus Yoctos SBOM, dazu 88, die dort fehlten: 23 Host-Pakete auf der Build-Maschine, 10 GitHub-Quellen, darunter die GitHub Action actions/upload-artifact, und 55 weitere Quellen und Tools, die während des Builds geladen wurden. Sie verzeichnete alle 653 Rust-Crate-Versionen mit pkg:cargo-Package-URLs, sodass sie mit Advisories abgeglichen werden können. Der Build ohne Yoctos SBOM-Generierung brauchte 43 % weniger Zeit: etwa $9.96 gegenüber $5.68 pro Build zum Preis von CRACI.

Worauf Sie verzichten. Yoctos SPDX enthält Rezept-Metadaten, die CRACI nicht aufzeichnet: die angewendeten Patches und die als behoben markierten CVEs. Wenn Sie darauf angewiesen sind, lassen Sie create-spdx eingeschaltet. Methode und vollständiger Vergleich stehen unter Yocto-Builds auf CRACI.

Aus SBOMs wird Schwachstellen-Tracking

Ein eigenständiger Tracker muss mit einer SBOM gefüttert werden und vertraut dem, was er bekommt. CRACI erzeugt die SBOM und führt die Aufzeichnung. Überwachte SBOMs werden laufend neu bewertet, sobald neue Advisories erscheinen. Die Build-Historie zeigt, welche Builds eine verwundbare Abhängigkeit enthielten, direkt oder transitiv, sodass Sie wissen, in welchem Zeitraum Sie betroffen waren, im Rahmen der Aufbewahrungsdauer Ihres Plans. Befunde werden dem Team zugewiesen, dem die Behebung gehört, CRACI benachrichtigt die zuständigen Personen über eine Schwachstelle und ihren Schweregrad, und Policy Gates können einen Build aufgrund von Befunden blockieren, auch einen Build, der eine bestimmte CVE enthält. VEX wird unterstützt. Hersteller-SBOMs lassen sich hinzufügen, sodass zugekaufte Komponenten zusammen mit Ihren eigenen Builds überwacht werden.

Beispiel: Für ein Crate, das einer Ihrer Dienste vor drei Monaten einkompiliert hat, erscheint ein Advisory. CRACI gleicht es mit jeder überwachten SBOM ab und zeigt, welche Builds diese Version enthielten, ohne dass jemand etwas erneut hochlädt.

Worauf Sie verzichten. CRACI bietet keine Erreichbarkeitsanalyse und keine Behebungskennzahlen wie MTTR, Fristen pro Schweregrad oder Backlog-Trends. Wenn Sie darauf angewiesen sind, behalten Sie das Tool, das sie liefert. Den vollen Funktionsumfang finden Sie unter Schwachstellen-Tracking.

Die Tabelle

Für Teams ohne SBOM-Tooling ersetzt CRACI die Handarbeit: Jemand kopiert vor einem Release oder Audit Abhängigkeitslisten in eine Tabelle. Ein Build auf CRACI erzeugt die SBOM als Nebenprodukt der Ausführung, die Liste existiert also für jeden Build und nicht nur für die, an die jemand gedacht hat.

Was CRACI ergänzt und wie

Diese Tools lesen Dinge, die CRACI nie liest. CRACI liest Ihren Quellcode nicht nach Fehlern durch, testet keine laufenden Dienste und analysiert keine Binärdateien, die es nicht gebaut hat. Sie laufen weiter wie bisher.

Tools, die Ihren Code und Ihr Repository lesen

SAST, Secret-Scanning und Push-Schutz, Snippet- und Signatur-Scanning, IaC-Scanning und CI/CD-Posture-Prüfungen untersuchen alle Ihren Code, Ihre Commits oder Ihre Konfiguration. Schritte in Ihrem Workflow laufen unverändert auf einem CRACI Runner, und Funktionen auf Repository-Ebene sind nicht betroffen, weil sie nie auf dem Runner liefen. Ein Code-Scanning-Schritt kann im selben Job wie Ihr Build stehen. SAST liegt bewusst außerhalb des Umfangs: Es gibt viele hervorragende SAST-Tools, die neben CRACI laufen. Wie sich die beiden Arten von Befunden unterscheiden, lesen Sie unter SAST vs. SCA.

Tools, die prüfen, was Sie nicht gebaut haben

Binär- und Firmware-Analyse von Zulieferer-Binärdateien, Scanner für Images, die Sie beziehen, aber nie bauen, und DAST gegen laufende Dienste betrachten alle etwas, das anderswo gebaut wurde oder bereits läuft. CRACI zeichnet Builds auf; eine Binärdatei von einem Zulieferer wurde irgendwo gebaut, wo CRACI nie hingesehen hat. Wenn Ihnen der Zulieferer eine SBOM gibt, kann CRACI sie zusammen mit Ihren eigenen Builds überwachen.

Priorisierung nach Erreichbarkeit liest Ihren Aufrufgraphen, den CRACI nicht analysiert. Behalten Sie sie, wenn Sie darauf angewiesen sind; was sie leisten kann und was nicht, lesen Sie unter Erreichbarkeitsanalyse.

Prozesssysteme

Ticketing, PSIRT-Fallbearbeitung, Veröffentlichung von Advisories und Plattformen für Compliance-Automatisierung steuern Ihren Prozess über viele Systeme hinweg. CRACI leitet Befunde an das zuständige Team weiter und hält die Nachweise aus dem Build vor; für den Rest behalten Sie Ihre Prozess-Tools. Aufzeichnungen verlassen CRACI als CycloneDX- oder SPDX-SBOMs und über die API, die SBOMs, Netzwerk-Traces und Provenienzdaten liefert. Für die Audit-Seite siehe SBOM-Prüfungen für SOC 2. Für Lizenzarbeit über deklarierte Lizenzen hinaus, etwa Hinweise und Volltextprüfung, siehe Open-Source-Lizenz-Compliance. CRACI führt die deklarierte Lizenz jeder Komponente und setzt Lizenzrichtlinien durch, bis hin zum Blockieren eines Builds wegen einer Lizenz.

So finden Sie die Ablösungspunkte in Ihrem eigenen Stack

Fünf Fragen, die Sie an einem Nachmittag beantworten können. Jede Antwort zeigt, ob eine Position in Ihrem Stack wechselt.

1. Laufen Ihre Builds auf GitHub Actions unter Linux? Wenn ja, wechseln die Runner. Wenn nicht, löst CRACI heute nichts ab.
2. Wer erzeugt heute SBOMs, und wie viele verschiedene Generatoren sind im Einsatz? Jeder Generator in einem Repository, das Sie zu CRACI verlagern, ist eine Position, die entfällt.
3. Bauen Sie Yocto-Images? Wenn ja, prüfen Sie, ob jemand auf die angewendeten Patches und behobenen CVEs in der Ausgabe von create-spdx angewiesen ist, bevor Sie es abschalten.
4. Wohin gehen SBOMs, nachdem sie erzeugt wurden: in einen Tracker, eine Tabelle, nirgendwohin? Dieses Tool oder dieser Prozess ist die zweite Position, die entfällt, es sei denn, Sie brauchen von dort Erreichbarkeit oder Behebungskennzahlen.
5. Welche Ihrer Sicherheitstools lesen Code, Repositories oder Binärdateien Dritter? Die bleiben. Schreiben Sie sie auf, damit niemand erwartet, dass CRACI sie ersetzt.

Ein durchgerechnetes Beispiel

Ein fiktiver Gerätehersteller, der auf keinem realen Unternehmen beruht: Linux-Builds auf GitHub-gehosteten Runnern, zwei Teams mit zwei verschiedenen SBOM-Generatoren, eine Yocto-Produktlinie mit eingeschaltetem create-spdx, SBOMs in einer gemeinsamen Tabelle, eine Code-Scanning-Suite und ein Ticketsystem. Sein Sicherheitsteam beantwortet die Fragen 1 und 3 mit Ja, findet bei Frage 2 zwei Generatoren und bei Frage 4 eine Tabelle und nennt bei Frage 5 Code-Scanning, Secret-Scanning und das Ticketsystem. Niemand nutzt die Patch-Metadaten im Yocto-SPDX.

Wechselt zu CRACI	Bleibt
GitHub-gehostete Runner für die Linux-Jobs	Code-Scanning, als Schritt auf CRACI Runnern
Beide SBOM-Generatoren	Secret-Scanning
create-spdx, da niemand seine Patch-Metadaten braucht	Das Ticketsystem
Die SBOM-Tabelle

Bei den Runnern kostet ein 10-minütiger Build, der auf einem GitHub-gehosteten x64-Runner mit 2 Kernen $0.060 kostet, auf CRACI mit der Beschleunigung etwa $0.020. Die Kosten der übrigen Tools trägt das Unternehmen selbst ein.

Wann CRACI nicht die Antwort ist

• Ihre Pipelines laufen auf GitLab CI, Jenkins, Azure DevOps oder einem anderen CI-System. CRACI unterstützt heute nur GitHub Actions, GitLab CI und Jenkins sind auf der Roadmap, es löst also noch nichts ab.
• Ihre Builds brauchen Windows- oder macOS-Runner oder GitHub Enterprise Server oder müssen auf Ihrer eigenen Infrastruktur laufen.
• Ihr Hauptproblem ist Rauschen aus dem Code-Scanning Ihres eigenen Codes. Das ist eine Frage der SAST-Feinabstimmung; siehe SAST vs. SCA und wie Sie das Rauschen bei Schwachstellen reduzieren.
• Ihr Hauptrisiko sind Firmware und Binärdateien, die Sie von Zulieferern erhalten, nicht Code, den Sie bauen.
• Ihr Stack besteht vor allem aus Java und Maven, die auf der Roadmap sind, oder aus .NET, das nicht zu den Ökosystemen gehört, die CRACI aufzeichnet.
• Sie brauchen heute Priorisierung nach Erreichbarkeit oder PSIRT-Fallbearbeitung.

Die Schritt-für-Schritt-Sicht auf das Produkt finden Sie unter So funktioniert CRACI, die SBOM selbst unter SBOM-Generierung.

Was CRACI ersetzt: häufig gestellte Fragen

Was ersetzt CRACI?

Ihre GitHub Actions Runner für Linux-Jobs, die SBOM-Generatoren, die Teams in der CI für Builds betreiben, die zu CRACI wechseln, Yoctos create-spdx für die Abdeckung der Lieferkette, Egress-Agents auf Runnern und eigenständiges Schwachstellen-Tracking auf Basis von SBOMs für diese Builds. Tools, die Ihren Code, Ihre Repositories oder Binärdateien Dritter lesen, ersetzt es nicht.

Ist CRACI eine Ergänzung zu unserem SCA-Tool, oder ersetzt es etwas?

Es ersetzt Aufgaben auf Build-Ebene: den Runner, die SBOM-Generierung und das Tracking, das auf der SBOM aufbaut. Ob das Ihr SCA-Tool ablöst, hängt davon ab, wofür Sie es nutzen. Wenn es Ihren Code liest, Snippet- oder Binäranalysen durchführt oder Ihnen Erreichbarkeit liefert, bleiben diese Teile.

Brauchen wir unseren SBOM-Generator noch, wenn wir Builds auf CRACI ausführen?

Nicht für Builds, die auf CRACI laufen und die Ökosysteme nutzen, die es aufzeichnet. CRACI zeichnet die Pakete auf, die jeder Job geladen hat, und exportiert die SBOM als CycloneDX oder SPDX. Behalten Sie einen Generator für Software, die Sie nicht auf CRACI bauen, etwa bezogene Images, und für Ökosysteme, die CRACI noch nicht aufzeichnet, etwa Maven.

Brauchen wir Yoctos integrierte SBOM-Generierung (create-spdx) noch?

Für die Abdeckung der Lieferkette nicht: In einem direkten Vergleichs-Build von core-image-sato enthielt die SBOM von CRACI jede Komponente aus Yoctos SBOM, dazu 88, die dort fehlten, und der Build ohne create-spdx brauchte 43 % weniger Zeit. Lassen Sie create-spdx eingeschaltet, wenn Sie auf seine angewendeten Patches und als behoben markierten CVEs angewiesen sind, die CRACI nicht aufzeichnet.

Ersetzt CRACI Code-Scanning oder Secret-Scanning?

Nein. CRACI liest Ihren Quellcode und Ihre Commits nicht nach Fehlern oder Secrets durch. Behalten Sie diese Tools. Code-Scanning-Schritte laufen unverändert in Ihrem Workflow auf einem CRACI Runner, und Funktionen auf Repository-Ebene sind nicht betroffen.

Ersetzt CRACI Binär- oder Firmware-Analyse?

Nein. CRACI zeichnet die Builds auf, die es ausführt. Für Firmware und Binärdateien, die Sie von Zulieferern erhalten, ist Binäranalyse das richtige Werkzeug. Wenn Ihnen ein Zulieferer eine SBOM gibt, kann CRACI sie zusammen mit Ihren eigenen Builds überwachen.

Können wir unsere bestehenden Sicherheitsschritte in GitHub Actions auf CRACI Runnern behalten?

Ja. CRACI ersetzt den Runner, nicht GitHub Actions: Sie setzen runs-on auf craci, und Ihre Workflows, Schritte und Ergebnisse bleiben in GitHub. Scan-Schritte, Test-Schritte und alle anderen Schritte laufen weiter wie bisher.