CRACI und Chainguard

Die kurze Antwort

Chainguard baut Open-Source-Software aus dem Quellcode und liefert sie gehärtet aus: minimale Container-Images mit wenigen oder keinen bekannten Schwachstellen, neu gebaute Sprachbibliotheken, VM-Images und gehärtete GitHub Actions, jeweils mit signierter SBOM und Provenienz. Wenn Ihr Problem darin besteht, dass die Basis-Images und Pakete, mit denen Sie starten, zu viele CVEs mitbringen, packt Chainguard genau das an.

CRACI ist ein CI-Runner für GitHub Actions. Ihre Jobs laufen darauf, und während sie laufen, zeichnet CRACI jede externe Abhängigkeit auf, die sie laden, und setzt eine Egress-Richtlinie durch. Chainguard sichert die Inputs ab. CRACI sichert den Build ab und zeichnet ihn auf. Die Überschneidung ist sehr gering, und beide ergänzen sich ganz natürlich.

Auf einen Blick

Was Chainguard gut macht

Chainguard Containers ist, in den Worten von Chainguard, ein Zero-CVE-Katalog von Container-Images, die aus dem Quellcode gebaut werden. Jedes Image kommt mit einer signierten SBOM-Attestierung im SPDX-Format und einer SLSA-1.0-Provenienz-Attestierung, die die Build-Umgebung beschreibt, alles mit cosign überprüfbar. Kunden können bei neueren Builds auch CycloneDX-SBOMs erhalten.

Die CVE-Richtlinie ist konkret. Für Kunden mit einem Auftrag sagt Chainguard zu, kritische CVEs innerhalb von 7 Kalendertagen und hohe, mittlere und niedrige CVEs innerhalb von 14 Kalendertagen zu beheben, nachdem ein qualifizierender Patch öffentlich verfügbar ist, und zwar für die unterstützten Versionsstränge seiner Images.

Chainguard Libraries wendet denselben Ansatz auf Sprachpakete an. Es ist ein Katalog von Java-, Python- und JavaScript-Abhängigkeiten, die aus verifiziertem Quellcode neu gebaut statt als vorkompilierte Artefakte heruntergeladen werden, bereitgestellt als Upstream für JFrog Artifactory, Sonatype Nexus Repository oder Cloudsmith. Jedes Paket trägt Sigstore-Signaturen, eine signierte SBOM und SLSA-Level-3-Provenienz. Chainguard Actions bietet gehärtete Versionen beliebter GitHub Actions, aus dem Quellcode gebaut und laufend gescannt, und Chainguard VMs überträgt das Modell auf Images virtueller Maschinen.

CRACI erzeugt keine gehärteten Images oder Bibliotheken und macht keine Zusage zur CVE-Anzahl von irgendetwas, das Sie beziehen. Das ist die Aufgabe von Chainguard.

Worin sich CRACI unterscheidet

Es beobachtet Ihren Build, nicht den von Chainguard

Die SBOMs und die Provenienz von Chainguard beschreiben die Artefakte von Chainguard, gebaut in der Fabrik von Chainguard. Ihr Build läuft trotzdem irgendwo, und er lädt mehr als ein Basis-Image: Ihre eigenen Abhängigkeiten, Toolchains, von Install-Skripten geladene Tools und alles, was ein Workflow-Schritt herunterlädt. CRACI zeichnet das auf. Ein paketbewusster Proxy auf dem Runner beobachtet den Datenverkehr zu Paketquellen über npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen hinweg. Die Nachweise reisen mit CI-Caches, und jede SBOM gibt ihre Vollständigkeit pro Job und pro Cache an: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded.

Es begrenzt, was der Build erreichen kann

Gehärtete Inputs helfen nur, wenn der Build sie tatsächlich verwendet. Die Egress-Richtlinie von CRACI blockiert oder erlaubt standardmäßig, mit 24 integrierten Presets für Softwarequellen und typisierten benutzerdefinierten Quellen für Registries, einschließlich OCI-Registries und Git. Richtlinien werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed). Eine Richtlinie, die Ihre Chainguard-Registry und Ihr Artefakt-Repository erlaubt und kaum etwas anderes, macht „wir verwenden Chainguard“ von einer Konvention zu etwas, das der Runner durchsetzt.

Es überwacht weiter, was Sie ausgeliefert haben

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI bewertet überwachte SBOMs laufend auf neue Schwachstellen. SBOMs lassen sich als CycloneDX oder SPDX exportieren, einschließlich Schwachstellen.

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.

Beide zusammen einsetzen

Ein typisches Setup:

• Chainguard liefert Basis-Images und, über Ihr Artefakt-Repository, neu gebaute Bibliotheken.
• CRACI führt die GitHub-Actions-Jobs aus, die darauf bauen, mit einer Egress-Richtlinie, die Ihre freigegebenen Quellen erlaubt, und zeichnet auf, was jeder Job geladen hat.

OCI gehört zu den Ökosystemen, die CRACI erkennt, und CRACI funktioniert mit JFrog-Artifactory-Spiegeln für npm und PyPI. Images sowie Python- oder JavaScript-Pakete, die auf diesem Weg ankommen, sind daher Teil der Build-Aufzeichnung. Unterstützung für Maven, die Chainguard Libraries für Java abdeckt, ist auf der Roadmap.

Was passt

• Scanner melden immer wieder CVEs in Ihren Basis-Images: Chainguard ersetzt diese Images durch gehärtete.
• Sie brauchen Nachweise darüber, was in jedes Release eingeflossen ist: CRACI zeichnet es im Build auf.
• Ihre Builds sollen nur freigegebene Quellen erreichen können: Die Egress-Richtlinie von CRACI setzt das am Runner durch.
• Sie wollen sowohl saubere Inputs als auch einen aufgezeichneten Build: Setzen Sie beide zusammen ein, wie oben beschrieben.

Für den Cyber Resilience Act

Mit Komponenten zu starten, die wenige bekannte Schwachstellen haben, eine dokumentierte SLA zur Behebung und signierte SBOMs mitbringen, erleichtert einem Hersteller die Behandlung von Schwachstellen. Dabei hilft Chainguard. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen: was in jedes Release eingeflossen ist und eine fortlaufende Schwachstellenverfolgung. Keines von beiden macht ein Produkt für sich allein konform. Lesen Sie, was der CRA ist, und mehr zu CRA-Compliance.

CRACI zu einem Chainguard-Setup hinzufügen

Installieren Sie die CRACI GitHub App und ändern Sie dann runs-on auf craci in den Workflows, die aufgezeichnet werden sollen. Ihre Dockerfiles und Ihre Paketkonfiguration bleiben, wie sie sind. CRACI unterstützt heute GitHub Actions; GitLab CI, Jenkins und weitere CI-Systeme sind auf der Roadmap. Mehr über SBOM-Generierung während des Builds und CI/CD-Integration.