CRACI vs. Buildkite

Die kurze Antwort

Buildkite ist eine hybride CI/CD-Plattform. Die SaaS-Control-Plane übernimmt die Orchestrierung, und die Agents, die Ihre Jobs ausführen, laufen auf Ihrer eigenen Infrastruktur, On-Premises oder in der Cloud. Buildkite gibt an, dass Quellcode und Secrets in Ihrer Umgebung bleiben. Es bietet auch vollständig verwaltete gehostete Agents an, falls Sie keine eigenen betreiben möchten.

CRACI ist ein verwalteter, GitHub-Actions-kompatibler Runner, gebaut für Lieferkettensicherheit. Es zeichnet jede externe Abhängigkeit auf, die ein Build lädt, setzt eine Egress-Richtlinie im Build-Netzwerk durch und erzeugt aus dieser Aufzeichnung SBOMs, Provenienzdaten und CRA-Nachweise. Kurz gesagt: Buildkite ist klassisches CI mit maximaler Kontrolle über die Infrastruktur; CRACI ist sicherheitsbewusstes CI, bei dem der Runner der Nachweis ist.

CRACI unterstützt heute nur GitHub Actions und führt daher keine Buildkite-Pipelines aus. Ein Team auf Buildkite müsste eine Pipeline zu GitHub Actions umziehen, um CRACI-Runner zu nutzen, oder auf weitere CI-Systeme warten, die auf der Roadmap stehen.

Was Buildkite gut kann

Kontrolle über die Rechenleistung. Weil Sie die Agents selbst hosten, wählen Sie Hardware, Betriebssystem, Netzwerk und Region. Agents fragen die Agent-API von Buildkite über HTTPS ab, Sie müssen also keine eingehenden Firewall-Ports öffnen. Dieses Modell passt zu großen Monorepos, spezieller Hardware und Organisationen, deren Richtlinien den Quellcode innerhalb des eigenen Perimeters halten.

Integrität der Pipeline. Mit signierten Pipelines werden Jobs beim Upload signiert, und Agents prüfen die Signatur vor der Ausführung. Ein Agent führt also keinen Job aus, dessen Anweisungen nach dem Upload verändert wurden.

Werkzeuge rund um den Build. Test Engine erkennt Flaky Tests, stellt sie unter Quarantäne und teilt Tests auf parallele Jobs auf. Package Registries können Artefakte mit SLSA-Provenienz veröffentlichen, was laut Buildkite SLSA Build Level 1 erfüllt; diese Funktion ist in den Enterprise-Plänen verfügbar.

Flexible Preise. Stand September 2026 hat Buildkite einen kostenlosen Plan und einen Pro-Plan zu $30 pro aktivem Nutzer und Monat, mit 10 selbst gehosteten Agents inklusive bei Pro und weiteren zu $3.50 pro Agent und Monat. Gehostete Linux-Agents kosten $0.004 pro vCPU-Minute, sekundengenau abgerechnet.

Worin sich CRACI unterscheidet

Sicherheitsnachweise sind Teil des Runners

Mit selbst gehosteten Agents liegt die Absicherung der Build-Umgebung bei Ihnen. Die Sicherheitshinweise von Buildkite selbst empfehlen, minimale Betriebssysteme zu installieren, eingehendes SSH zu deaktivieren und strikte Kontrollen für den Netzwerk-Egress durchzusetzen. Das ist eine faire Aufteilung der Verantwortung, und es bedeutet, dass Lieferkettennachweise davon abhängen, was Ihr Team rund um die Agents aufbaut.

Bei CRACI kommt diese Ebene mit dem Runner. Ein paketbewusster Proxy zeichnet während jedes Jobs den Datenverkehr zu den Paketquellen auf, ü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. Jeder Job erzeugt eine SBOM als CycloneDX oder SPDX mit einem Vollständigkeitsstatus pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded.

Egress-Richtlinien, ohne sie selbst bauen zu müssen

Egress-Richtlinien von CRACI sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen, typisierten eigenen Quellen für npm, PyPI, apt, apk, den Go-Proxy, Nix, Cargo, OCI-Registries und Git sowie expliziten Regeln für TLS, TCP, UDP und ICMP. Richtlinien werden vor dem Start des Jobs validiert, blockieren im Zweifel (fail closed) und senden bei einem Verstoß eine Warnung.

Provenienz und Überwachung

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert die Provenienz nicht. Es führt Schwachstellen über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs laufend neu.

Der Kompromiss

CRACI gibt es nur als verwalteten Dienst. Jobs laufen in isolierten virtuellen Maschinen auf der Infrastruktur von CRACI, und der Quellcode wird für die Dauer des Builds in der Job-VM verarbeitet und nicht gespeichert. Im Enterprise-Plan bietet CRACI EU-Datenresidenz mit Build-Ausführung auf europäischer Bare-Metal-Infrastruktur. Wenn Ihre Richtlinien Builds auf Ihrer eigenen Hardware verlangen, erfüllt das Modell von Buildkite diese Anforderung, das von CRACI nicht.

Was passt

• Buildkite, wenn Sie Builds auf Ihrer eigenen Hardware oder in Ihrem eigenen Netzwerk brauchen, Windows- oder macOS-Builds ausführen, GitLab oder Bitbucket nutzen oder in einer Größenordnung arbeiten, in der sich eigene Rechenleistung auszahlt.
• CRACI, wenn Sie auf GitHub Actions sind und Build-Nachweise wollen, ohne sie selbst aufzubauen und zu betreiben: aufgezeichnete Abhängigkeiten, Egress-Richtlinie und CRA-Nachweise aus einem Runner.
• Beide, wenn Ihre Organisation geteilt ist: Buildkite für Pipelines, die auf Ihrer Hardware bleiben müssen, CRACI für Linux-Workflows in GitHub Actions. Rechenintensive Linux-Builds wie Yocto-Images können auf CRACI-Runnern mit bis zu 32 vCPU und 96 GB RAM laufen, wie im Yocto-Leitfaden von CRACI beschrieben.

Für den Cyber Resilience Act

Der EU Cyber Resilience Act verlangt von Herstellern, dass sie wissen, was in jedem Release steckt, und dessen Schwachstellen behandeln, mit Meldepflichten ab September 2026 und voller Anwendung ab Dezember 2027. Bei Buildkite stammen diese Nachweise aus den Tools, die Sie auf Ihren Agents ausführen. CRACI erzeugt sie aus der Build-Aufzeichnung, überwacht das Ausgelieferte weiter und exportiert SBOMs als CycloneDX oder SPDX, einschließlich Schwachstellen. Es automatisiert einen wesentlichen Teil der Transparenz und Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen.

CRACI hinzufügen

Für ein Repository auf GitHub mit GitHub-Actions-Workflows installieren Sie die CRACI GitHub App in Ihrer Organisation und setzen das Runner-Label:

runs-on: craci

Die Ausführungen erscheinen weiterhin in der GitHub-Oberfläche. Erfahren Sie mehr über SBOM-Generierung während des Builds und darüber, wie CRACI mit Sicherheit umgeht, oder sehen Sie sich die Preise an.