CRACI vs. Syft und Grype

Die kurze Antwort

Syft ist ein beliebter Open-Source-SBOM-Generator, und Grype ist der zugehörige Schwachstellenscanner. Zusammen decken sie Erzeugung und Abgleich kostenlos ab, in jeder Pipeline. CRACI ist ein GitHub-Actions-Runner, der aufzeichnet, was jeder Build geladen hat, angibt, ob diese Aufzeichnung vollständig ist, kontrolliert, wohin sich der Build verbinden darf, und das Ausgelieferte weiter überwacht. Der Unterschied in einem Satz: Syft rekonstruiert die SBOM aus Dateien, und wie viel es findet, hängt von seiner Konfiguration und davon ab, was beim Lauf auf der Festplatte liegt. CRACI beobachtet sie und verfolgt die Schwachstellen in dem, was es aufgezeichnet hat, sodass ein Produkt die Aufgabe beider erledigt.

Was Syft und Grype gut können

Syft ist „a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems.“ Es erkennt Dutzende Paketsysteme, von Alpine, Debian und RPM bis zu Go, Python, Java, JavaScript, Ruby, Rust, PHP und .NET. Es schreibt CycloneDX, SPDX und sein eigenes Syft JSON, konvertiert zwischen Formaten und kann signierte SBOM-Attestations nach der in-toto-Spezifikation erstellen.

Grype scannt Container-Images, Dateisysteme und SBOMs auf bekannte Schwachstellen. Es priorisiert Befunde mit EPSS, KEV und Risikobewertung, unterstützt OpenVEX zum Filtern der Ergebnisse, und sein Flag --fail-on lässt eine Pipeline fehlschlagen, wenn es Schwachstellen ab einem von Ihnen gewählten Schweregrad findet. Anchore weist darauf hin, dass Grype „runs entirely locally and doesn't send any data to external services“, abgesehen vom Download seiner Datenbank.

Beide stehen unter Apache-2.0 und werden von Anchore gesponsert, dessen kommerzielle Plattform Anchore Enterprise „builds on open source Syft and Grype.“ Diese Seite behandelt die Open-Source-Tools.

Syft ist stark, wenn es die richtigen Dateien vor sich hat. Bei einem Quellbaum, der seine Abhängigkeiten committet, etwa ollama/ollama, löst der Standard-Scan sie mit Versionen, Package-URLs und den Abhängigkeitskanten dazwischen auf.

Ein Flag ändert die Antwort

Syft wählt seine Cataloger nach Scan-Typ aus, und seine Dokumentation erklärt, warum: „files that hint at the intent to install software do not have enough information in them to determine the exact version.“ Cataloger tragen Tags wie declared, installed, image und directory, und Flags wie --select-catalogers und --override-default-catalogers ändern die Auswahl.

In syft cataloger list bei v1.51.1 ist der JavaScript-Cataloger, der node_modules liest, für Image- und Installed-Scans getaggt und gehört bei einem Verzeichnis-Scan nicht zur Standardauswahl. Bei einem installierten Checkout entscheidet also ein Flag, ob die npm-Pakete in node_modules überhaupt gelesen werden. Dasselbe Tool, dieselbe Version, derselbe Baum.

Die Kehrseite ist genauso wichtig. Keine einzelne Konfiguration passt überall:

• Bei einem sauberen Checkout von express 5.2.1, das kein Lockfile hat, findet der Standard-Scan keine npm-Abhängigkeiten zum Auflösen und liefert nur, was er sonst erkennt, etwa GitHub Actions und Workflow-Dateien.
• Schalten Sie die Installed-Cataloger ein und setzen Sie sie auf Quellbäume im committeten Zustand an, in denen noch nichts installiert wurde, und sie haben fast nichts zu lesen.
• Ein Repository ganz ohne Abhängigkeitsmanifest gibt dem Scan keine Abhängigkeitsdateien zu lesen, unabhängig von der Konfiguration.

Nichts davon ist ein Fehler. Syft meldet, was die vorliegenden Dateien hergeben, wie vorgesehen. Die praktische Folge ist, dass die SBOM von zwei Entscheidungen abhängt, die in jeder Pipeline jemand richtig treffen muss: welche Cataloger laufen und ob Abhängigkeiten vor dem Scan installiert wurden. Und Grype kann nur abgleichen, was Syft aufgelistet hat. Eine Komponente, die in der SBOM fehlt, erreicht die Schwachstellensuche nie, der Scan ist für sie also sauber.

Worin sich CRACI unterscheidet

Bei CRACI gibt es keine Cataloger auszuwählen, weil es den Baum nicht im Nachhinein liest. Sie ändern runs-on auf craci, und ein paketbewusster Proxy zeichnet auf, was der Job von npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen lädt, dazu Download-Presets. Aus einem CI-Cache wiederhergestellte Pakete nehmen ihre Nachweise mit. Das Ergebnis, als CycloneDX oder SPDX, enthält die transitiven Abhängigkeiten, die der Build tatsächlich genutzt hat.

• Vollständigkeit ist explizit. Jeder Job und jeder Cache ist als Complete, Complete with connections, Incomplete, Unavailable oder Not recorded gekennzeichnet.
• Der Build wird kontrolliert. Eine Egress-Richtlinie (standardmäßig sperrend oder erlaubend, 24 integrierte Presets für Softwarequellen) wird vor dem Start des Jobs validiert und blockiert im Zweifel (fail closed).
• Provenienzdaten. Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht; eine Syft-Attestation signiert die SBOM.
• Überwachung. Überwachte SBOMs werden laufend neu bewertet, und Befunde werden über Builds und Repositories hinweg zusammengeführt.

Grype kann weiterhin Dinge, die CRACI nicht kann. VEX-Filterung und das Scannen von Images, die Sie nicht gebaut haben, sind das Gebiet von Grype. Die Policy-Gates von CRACI können den Build fehlschlagen lassen; Schwellenwert-Alarme sind auf der Roadmap.

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.

Wechsel von Syft und Grype

Auf CRACI gibt es keine SBOM zu erzeugen und keinen Scan-Schritt zu pflegen. Der Runner zeichnet die SBOM auf, während der Build läuft, und CRACI prüft sie auch nach Abschluss des Builds weiter auf neue Schwachstellen. Syft und Grype bleiben die Tools für Images und Drittanbieter-Software, die Sie nicht gebaut haben, und für Pipelines außerhalb von GitHub Actions.

Für den Cyber Resilience Act

Der CRA verlangt von Herstellern, die Komponenten jedes Produkts zu dokumentieren, einschließlich einer SBOM, und dessen Schwachstellen zu behandeln. Syft und Grype können diese SBOM erzeugen und prüfen, und die Nachweiskette von jedem Release zurück zu seiner SBOM bauen Sie selbst. CRACI zeichnet die SBOM pro Build auf und exportiert sie 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. Siehe Was ist der CRA? und SBOM-Generierung während des Builds.