CRACI vs. DIY-SBOM-Stack

Die kurze Antwort

Ein DIY-Stack aus Syft oder Trivy, Grype, Dependency-Track, Cosign und Renovate kostet keine Lizenzgebühren, läuft überall und gibt einem fähigen Plattform-Team die volle Kontrolle. CRACI ist ein verwalteter GitHub-Actions-Runner, der aufzeichnet, was jeder Build geladen hat, kontrolliert, wohin er sich verbinden darf, das Ausgelieferte überwacht und die Nachweise exportiert. Der Unterschied liegt weniger in den Funktionen als darin, woher die SBOM stammt und wer die Nahtstellen pflegt. Wenn Sie auf GitLab, Jenkins oder Windows bauen oder alles auf Ihrer eigenen Infrastruktur laufen muss, ist DIY heute die ehrliche Empfehlung.

So sieht der Stack aus

Ein vollständiger Eigenbau hat meist sieben Ebenen. Jede davon ist ein echtes Projekt mit eigenem Pflegeaufwand.

1. Generierung. Syft („generating a Software Bill of Materials (SBOM) from container images and filesystems“), Trivy, cdxgen (ein OWASP-Projekt, das CycloneDX-BOMs „from source and container images“ erzeugt) oder das Microsoft SBOM Tool, das SPDX schreibt und in der Kommandozeile einen Build-Drop-Ordner, einen Paketnamen, eine Version und einen Lieferanten erwartet.
2. Abgleich. Grype scannt Images, Dateisysteme und SBOMs, mit EPSS, KEV und Risikobewertung. OSV-Scanner gleicht Lockfiles, SBOMs und Container-Images mit OSV.dev ab.
3. Verwaltung. OWASP Dependency-Track nimmt CycloneDX-SBOMs auf und überwacht sie im Zeitverlauf. Sein API-Server braucht mindestens 2 GB RAM und 2 CPU-Kerne (empfohlen sind 8 GB und 4 Kerne), und seine Dokumentation verweist für Produktivumgebungen auf Docker Compose mit einer separaten Datenbank.
4. Signierung. Cosign signiert Images, Blobs und SBOM-Attestierungen, mit schlüsselloser Signierung über Fulcio und einem Rekor-Transparenzlog. GitHub Artifact Attestations bauen auf Sigstore auf und liefern Provenienz nach SLSA v1.0 Build Level 2.
5. Updates. Renovate oder Dependabot öffnen Pull Requests, um Abhängigkeiten aktuell zu halten.
6. Egress-Kontrolle. StepSecurity Harden-Runner kann ausgehende Verbindungen von GitHub-Actions-Jobs prüfen oder blockieren. Die Community-Stufe ist für öffentliche Repositories auf GitHub-hosted Runnern kostenlos; private Repositories und selbst gehostete Runner brauchen die Enterprise-Stufe. Die Alternative sind ein eigener Proxy und Firewall-Regeln rund um selbst gehostete Runner.
7. Reporting. Jemand macht aus den Ergebnissen all dieser Tools die Dokumente, die ein Auditor, ein Kunde oder eine technische Dokumentation nach dem CRA braucht.

Die Kosten stecken in den Nahtstellen

Wer einen Generator wählt, wählt seine blinden Flecken

Richten Sie mehrere SBOM-Generatoren auf dasselbe Repository, und sie werden sich nicht einig sein, was es enthält. Jeder liest andere Dateien und löst sie anders auf, die Komponentenliste ist also ebenso eine Eigenschaft des gewählten Tools wie des Projekts. Das NTIA-Lieferantenfeld zeigt dasselbe von der anderen Seite: Die meisten Generatoren haben dafür keine Quelle, sodass es leer bleibt, ganz gleich, was das Repository enthält.

Keines dieser Tools ist kaputt. Jedes trifft eine andere, dokumentierte Entscheidung darüber, was als Komponente zählt und welchen Dateien es vertraut. Ein DIY-Stack erbt aber die Entscheidungen der Tools, die Sie gewählt haben, und der Rest der Pipeline (Abgleich, Überwachung, Reporting) kann nur so vollständig sein wie dieser erste Schritt.

Die Integration bleibt Ihre Aufgabe

Jedes Tool hat seinen eigenen Release-Rhythmus, seine eigene Schwachstellendatenbank, sein eigenes Ausgabeformat und seine eigene Konfiguration. Jemand pinnt die Versionen, aktualisiert die Datenbanken, hält Dependency-Track und seine Datenbank gepatcht, rotiert Signaturidentitäten, entscheidet, welche SBOM wohin geht, und bemerkt, wenn ein Schritt stillschweigend weniger liefert. Das ist laufende Plattformarbeit, keine einmalige Einrichtung.

