Vergleich
CRACI vs. GitLab CI
GitLab scannt Ihr Projekt und berichtet, was seine Lockfiles deklarieren. CRACI ist der Runner und zeichnet daher auf, was jeder Build tatsächlich geladen hat. Der Unterschied liegt darin, woher Ihre SBOM und Ihre Provenienz stammen.
Aktualisiert am
Die kurze Antwort
GitLab ist eine vollständige DevSecOps-Plattform: Quellcodeverwaltung, Merge Requests, Planung und CI/CD in einem Produkt, mit einer breiten Palette an Sicherheitsscannern und Schwachstellenmanagement in der Stufe Ultimate. Wenn Sie einen Anbieter für den gesamten Software-Lebenszyklus möchten, ist GitLab dafür gebaut.
CRACI ist enger gefasst. Es ist ein GitHub-Actions-kompatibler Runner, der jede externe Abhängigkeit aufzeichnet, die ein Build lädt, kontrolliert, was der Build erreichen kann, und aus dieser Aufzeichnung SBOMs, Provenienzdaten und CRA-Nachweise macht. Der Kernunterschied: klassisches CI mit angebundenen Scannern gegenüber CI, bei dem der Runner selbst die Sicherheitsaufzeichnung ist.
Ein praktischer Punkt vorab. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. Wenn Ihre Pipelines in GitLab CI liegen, müssten Sie sie zu GitHub Actions migrieren, um CRACI-Runner zu nutzen, oder auf die Unterstützung für GitLab CI warten, die auf der Roadmap steht.
| Funktion | CRACI | GitLab |
|---|---|---|
| Aus dem Build aufgezeichnete Abhängigkeiten | Beobachtete Abrufe, einschließlich Paketen aus CI-Caches | Scanner lesen Lockfiles und Exporte des Abhängigkeitsgraphen |
| SBOM-Export | CycloneDX oder SPDX pro Build, mit Vollständigkeitsstatus | CycloneDX-Berichte; Export der Abhängigkeitsliste in Ultimate |
| Egress-Richtlinie für das Build-Netzwerk | Standardmäßig sperrend oder erlaubend, blockiert im Zweifel (fail closed) | Ihre eigenen Netzwerkkontrollen auf Self-Managed-Runnern |
| Build-Provenienz | Provenienzdaten über die API; nicht signiert | SLSA-1.0-Provenienzangabe vom Runner |
| Kontinuierliche Schwachstellenüberwachung | Überwachte SBOMs werden laufend neu bewertet | Continuous Vulnerability Scanning in Ultimate |
| Compliance-Reporting | SBOMs in CycloneDX oder SPDX, Aufzeichnungen über die API; kein Berichtsexport | Compliance- und Governance-Funktionen in Ultimate |
| SAST, Secret Detection, DAST | Basis-SAST und Secrets in allen Stufen; DAST in Ultimate | |
| Quellcodeverwaltung und Planung | Arbeitet mit Ihren GitHub-Repositories | Repositories, Merge Requests und Planung auf einer Plattform |
| Unterstützte CI-Systeme | Heute GitHub Actions; GitLab CI und Jenkins auf der Roadmap | GitLab CI/CD, gehostet oder Self-Managed |
| Plattformen gehosteter Runner | Linux auf x86-64 und ARM64, 1 bis 32 vCPU. Windows und macOS auf der Roadmap. | Linux auf x86-64 und arm64; gehostete Windows- und macOS-Runner in der Beta. |
| Preise | Zahlung pro Build-Minute: $0.004 pro Minute mit 2 vCPU, sekundengenau abgerechnet. Keine Monatsgebühr und keine Gebühr pro SBOM. | Free mit 400 Compute-Minuten; Premium $29 pro Nutzer und Monat bei jährlicher Abrechnung; Ultimate zu individuellen Preisen (Stand September 2026). |
- Enthalten
- Teilweise
- Nicht enthalten
- Auf der Roadmap
Was GitLab gut kann
Eine Plattform. Code, Reviews, Pipelines, Sicherheitsbefunde und Planung liegen am selben Ort, mit einem einzigen Berechtigungsmodell. Für viele Organisationen entscheidet das allein schon die Frage.
Sicherheitsscans nach Stufe. Achten Sie genau darauf, was jede Stufe enthält. Laut GitLab laufen Basis-SAST, Secret Detection und Container-Scanning in allen Stufen, auch in Free. In Free und Premium erzeugen diese Scans JSON-Berichtsartefakte. Ultimate ergänzt den Workflow drumherum: Befunde in Merge Requests, den Vulnerability Report, die Abhängigkeitsliste, Sicherheitsfreigaben und GitLab Advanced SAST. Dependency Scanning, Continuous Vulnerability Scanning und DAST sind Funktionen von Ultimate. Container-Scanning kann in jeder Stufe auch einen CycloneDX-SBOM-Bericht erzeugen.
Provenienz. GitLab Runner kann in allen Stufen eine Artefakt-Provenienzangabe im Format SLSA 1.0 erzeugen. Es gibt auch signierte Attestierungen nach SLSA Level 3, doch GitLab führt sie als Experiment auf GitLab.com für Ultimate, hinter einem standardmäßig deaktivierten Feature-Flag.
Wahl des Runners. Von GitLab gehostete Runner decken Linux auf x86-64 (2 bis 32 vCPUs) und arm64 ab, Windows und macOS sind in der Beta. Sie können auch eigene Runner an beliebigen Orten betreiben, und laut GitLab verbrauchen Jobs auf eigenen Runnern keine Compute-Minuten. GitLab Dedicated ergänzt Datenresidenz in einer Region Ihrer Wahl.
Worin sich CRACI unterscheidet
Die SBOM stammt aus dem Build, nicht aus dem Lockfile
Das SBOM-basierte Dependency Scanning von GitLab erkennt Abhängigkeiten aus unterstützten Lockfiles oder Exporten des Abhängigkeitsgraphen. Das ist ein solider Ansatz, wenn das Lockfile die ganze Geschichte erzählt. Builds tun oft mehr: Sie führen Install-Skripte aus, laden Toolchains herunter, stellen Caches wieder her und ziehen Basis-Images.
CRACI sieht diese Aktivität, weil es der Runner ist. Ein paketbewusster Proxy beobachtet während des Jobs den Datenverkehr zu Paketquellen, über npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen hinweg, dazu Download-Presets. Die Abhängigkeitsnachweise reisen mit CI-Caches mit, sodass auch ein aus einem Cache wiederhergestelltes Paket gezählt wird. Jeder Job erzeugt eine SBOM in CycloneDX oder SPDX.
Vollständigkeit wird angegeben, nicht angenommen
Jede SBOM trägt einen Vollständigkeitsstatus pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Hat die Aufzeichnung eine Lücke, können Sie sie sehen.
Das Build-Netzwerk folgt einer Richtlinie
Egress-Richtlinien von CRACI sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen und typisierten eigenen Quellen für npm, PyPI, apt, apk, den Go-Proxy, Nix, Cargo, OCI-Registries und Git. Richtlinien werden vor dem Start des Jobs validiert, blockieren im Zweifel (fail closed) und senden bei einem Verstoß eine Warnung. Bei GitLab ist die Netzwerkkontrolle für Builds das, was Sie rund um Ihre eigenen Runner konfigurieren.
Provenienz
Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht und beansprucht kein SLSA-Level.
Überwachung des Ausgelieferten
CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs laufend neu, sobald neue Advisories erscheinen.
Was zu Ihnen passt
- Bleiben Sie bei GitLab, wenn Ihr Code und Ihre Pipelines auf GitLab liegen und Sie eine Plattform möchten oder wenn Sie SAST, DAST und Secret Detection im selben Produkt brauchen.
- Wählen Sie CRACI, wenn Ihr Code auf GitHub liegt, Sie GitHub Actions nutzen und Sie Nachweise darüber brauchen, was in jedes Release eingeflossen ist, Kontrolle darüber, was Builds erreichen können, und SBOMs, die Sie in einem Audit verteidigen können.
- Nutzen Sie beide, wenn Ihre Organisation beide Plattformen betreibt. GitLab deckt weiterhin seine Projekte und Scanner ab; CRACI übernimmt die GitHub-Actions-Seite und zeichnet diese Builds auf.
Für den Cyber Resilience Act
Nach dem EU Cyber Resilience Act müssen Hersteller wissen, was in jedem Produkt-Release steckt, und dessen Schwachstellen behandeln. Die Meldepflichten für Schwachstellen gelten ab September 2026, die Verordnung gilt ab Dezember 2027 vollständig. GitLab Ultimate hilft, Schwachstellen in Ihren Projekten zu finden und zu verwalten. CRACI zeichnet auf, woraus jedes Release gebaut wurde, überwacht es weiter und exportiert SBOMs als CycloneDX oder SPDX. Es 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 Sie allein konform.
CRACI hinzufügen
Installieren Sie für ein Repository auf GitHub die CRACI GitHub App in Ihrer Organisation, für alle Repositories oder eine Auswahl, und ändern Sie das Runner-Label:
runs-on: craciWorkflows, Actions und die GitHub-Oberfläche bleiben gleich. CRACI ersetzt den Runner, nicht GitHub Actions. Lesen Sie mehr über SBOM-Generierung während des Builds und CRA-Nachweise, oder sehen Sie sich die Preise an.
Sehen Sie, was ein Build wirklich lädt
Führen Sie einen GitHub-Actions-Workflow auf CRACI aus und vergleichen Sie seine SBOM mit der, die Ihre Scanner heute erzeugen.
Demo buchen