CRACI vs. CircleCI

Die kurze Antwort

CircleCI ist eine ausgereifte, flexible CI/CD-Plattform. Sie verbindet sich mit GitHub, GitLab und Bitbucket, führt Jobs auf einer breiten Palette von Maschinen aus, von Docker-Containern bis zu macOS und GPUs, und erlaubt es, wiederverwendbare Konfiguration als Orbs zu bündeln. Bei der Sicherheit schützt CircleCI Zugangsdaten und überlässt Scans den Orbs und Drittanbieter-Tools.

CRACI verfolgt den umgekehrten Ansatz: Der Runner ist die Sicherheitsaufzeichnung. Er führt GitHub-Actions-Jobs aus, beobachtet jede externe Abhängigkeit, die ein Build lädt, setzt eine Egress-Richtlinie im Build-Netzwerk durch und erzeugt aus dem Beobachteten SBOMs, Provenienzdaten und CRA-Nachweise. Das ist der Unterschied zwischen klassischem CI und sicherheitsbewusstem CI.

CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap. CircleCI wird noch nicht unterstützt. Teams auf CircleCI müssten eine Pipeline auf GitHub Actions umziehen, um CRACI-Runner zu nutzen, oder auf weitere CI-Systeme warten, die auf der Roadmap sind.

Was CircleCI gut macht

Breites Angebot an Rechenressourcen. CircleCI bietet Ressourcenklassen für Docker, Linux-VMs, Arm, Windows, macOS und GPU, sodass eine Plattform ein Backend, einen Windows-Client und eine iOS-App bauen kann. Selbst gehostete Runner erweitern das auf Ihre eigenen Linux-, Windows- und macOS-Maschinen und auf Kubernetes, und die Job-Zeit auf diesen Runnern verbraucht keine Credits.

Funktionen für Geschwindigkeit. Docker Layer Caching ist in allen Plänen verfügbar. Test Splitting verteilt eine Testsuite nach Name, Dateigröße oder historischen Laufzeitdaten auf parallele Executors, was die Gesamtlaufzeit großer Testsuiten verkürzt.

Wiederverwendbare Konfiguration. Orbs bündeln Jobs, Befehle und Executors, damit Teams sie projektübergreifend wiederverwenden können, und sie machen es einfach, Drittanbieter-Tools einzubinden, auch Sicherheitsscanner.

Sorgfalt bei Zugangsdaten. Die Empfehlungen von CircleCI zur Lieferkette konzentrieren sich auf den Schutz von Secrets: Teilen Sie sie auf Contexts auf, legen Sie Deploy- und Signierschlüssel in eingeschränkte Contexts, die über Ihre VCS-Gruppen gesteuert werden, und nutzen Sie OIDC-Tokens, damit Jobs Cloud-Dienste ohne langlebige, in CircleCI gespeicherte Zugangsdaten erreichen.

Worin sich CRACI unterscheidet

Der Build ist die maßgebliche Quelle

Auf einer klassischen CI-Plattform erzeugt ein Tool, das Sie der Pipeline hinzufügen, die SBOM, und es liest dafür meist Manifeste und Lockfiles. CRACI beobachtet stattdessen den Build. Ein paketbewusster Proxy zeichnet den Datenverkehr zu Paketquellen auf, während der Job läuft, über npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen hinweg, dazu Download-Presets. Die Abhängigkeitsnachweise reisen mit CI-Caches, sodass ein aus einem Cache wiederhergestelltes Paket trotzdem erfasst wird.

Sie wissen, wie vollständig die SBOM ist

Jeder Job erzeugt eine CycloneDX- oder SPDX-SBOM mit einem Vollständigkeitsstatus pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded.

Das Build-Netzwerk hat eine Richtlinie

Die Funktion IP-Bereiche von CircleCI leitet Jobs über bekannte CircleCI-Adressen, damit Ihre eigenen Systeme sie per Allowlist zulassen können. Das löst den eingehenden Zugriff. CRACI ergänzt Kontrolle in die andere Richtung: Egress-Richtlinien für jeden Job, standardmäßig blockieren oder standardmäßig erlauben, mit 24 integrierten Presets für Softwarequellen, typisierten benutzerdefinierten Quellen und expliziten TLS-, TCP-, UDP- und ICMP-Regeln. Richtlinien werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed). CRACI bietet außerdem einen festen IP-Bereich für ausgehenden Verkehr.

Provenienz und Überwachung aus derselben Aufzeichnung

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

Was passt

• Bleiben Sie bei CircleCI, wenn Ihr Code auf GitLab oder Bitbucket liegt, wenn Sie auf Windows-, macOS- oder GPU-Builds angewiesen sind oder wenn Sie Jobs auf Ihrer eigenen Hardware ausführen.
• Ziehen Sie CRACI in Betracht, wenn Ihr Code auf GitHub liegt, Sie GitHub Actions gegen CircleCI abwägen und Sie Software ausliefern, bei der Sie zeigen müssen, was in jedes Release eingeflossen ist.
• Setzen Sie beide ein während eines schrittweisen Umstiegs: Behalten Sie macOS- und Windows-Pipelines auf CircleCI und lassen Sie Linux-Workflows für GitHub Actions dort auf CRACI laufen, wo Build-Nachweise am wichtigsten sind.

Für den Cyber Resilience Act

Der EU Cyber Resilience Act erwartet 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. Auf CircleCI kommen diese Nachweise von den Scannern und Orbs, die Sie in Ihre Pipelines einbinden. CRACI erzeugt sie aus der Build-Aufzeichnung und exportiert SBOMs als CycloneDX oder SPDX, einschließlich Schwachstellen. Es automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen.

Eine Pipeline auf CRACI umziehen

CRACI führt GitHub-Actions-Workflows aus, eine CircleCI-Pipeline braucht also zuerst ein Gegenstück in GitHub Actions. Sobald es das gibt, 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. Jobs erhalten Docker Engine, Buildx und Compose v2, Runner-Größen von 1 bis 32 vCPU mit 3 GB RAM pro vCPU und Unterstützung für den GitHub-Actions-Cache. Erfahren Sie mehr über SBOM-Generierung während des Builds, oder sehen Sie sich die Preise und das Startup-Programm an.