Software-Lieferkettensicherheit, aus jedem Build aufgezeichnet
Ihre Software-Lieferkette trifft im CI-Build auf Ihr Produkt. CRACI führt Ihre GitHub-Actions-Jobs auf sicheren Runnern aus und zeichnet jede Abhängigkeit auf, die sie laden, steuert, was jeder Build erreichen kann, und verfolgt Schwachstellen in dem, was Sie ausgeliefert haben, laufend weiter.
Sichere Runner für GitHub Actions
Ändern Sie runs-on auf craci, und Ihre GitHub-Actions-Jobs laufen auf den Runnern von CRACI, während die Läufe weiterhin in GitHub erscheinen. Jeder Job erhält eine eigene isolierte virtuelle Maschine unter Linux auf x86-64 oder ARM64, gehostet in Europa. Builds laufen etwa doppelt so schnell wie auf GitHub-gehosteten Runnern, dank schnellerer Hardware, kürzerer Wartezeiten und Caching.
Eine SBOM aus jedem Build
CRACI zeichnet auf, statt zu scannen. Ein paketbewusster Proxy auf dem Runner sieht jedes Paket, das der Job lädt, aus npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen, dazu Yocto- und OpenEmbedded-Download-Presets, auch Pakete aus CI-Caches. Die SBOM jedes Jobs trägt einen Vollständigkeitsstatus und lässt sich als CycloneDX oder SPDX exportieren, mit transitiven Abhängigkeiten und der deklarierten Lizenz jeder Komponente.
Steuern, was ein Build erreichen kann
Eine Egress-Richtlinie legt fest, mit welchen Hosts sich ein Job verbinden darf: Default-Deny oder Default-Allow, 24 integrierte Presets für Softwarequellen, typisierte eigene Quellen für Paket-Registries und Git sowie explizite Netzwerkregeln. Die Richtlinie wird vor dem Start des Jobs validiert und blockiert im Fehlerfall (Fail-closed), und Verstöße lösen eine Warnung aus. Eine kompromittierte Abhängigkeit oder ein kompromittierter Build-Schritt kann keine Daten unbemerkt an einen Host senden, den Sie nie freigegeben haben.
Provenienz für das, was Sie ausliefern
Die öffentliche REST-API liefert SBOMs, Netzwerk-Traces und Provenienzdaten für jeden Job, alle aus demselben Build aufgezeichnet. Die Nachweise entstehen im Build selbst, ohne zusätzlichen Schritt im Workflow.
Schwachstellenverfolgung nach dem Release
CRACI bewertet die SBOMs dessen, was Sie ausgeliefert haben, laufend neu, sobald neue Schwachstellen veröffentlicht werden, und führt Befunde über Builds und Repositories hinweg zusammen. Sicherheitsteams sichten sie und geben jeden Befund an das Team weiter, das für die Behebung zuständig ist. Policy-Gates können einen Build wegen Befunden oder einer Lizenz blockieren, VEX wird unterstützt, Lieferanten-SBOMs werden zusammen mit Ihren eigenen Builds überwacht, und die Inventaransicht zeigt, welche Softwareversionen in welchen Produkten eingesetzt sind.
Nachweise für Kunden und Auditoren
Kunden, Auditoren und Vorschriften verlangen immer häufiger eine SBOM pro Release und eine Dokumentation darüber, wie Schwachstellen behandelt wurden. CRACI exportiert SBOMs als CycloneDX oder SPDX, einschließlich der in ihren Komponenten gefundenen Schwachstellen, und eine öffentliche REST-API liefert SBOMs, Netzwerk-Traces und Provenienzdaten. Dieselben Nachweise unterstützen den EU Cyber Resilience Act, NIS2, die SBOM-Anforderungen der FDA und die Lieferketten-Controls von ISO 27001.
Die Fragen, die ein Vorfall in der Lieferkette aufwirft
Wird ein Paket, eine CI-Action oder eine Registry kompromittiert, vergehen die ersten Stunden mit der Klärung, ob Sie betroffen sind. Das sind die Fragen, die Teams stellen, und so beantwortet die Build-Aufzeichnung von CRACI sie.
| Die Frage | Wie CRACI sie beantwortet |
|---|---|
| Hat einer unserer Builds die kompromittierte Paketversion geladen? | Die SBOM jedes Builds listet die Pakete, die der Job tatsächlich geladen hat. Sie durchsuchen also aufgezeichnete Builds, statt Repositories erneut zu scannen. |
| Welche unserer Produkte und Releases sind betroffen? | Überwachte SBOMs werden laufend neu bewertet, und die Inventaransicht ordnet Softwareversionen den Produkten zu, in denen sie eingesetzt sind. |
| Könnte ein Build-Schritt Secrets irgendwohin gesendet haben? | Der Netzwerk-Trace jedes Jobs zeichnet seine Verbindungen auf, und die Egress-Richtlinie blockiert Hosts außerhalb der Richtlinie, bevor sie erreicht werden. |
| Ist diese SBOM vollständig genug, um sie weiterzugeben? | Die SBOM jedes Jobs gibt ihre Vollständigkeit an: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. |
| Wer behebt das, und können wir belegen, dass es behandelt wurde? | Befunde werden gesichtet und an die zuständigen Teams weitergegeben, und SBOMs lassen sich als CycloneDX oder SPDX exportieren, mit den in ihren Komponenten gefundenen Schwachstellen. |
CRACI deckt den Build ab und das, was er ausliefert. Code-Scanning, Secret-Scanning und Erreichbarkeitsanalyse bleiben bei Ihren Tools für Anwendungssicherheit. GitHub Actions wird heute unterstützt, weitere CI-Systeme sind auf der Roadmap.
Software-Lieferkettensicherheit: Antworten
Was sie umfasst, warum sie in CI/CD gehört und wo CRACI ansetzt
Was ist Software-Lieferkettensicherheit?
Software-Lieferkettensicherheit schützt alles, was zwischen dem ersten Commit und dem Release in Ihre Software einfließt: Open-Source-Abhängigkeiten, Basis-Images, Build-Tools, CI-Actions von Drittanbietern, die CI-Pipeline selbst und die Artefakte, die Sie ausliefern. Es geht darum, diese Bestandteile zu kennen, zu steuern, woher sie kommen, und nachzuweisen, was in jedes Release eingeflossen ist.
Warum die Software-Lieferkette in CI/CD absichern?
Im Release-Build werden Ihre Abhängigkeiten aufgelöst, heruntergeladen und paketiert. Ein Produktions-Build ist nicht der Build auf einem Laptop: Versionsbereiche, veränderliche Tags und Caches führen dazu, dass er etwas anderes laden kann. Eine Aufzeichnung, die während des Release-Builds entsteht, ist die einzige verlässliche Aufzeichnung dessen, was ausgeliefert wurde, und am Build-Runner können Sie steuern, was der Build erreichen darf.
Wie unterscheidet sich CRACI von einem Scanner für Lieferkettensicherheit?
Scanner lesen Dateien im Nachhinein: ein Manifest, ein Lockfile, Quellcode oder eine fertige Binärdatei. CRACI ist der Runner für Ihre GitHub-Actions-Jobs, beobachtet den Build also, während er läuft, und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, auch Pakete aus CI-Caches. Jede SBOM gibt ihre eigene Vollständigkeit an, eine Egress-Richtlinie steuert, was der Build erreichen kann, und die API liefert SBOMs, Netzwerk-Traces und Provenienzdaten.
Ersetzt CRACI meine GitHub-Actions-Workflows?
Nein. CRACI ersetzt den Runner, nicht GitHub Actions. Sie ändern runs-on auf craci, und Ihre Workflows, Trigger und Laufhistorie bleiben in GitHub.
Welche CI-Systeme und Plattformen unterstützt CRACI?
Heute GitHub Actions; weitere CI-Systeme sind auf der Roadmap, darunter GitLab CI und Jenkins. Die Runner laufen unter Linux auf x86-64 und ARM64, Windows und macOS sind auf der Roadmap.
Bietet CRACI SAST, Secret-Scanning oder Erreichbarkeitsanalyse?
Nein. CRACI zeichnet den Build auf und steuert ihn, verfolgt Schwachstellen in dem, was Sie ausgeliefert haben, und erzeugt die Nachweise. Das Scannen Ihres eigenen Codes auf Fehler oder Secrets und die Erreichbarkeitsanalyse sind Aufgaben für ein Tool für Anwendungssicherheit.
Wo werden meine Build-Daten gespeichert?
CRACI wird in Europa gehostet, auf europäischer Bare-Metal-Infrastruktur, und Daten werden standardmäßig 180 Tage aufbewahrt, mit individueller Aufbewahrungsdauer im Enterprise-Plan. CRACI speichert Ihren Quellcode nicht. CRACI ist nach ISO 27001 zertifiziert; Details finden Sie im Trust Center.
Sehen Sie, was Ihre Builds tatsächlich laden
Buchen Sie eine Demo und sehen Sie SBOM, Netzwerk-Trace, Egress-Richtlinie und Provenienzdaten, die CRACI für einen GitHub-Actions-Build aufzeichnet
Demo buchen