CRACI vs. Dependency-Track

Was Dependency-Track gut kann

OWASP Dependency-Track ist eine starke Wahl für die Komponentenanalyse. Es ist Open Source unter der Apache-2.0-Lizenz, verfolgt die Komponentennutzung über jede Version jeder Anwendung in Ihrem Portfolio und bezieht Schwachstellendaten aus mehreren Quellen, darunter der National Vulnerability Database und den GitHub Advisories. Seine Policy-Engine deckt Sicherheits-, Lizenz- und Betriebsregeln ab, und es verarbeitet und erzeugt CycloneDX-VEX-Dokumente. Sein API-First-Design passt zu CI/CD: Pipelines laden SBOMs nach /api/v1/bom hoch.

Teams in regulierten Branchen schätzen es, weil es transparent und selbst gehostet ist und auf einem Standardformat aufbaut. Seine Schwäche liegt nicht in der Analyse, sondern in dem, was hineingeht.

Die Analyse hängt von ihrer Eingabe ab

Dependency-Track verarbeitet SBOMs, erzeugt sie aber nicht. Jeder Befund, jeder Policy-Verstoß und jede Portfolio-Ansicht hängt von der SBOM ab, die Ihre Pipeline sendet. Fehlt in der SBOM eine Abhängigkeit, kann Dependency-Track sie nicht melden. Widersprechen sich zwei Generatoren, zeigt Dependency-Track das, was Sie hochgeladen haben.

In der Praxis widersprechen sich SBOM-Generatoren häufig, und die Gründe stehen in ihrer eigenen Dokumentation:

• Keine gemeinsame Basis. Jeder Generator entscheidet selbst, was als Komponente zählt und welchen Dateien er vertraut, sodass zwei von ihnen für dasselbe Repository überlappende, aber unterschiedliche Listen liefern.
• Das Offensichtliche fehlt. Ein Tool, das Abhängigkeiten aus Lockfiles auflöst, hat in einem Repository, das keines committet, nichts aufzulösen, wie bei express 5.2.1. Es kann trotzdem eine Liste liefern, bestehend aus allem anderen, was es erkennt, etwa GitHub Actions und Workflow-Dateien.
• Konfiguration macht den Unterschied. Syft wählt seine Cataloger nach Scan-Typ aus, sodass ein einziges Flag ändert, was dasselbe Tool in derselben Version aus demselben Checkout meldet.
• Kein Manifest, keine SBOM. Ein Repository ganz ohne Abhängigkeitsmanifest gibt einem dateibasierten Scanner nichts an die Hand, und was jedes Tool dann liefert, sagt mehr über das Tool als über das Projekt.
• Dünne Metadaten. Die meisten Generatoren haben keine Quelle für das NTIA-Lieferantenfeld, es bleibt also leer, was auch immer das Repository enthält.

CRACI lässt sich so nicht vergleichen. Es zeichnet Builds auf, statt ein Verzeichnis zu scannen, und lässt sich daher nicht auf dieselbe Weise ausführen. Der Punkt ist nicht, dass eines dieser Tools schlecht wäre, sondern dass der statische Scan eines Repositorys eine Schätzung dessen ist, was ein Build nutzen wird, und diese Schätzung variiert mit dem Tool, seinen Einstellungen und den vorhandenen Dateien.

Was CRACI an der Quelle ändert

Die SBOM stammt aus dem Build

CRACI ist ein GitHub-Actions-kompatibler Runner. Sie ändern runs-on auf craci, und Ihre Jobs laufen auf CRACI in isolierten virtuellen Maschinen. Während jedes Jobs zeichnet ein paketbewusster Proxy den Datenverkehr zu den Paketquellen auf: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen, dazu Download-Presets. Die Abhängigkeitsnachweise reisen mit CI-Caches mit, sodass ein aus einem Cache wiederhergestelltes Paket weiterhin in der Aufzeichnung steht. Die SBOM, als CycloneDX oder SPDX, enthält alle transitiven Abhängigkeiten, die der Build tatsächlich genutzt hat.

Sie sagt Ihnen, wenn sie unvollständig ist

Jede CRACI-SBOM trägt einen Vollständigkeitsstatus pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Sie wissen, ob jede SBOM eine vollständige Aufzeichnung ist oder eine Lücke hat. Das zählt, wenn ein Auditor fragt, woher Sie wissen, dass Ihr Inventar vollständig ist.

Es zeichnet die SBOM im Build auf

CRACI erzeugt die SBOM in seinem eigenen Runner aus dem, was der Job geladen hat. Die API liefert SBOMs, Netzwerk-Traces und Provenienz.

Es kontrolliert, was der Build erreichen kann

Weil CRACI den Job ausführt, kann es eine Netzwerk-Egress-Richtlinie durchsetzen: standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen und typisierten eigenen Quellen. Richtlinien werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed). Dependency-Track kann Ihnen im Nachhinein sagen, dass eine Komponente riskant ist; eine Egress-Richtlinie begrenzt von vornherein, aus welchen Quellen ein Build laden konnte.

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 nutzen, statt es aus Release Notes und Tabellen zusammenzusuchen.

Dependency-Track durch CRACI ersetzen

CRACI deckt beide Hälften der Aufgabe ab, für die es bisher einen Generator und Dependency-Track brauchte. Es erzeugt die SBOM im Build, bewertet überwachte SBOMs laufend neu, wenn neue Schwachstellen veröffentlicht werden, führt Befunde über Builds und Repositories hinweg zusammen und lässt Sicherheitsteams sie sichten und jeden an das Team weiterleiten, das für den Fix zuständig ist. Sie müssen keinen Upload-Schritt pflegen und keinen Server betreiben.

Seien Sie sich darüber im Klaren, worauf Sie verzichten. Die Policy-Engine von Dependency-Track ist ausgereift. CRACI hat Policy-Gates, die Builds blockieren, und eine Lizenzrichtlinie, während Kommentare und Schwellenwert-Warnungen auf der Roadmap sind. Dependency-Track ist außerdem Open Source und selbst gehostet, während CRACI heute ein verwalteter Dienst ist; vom Kunden gehostete Runner sind für Enterprise auf der Roadmap. Wenn Ihnen das wichtiger ist als die Qualität des Inventars, behalten Sie Dependency-Track.

Warum das in regulierten Branchen zählt

Nach dem EU Cyber Resilience Act müssen Hersteller wissen, was in jedem Produkt-Release steckt, und dessen Schwachstellen behandeln, mit Meldepflichten für aktiv ausgenutzte Schwachstellen ab September 2026. Eine Schwachstelle, die Sie nicht sehen, weil Ihrer SBOM die Komponente fehlt, bleibt Ihre Schwachstelle.

CRACI automatisiert einen wesentlichen Teil der Transparenz und Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen, und exportiert SBOMs als CycloneDX oder SPDX, einschließlich Schwachstellen. Inventar und Überwachung stammen aus derselben Aufzeichnung dessen, woraus jedes Release gebaut wurde. Siehe CRA-Compliance, Industrial IoT und Telekommunikation.