CRACI vs. Harness | CI und Lieferkettensicherheit verglichen

Die kurze Antwort

Harness, 2017 gegründet und in San Francisco ansässig, verkauft eine Plattform für alles, was nach dem Schreiben des Codes kommt: Continuous Integration, Continuous Delivery, Feature-Flags, Cloud-Kostenmanagement, Chaos Engineering und Sicherheitstests. Sein Modul Supply Chain Security (SCS) ergänzt SBOM-Generierung, SLSA-Provenienz, OPA-Policy-Gates und Posture-Prüfungen für Repositories und Pipelines. Wenn Sie einen Anbieter für die gesamte Delivery-Pipeline über mehrere Git-Anbieter hinweg möchten, ist Harness dafür gebaut.

CRACI ist enger gefasst und geht tiefer in den Build. Es ist ein GitHub-Actions-Runner: Während jeder Job läuft, zeichnet es jede externe Abhängigkeit auf, die der Build lädt, setzt eine Egress-Richtlinie im Build-Netzwerk durch und erzeugt aus dieser Aufzeichnung SBOMs, Provenienzdaten und Schwachstellenüberwachung. Harness fügt einer Pipeline Lieferketten-Schritte hinzu; CRACI macht den Runner selbst zur Sicherheitsaufzeichnung.

Ein praktischer Punkt vorab. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. Harness-CI-Pipelines müssten zu GitHub Actions wechseln, um auf CRACI zu laufen.

Auf einen Blick

Funktion	CRACI	Harness
Wie die SBOM entsteht	Aufgezeichnet aus dem, was jeder Job geladen hat, mit Vollständigkeitsstatus	Syft oder cdxgen scannt ein Image oder Repository in einem Pipeline-Schritt
SBOM-Formate	CycloneDX und SPDX	SPDX und CycloneDX
Build-Provenienz	Provenienzdaten über die API; nicht signiert	SLSA Build L1 bis L3, signiert mit cosign
Egress-Richtlinie für das Build-Netzwerk	Standardmäßig sperrend oder erlaubend, vor dem Job validiert, blockiert im Zweifel (fail closed)	Erkennt laut eigener Aussage auffällige Netzwerkaufrufe von Runnern
Policy-Gates	Blockiert einen Build wegen Befunden, einer bestimmten CVE oder einer Lizenz	OPA-Richtlinien für SBOMs, Provenienz und Deployments
Überwachung des Ausgelieferten	Überwachte SBOMs werden laufend neu bewertet	Kennzeichnet Pipelines und Artefakte, die eine neue CVE betrifft
Posture-Prüfungen für CI/CD und Repositories		OWASP Top 10 CI/CD Risks und CIS-Benchmarks
CI-Systeme	Heute GitHub Actions; GitLab CI und Jenkins auf der Roadmap	Harness CI; SCS-Schritte auch für GitHub Actions und GitLab CI/CD
Plattformen gehosteter Runner	Linux auf x86-64 und ARM64, 1 bis 32 vCPU. Windows und macOS auf der Roadmap.	Linux AMD64 mit bis zu 96 Kernen und ARM64 mit bis zu 64, Windows und macOS auf Apple M4.
Selbst gehostete Build-Infrastruktur	Vom Kunden gehostete Runner, Enterprise	Kubernetes, VMs oder Bare Metal
Delivery, Feature-Flags, Kostenmanagement	CRACI deckt den Build ab	Module derselben Plattform
Preis, Linux mit 2 vCPU	$0.004 pro Minute ($0.002 pro vCPU-Minute), sekundengenau abgerechnet.	$0.005 pro Minute für 2 Kerne und 7 GB, auf die nächste Minute gerundet.
Pläne	Zahlung pro Build-Minute: $0.004 pro Minute mit 2 vCPU, sekundengenau abgerechnet. Keine Monatsgebühr und keine Gebühr pro SBOM.	Free-Plan mit 2.000 Harness-Cloud-Credits pro Monat; kostenpflichtige Pläne, Credit-Pakete und Supply Chain Security über den Vertrieb (Stand September 2026).

Enthalten
Teilweise
Nicht enthalten
Auf der Roadmap

