CRACI vs. Sonatype

Die kurze Antwort

Die Stärke von Sonatype ist Open-Source-Governance: Policies, die entscheiden, welche Komponenten erlaubt sind, eine Firewall, die schädliche Pakete am Repository stoppt, und Analysen, die zeigen, was in Ihrer Anwendung gelandet ist. CRACI ist ein GitHub-Actions-kompatibler CI-Runner, der jede externe Abhängigkeit aufzeichnet, die ein Build lädt, und aus dieser Aufzeichnung SBOM, Provenienz und Compliance-Nachweise erzeugt. Sonatype ist ein Scanner und ein Torwächter. CRACI ist ein Rekorder, dessen Policy-Gates einen Build außerdem aufgrund von Befunden blockieren können. Die meisten Teams, die beides brauchen, würden sie nebeneinander betreiben.

Welches Sonatype-Produkt was ist

Sonatype verkauft mehrere Produkte, und die Namen sind für diesen Vergleich wichtig:

• Sonatype Lifecycle ist das Produkt für Software Composition Analysis (SCA) und Policies, selbst gehostet oder als SaaS.
• Sonatype Repository Firewall blockiert Komponenten, die Ihre Policies nicht erfüllen, und stellt sie unter Quarantäne, bevor sie in Ihre Repositories gelangen. Sie ist für Sonatype Nexus Repository ausgelegt. Sonatype Firewall Pro deckt andere Repository-Manager wie JFrog Artifactory, Cloudsmith und GitHub Packages ab, für npm, Maven, PyPI und NuGet.
• Sonatype SBOM Manager importiert, überwacht und teilt SBOMs, mit einem VEX-Workflow.

Das Produktangebot ändert sich. Laut der Preisseite von Sonatype sind alle Lifecycle-Funktionen jetzt in Sonatype Guide enthalten, neue Kunden kaufen Guide für SCA und Governance, und Guide umfasst auch die Compliance-Funktionen von SBOM Manager.

Auf einen Blick

Was Sonatype gut kann

Policies im großen Maßstab. Lifecycle wird mit 18 Standard-Policies und mehr als 30 anpassbaren Constraints für Sicherheits-, Rechts- und Architekturregeln ausgeliefert. Die Lizenz-Policies umfassen mehr als 2.000 Open-Source-Lizenzen. Es priorisiert Befunde mit Daten zu Erreichbarkeit, Breaking Changes und verfügbaren Upgrades und kann Golden Pull Requests mit den vorgeschlagenen Upgrades öffnen.

Ein Blick auf das, was der Build erzeugt hat. Lifecycle-Integrationen nutzen standardmäßig Advanced Binary Fingerprinting, das nach dem Build alles untersucht, was in der Anwendung enthalten ist, einschließlich eingebetteter Abhängigkeiten, und umbenannte oder veränderte Komponenten erkennen kann. Erst dann greift es auf Lockfiles und Manifeste zurück. Jeder Scan-Bericht lässt sich als CycloneDX- oder SPDX-SBOM exportieren.

Schädliche Pakete an der Tür stoppen. Repository Firewall setzt Ihre Sicherheits-, Lizenz- und Qualitätsstandards beim Download durch und stellt verdächtige Komponenten unter Quarantäne. CRACI hat heute kein Gegenstück: Paket-Blocklists sind auf der Roadmap.

Passt in jede Pipeline. Sonatype integriert sich in Jenkins, GitHub Actions, GitLab CI, Azure DevOps und Bamboo, dazu Maven, Gradle und eine CLI für andere CI-Server. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap.

Worin sich CRACI unterscheidet

Es zeichnet den Build auf, statt sein Ergebnis zu analysieren

Binary Fingerprinting zeigt Ihnen, was in der fertigen Anwendung steckt. Es zeigt nicht, was der Build unterwegs heruntergeladen hat: Compiler und Toolchains, Install-Skripte, Basis-Images, mit curl geladene Release-Binärdateien oder aus einem Cache wiederhergestellte Pakete. CRACI sieht sie, weil es der Runner ist. Ein paketbewusster Proxy beobachtet während des Jobs den Datenverkehr zu Paketquellen und deckt npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen ab, dazu Quell- oder Download-Presets. Die Abhängigkeitsnachweise reisen mit CI-Caches, sodass auch gecachte Pakete erfasst bleiben.

Jede SBOM gibt ihre eigene Vollständigkeit an, pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Hat die Aufzeichnung eine Lücke, wissen Sie es.

Es kontrolliert, wohin der Build darf

Repository Firewall regelt, was durch das Repository kommt. Eine Egress-Richtlinie von CRACI regelt, was der Build überhaupt erreichen kann. Richtlinien sind standardmäßig sperrend oder 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. Sie werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed). Zusammen stellen beide sicher, dass Build-Jobs Pakete nur aus den von Ihnen freigegebenen Quellen laden und dass diese Quellen nur Pakete ausliefern, die Sie erlauben.

Es behält das Ausgelieferte im Blick

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

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.

Wann Sie beide einsetzen

• Sie betreiben bereits Nexus Repository mit Firewall. Behalten Sie es als Kontrollpunkt. Ergänzen Sie CRACI, damit jeder Build eine Aufzeichnung dessen hat, was er geladen hat, und eine Egress-Richtlinie, die Builds bei Ihren freigegebenen Quellen hält.
• Ihre Rechtsabteilung verlässt sich auf Lifecycle-Lizenz-Policies. Behalten Sie sie. CRACI nimmt die deklarierten Lizenzmetadaten in seinen SBOM-Export auf und setzt ebenfalls eine Lizenzrichtlinie durch.
• Sie sammeln SBOMs in SBOM Manager. SBOM Manager importiert CycloneDX und SPDX, dieselben Formate, die CRACI exportiert, sodass Build-Time-SBOMs neben denen liegen können, die Sie bereits verwalten.
• Ihre Pipelines laufen auf Jenkins oder Azure DevOps. Sonatype passt heute. CRACI bräuchte diese Pipelines zuerst auf GitHub Actions; Jenkins ist auf der Roadmap.

Für den Cyber Resilience Act

Sonatype veröffentlicht einen CRA-Leitfaden und eine CRA-Checkliste und positioniert SBOM Manager als sein CRA-Produkt. Der Leitfaden hebt das Erzeugen von VEX-Dateien zur Meldung bekannter Schwachstellen in SBOMs hervor sowie Nexus Repository als Update-Site zum Verteilen von Sicherheitsupdates.

CRACI deckt die Nachweisseite aus dem Build ab: eine SBOM für jedes Release mit angegebener Vollständigkeit, Provenienz, kontinuierliche Schwachstellenüberwachung und SBOM-Export 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 Tools macht ein Produkt allein konform. Siehe CRA-Compliance und Was ist der CRA?.

CRACI neben Sonatype einsetzen

CRACI ersetzt den Runner, nicht GitHub Actions. Ändern Sie in einem Workflow runs-on auf craci, und Läufe erscheinen weiterhin in der GitHub-Oberfläche. Ihre Sonatype-Schritte bleiben im Workflow. Beginnen Sie mit einer Release-Pipeline, vergleichen Sie die SBOM von CRACI mit Ihrem Lifecycle-Bericht und schauen Sie, was nur eines von beiden gesehen hat.