Auch die Tools sind Abhängigkeiten

Sicherheitstools laufen in Ihren Builds mit Zugriff auf Ihre Secrets, sie gehören also in Ihr Bedrohungsmodell. Im März 2026 veröffentlichte Aqua Security ein Advisory, das beschreibt, wie kompromittierte Zugangsdaten genutzt wurden, um ein bösartiges Trivy-Release zu veröffentlichen und die meisten trivy-action-Tags für etwa 12 Stunden per Force-Push auf Code umzulenken, der Zugangsdaten stahl. Aqua hat den Vorfall öffentlich dokumentiert, und er hätte jedes weit verbreitete Projekt treffen können. Er zeigt, warum Egress-Kontrolle auf dem Runner wichtig ist: Eine standardmäßig sperrende Richtlinie begrenzt, wohin ein kompromittierter Schritt Daten senden kann, wenn auch nicht jeden Kanal (das Advisory beschreibt auch einen Ausweichweg, der Repositories im GitHub-Konto des Opfers anlegte).

Wann DIY die richtige Wahl ist

• Ihr CI ist nicht GitHub Actions. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. Teams mit GitLab, Jenkins und CircleCI können jedes der genannten Open-Source-Tools einsetzen.
• Sie bauen auf Windows oder macOS. CRACI-Runner laufen heute auf Linux (x86-64 und ARM64); Windows und macOS sind auf der Roadmap.
• Alles muss auf Ihrer Infrastruktur laufen. CRACI betreibt heute verwaltete Runner auf europäischer Infrastruktur; vom Kunden gehostete Runner sind für Enterprise auf der Roadmap.
• Sie haben ein Plattform-Team, das dafür zuständig sein will. Wenn die Pflege des Stacks eine bewusste Investition ist und Sie Dependency-Track bereits gut betreiben, bleiben Sie dabei.
• Sie brauchen eine SBOM für einen Fragebogen. Für eine gelegentliche Anfrage, bei der wenig auf dem Spiel steht, kann ein von Hand gestarteter Generator genügen.

Was CRACI ersetzt und was nicht

CRACI deckt mehrere Ebenen an einem Ort ab, ausgehend vom Build. Sie ändern runs-on auf craci, und Läufe erscheinen weiterhin in der GitHub-Oberfläche. Ein paketbewusster Proxy zeichnet auf, was jeder Job von npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen lädt, dazu Download-Presets, und die Abhängigkeitsnachweise reisen mit CI-Caches mit. Jeder Job und jeder Cache erhält einen Vollständigkeitsstatus: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded.

• Generierung: CycloneDX und SPDX aus dem aufgezeichneten Build, einschließlich transitiver Abhängigkeiten.
• Überwachung: Befunde werden über Builds und Repositories hinweg zusammengeführt, und überwachte SBOMs werden laufend neu bewertet.
• Provenienz: Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht.
• Egress: Richtlinie pro Job mit 24 integrierten Presets für Softwarequellen, vor dem Start des Jobs validiert, blockiert im Zweifel (fail closed), mit Warnungen bei Verstößen.
• Export: SBOMs als CycloneDX oder SPDX, einschließlich Schwachstellen; kein Berichtsexport.

Es ersetzt nicht alles. Paket-Blocklists sind auf der Roadmap. Wenn Sie signierte Provenienz brauchen, behalten Sie Cosign oder GitHub Artifact Attestations. Renovate oder Dependabot sind weiterhin sinnvoll, um alle Abhängigkeiten aktuell zu halten, nicht nur verwundbare. Wenn Ihr Sicherheitsteam in Dependency-Track arbeitet, lässt sich die CycloneDX-SBOM über die REST-API von CRACI herunterladen und dort einspeisen.

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.

Für den Cyber Resilience Act

Der CRA verlangt von Herstellern, Schwachstellen und Komponenten in Produkten mit digitalen Elementen zu ermitteln und zu dokumentieren, „unter anderem durch Erstellung einer Software-Stückliste“ (Anhang I Teil II). Die Meldepflicht für aktiv ausgenutzte Schwachstellen gilt ab September 2026, mit 24 Stunden für die Erstmeldung. Ein DIY-Stack kann das unterstützen, solange jemand für die Nachweiskette von jedem Release zurück zu seiner SBOM zuständig ist. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen, und reicht die CRA-Meldungen in Ihrem Namen ein. Welchen Weg Sie auch wählen: Die Entscheidung, was aktiv ausgenutzt wird, bleibt bei Ihrem Team. Siehe CRA-Compliance und SBOM-Generierung während des Builds.