Was Harness gut kann

Eine Plattform für Delivery. Harness deckt CI, CD, GitOps, Feature-Flags, Infrastructure as Code, Chaos Engineering und Cloud-Kostenmanagement ab, mit OPA-basierter Richtliniendurchsetzung über alle hinweg. Es arbeitet mit GitHub, GitLab, Bitbucket, Azure Repos und den eigenen Harness-Code-Repositories und bedient nach eigenen Angaben mehr als 1.000 Enterprise-Kunden mit mehr als 1.200 Beschäftigten.

Wahl der Build-Infrastruktur. Harness Cloud führt Builds auf von Harness verwalteten Linux-, Windows- und macOS-Maschinen aus: Linux AMD64 mit 2 bis 96 Kernen, ARM64 mit 2 bis 64 Kernen zum gleichen Tarif und macOS auf Apple M4. Nested Virtualization ist auf Linux AMD64 verfügbar. Sie können Builds auch auf eigenen Kubernetes-Clustern, VMs oder Bare Metal ausführen. Test Intelligence führt nur die Tests aus, die eine Änderung betrifft, und Build Intelligence und Cache-Funktionen verwenden unveränderte Ausgaben und Abhängigkeiten wieder.

Lieferkettenfunktionen in der Pipeline. Der Schritt SBOM Orchestration des SCS-Moduls erzeugt mit Syft oder cdxgen eine SBOM für ein Container-Image oder ein Code-Repository, in SPDX oder CycloneDX, und kann SBOMs aus anderen Tools aufnehmen. Laut Harness werden SBOMs bei jedem Build erzeugt und aktualisiert. OPA-Richtlinien können Builds und Deployments wegen Komponenten, Lizenzen oder Provenienz blockieren, und ein Remediation Tracker verfolgt verwundbare Artefakte.

SLSA-Provenienz. Harness dokumentiert SLSA Build Level 1, 2 und 3 unter SLSA v1.0, mit Provenienz, die über in-toto-Attestierungen und cosign signiert wird. Laut seiner Dokumentation braucht Level 3 gehärtete Build-Infrastruktur oder Harness Cloud, das Build-Prozesse voneinander isoliert.

Posture- und Pipeline-Prüfungen. SCS prüft Repositories und Pipelines anhand der OWASP Top 10 CI/CD Security Risks und der CIS-Benchmarks und kennzeichnet ungepinnte, nicht verifizierte und überberechtigte GitHub Actions. Harness bietet seine SCS-Schritte außerdem als GitHub Actions und GitLab-CI/CD-Komponenten an, das Modul ist also nicht an Harness CI gebunden; diese Schritte brauchen ein Harness-Konto mit SCS-Lizenz.

Worin sich CRACI unterscheidet

Die SBOM stammt aus dem Build, nicht aus einem Scan seiner Ausgabe

Syft und cdxgen sind Scanner: Sie lesen nachträglich ein Image oder ein Repository und leiten aus Lockfiles, Manifesten und Paketdatenbanken ab, was darin steckt. Das funktioniert gut, wenn diese Dateien die ganze Geschichte erzählen. Builds tun oft mehr: Install-Skripte laden Code herunter, Rust-Build-Skripte laden zur Build-Zeit nach, und Caches stellen Pakete wieder her, die kein Lockfile erwähnt.

CRACI sieht diesen Datenverkehr, weil es der Runner ist. Ein paketbewusster Proxy zeichnet auf, was jeder Job von Paketquellen lädt, über npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen hinweg, dazu Download-Presets, und die Abhängigkeitsnachweise reisen mit CI-Caches mit. Es zeichnet die versteckten Abhängigkeiten auf, die lockfile-basierte Tools übersehen, und jede SBOM gibt an, wie vollständig sie ist, pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded.

Eine Richtlinie für das Build-Netzwerk, keine nachträgliche Erkennung

Laut Harness erkennt sein Modul auffälliges Verhalten von CI-Runnern, darunter Netzwerkaufrufe und Rechteausweitung. CRACI geht den anderen Weg: Eine Egress-Richtlinie auf dem Runner entscheidet, welche Hosts ein Job erreichen darf. Richtlinien sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen und typisierten eigenen Quellen, werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed). Weil eine standardmäßig sperrende Richtlinie nur erlaubt, was der Build braucht, statt nach bekannten bösartigen Hosts zu suchen, blockiert sie die Exfiltration zum Server eines Angreifers selbst bei einem Angriff, den noch niemand gesehen hat. Verstöße lösen eine Warnung aus.

Provenienz und Überwachung aus derselben Aufzeichnung

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht und beansprucht kein SLSA-Level; Harness signiert seine Provenienz und dokumentiert die Level 1 bis 3, und wenn signierte Provenienz oder ein SLSA-Level eine Beschaffungsanforderung ist, spricht das für Harness. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen, bewertet überwachte SBOMs laufend neu, sobald Advisories erscheinen, und zeigt, welche früheren Builds eine verwundbare Abhängigkeit enthielten, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren.

Preise, die Sie nachlesen können

CRACI berechnet nur Build-Minuten: $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPU), sekundengenau abgerechnet, ohne Monatsgebühr und ohne Gebühr pro SBOM. Harness veröffentlicht seine Harness-Cloud-Tarife, $0.005 pro Minute für eine Linux-Maschine mit 2 Kernen und 7 GB und $0.080 für 32 Kerne, auf die nächste Minute abgerechnet, während die kostenpflichtigen Pläne und das SCS-Modul über den Vertrieb bepreist werden. Der Listenpreis von CRACI liegt bei beiden Größen 20 % niedriger pro Minute ($0.004 gegenüber $0.005, $0.064 gegenüber $0.080); Harness-Maschinen haben mehr Arbeitsspeicher pro Kern.

Was zu Ihnen passt

Bleiben Sie bei Harness, wenn Sie CI, CD, Feature-Flags und Kostenmanagement von einem Anbieter möchten, wenn Ihr Code auf GitLab, Bitbucket oder Azure Repos liegt, wenn Sie Windows, macOS oder eigene Build-Hardware brauchen oder wenn ein dokumentiertes SLSA Build Level 3 eine Anforderung ist.
Wählen Sie CRACI, wenn Ihr Code auf GitHub liegt, Sie GitHub Actions nutzen oder nutzen wollen und Sie möchten, dass SBOM, Netzwerkrichtlinie und Provenienz von dem Runner stammen, der den Build ausgeführt hat, abgerechnet pro Build-Minute.

Seien Sie sich im Klaren darüber, worauf Sie mit CRACI verzichten. Es stellt keine Software bereit, betreibt keine Feature-Flags und verwaltet keine Cloud-Kosten, und es prüft weder Repositories und Pipelines anhand von Posture-Benchmarks noch scannt es Quellcode. Es führt heute nur Linux-Jobs aus; Windows und macOS sind auf der Roadmap, und vom Kunden gehostete Runner sind für Enterprise auf der Roadmap.

Für regulierte Produkte

Frameworks wie der EU Cyber Resilience Act erwarten von Herstellern, dass sie wissen, was in jedem Release steckt, und seine Schwachstellen behandeln, mit Meldepflichten ab September 2026. Harness liefert SBOMs, Provenienz und Richtlinienergebnisse aus seinen Pipeline-Schritten. CRACI erzeugt die Nachweise aus der Build-Aufzeichnung und exportiert SBOMs als CycloneDX oder SPDX. Es automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die ein Unternehmen für seinen umfassenderen CRA-Prozess braucht; keines der beiden Tools macht ein Produkt allein konform.

Eine Pipeline zu CRACI migrieren

CRACI ersetzt den Runner, nicht GitHub Actions, und Läufe erscheinen weiterhin in der GitHub-Oberfläche. Sobald eine Pipeline als GitHub-Actions-Workflow läuft, läuft sie mit einer Zeile auf CRACI:

runs-on: craci

Lesen Sie mehr über SBOM-Generierung während des Builds, vergleichen Sie CI/CD-Plattformen, sehen Sie sich die Harness-Alternativen an, oder sehen Sie sich die Preise an.