Sie scannen Ihre Abhängigkeiten bereits. Das kann ein Scanner nicht sehen.

Was Ihr aktueller Stack gut macht

Wenn Sie SCA und SBOM-Generierung eingerichtet haben, haben Sie die schwierige organisatorische Arbeit bereits erledigt: Abhängigkeiten werden verfolgt, Advisories erreichen die Entwickler, und es gibt eine Datei, die Sie vorlegen können, wenn jemand danach fragt. Behalten Sie das bei.

• GitHubs Abhängigkeitsgraph und Dependabot sind bei vielen Teams standardmäßig aktiv. GitHub beschreibt den Abhängigkeitsgraphen als Zusammenfassung der im Repository gespeicherten Manifest- und Lockfiles sowie aller Abhängigkeiten, die über die Dependency Submission API für das Repository eingereicht werden. Dependabot-Warnungen bauen darauf auf und benachrichtigen Sie, wenn ein neues Advisory veröffentlicht wird oder sich Ihr Abhängigkeitsgraph ändert.
• Kommerzielle SCA-Tools wie Snyk erzeugen ebenfalls SBOMs. Der Befehl snyk sbom liest Manifest-Dateien und ihre Lockfiles und gibt CycloneDX oder SPDX aus. Stand September 2026 ist er laut der Dokumentation von Snyk nur für Kunden mit Snyk-Enterprise-Plänen verfügbar.
• Open-Source-Generatoren wie Syft, Trivy und cdxgen sind kostenlos, schnell und leicht ins CI einzubinden. Syft beschreibt sich selbst als Tool, das aus Container-Images und Dateisystemen eine Software Bill of Materials (SBOM) erzeugt.

Am stärksten sind diese Tools bei schnellem Feedback auf Pull Requests, breiter Abdeckung von Ökosystemen und einem Behebungs-Workflow, den Entwickler bereits kennen. CRACI ersetzt das heute nicht. Seine Schwachstellenverfolgung aggregiert Befunde über Builds und Repositories hinweg und bewertet überwachte SBOMs neu, sobald neue Schwachstellen auftauchen. Sicherheitsteams können Befunde sichten und an das richtige Team weiterleiten. Policy-Gates können einen Build blockieren; Schwachstellen-Webhooks sind auf der Roadmap.

Scanner oder Rekorder

Jedes Tool oben ist ein Scanner. Sie richten es auf einen Quellbaum, ein Lockfile oder ein Container-Image, und es leitet ab, was eingeflossen ist. Das funktioniert, wenn die Dateien das ganze Bild zeigen. Schwieriger wird es, wenn sie das nicht tun:

• Das Repository hat kein Lockfile, also werden Versionen erst bei der Installation festgelegt.
• Der Build stellt Pakete aus einem CI-Cache wieder her, den kein Manifest erwähnt.
• Ein Build-Schritt lädt direkt ein Tool, ein Betriebssystempaket oder eine Binärdatei herunter.
• Ein npm-Install-Hook oder ein Rust-Build-Skript lädt während der Installation weiteren Code, der Weg, den der Wurm Shai-Hulud nutzte.
• Ein Container-Build lädt ein Basis-Image und dessen Betriebssystem-Layer, die kein Sprach-Lockfile aufführt.
• Was Sie ausliefern, ist eine kompilierte Binärdatei, und das Manifest daneben führt fast nichts auf.

CRACI ist ein Rekorder: Es sieht den Datenverkehr, Scanner nicht. Es führt den Build auf seinem eigenen, mit GitHub Actions kompatiblen Runner aus, und ein paketbewusster Proxy beobachtet den Datenverkehr zu Paketquellen, während der Job läuft, sodass diese versteckten Abhängigkeiten in der SBOM landen. Aus einem Cache wiederhergestellte Pakete nehmen ihre Nachweise mit. Einen Befehl craci scan ./dir gibt es nicht, denn das nachträgliche Scannen eines Verzeichnisses ist genau der Schritt, den CRACI vermeiden soll.

Wovon ein Scan abhängt

Die Ausgabe eines Scanners hängt vom Tool ab und davon, worauf es gerichtet ist. Syft, Trivy, cdxgen, das Microsoft SBOM Tool, der Export des GitHub-Abhängigkeitsgraphen und die Socket CLI ermitteln die Liste jeweils aus dem, was sie lesen können. Die Muster unten ergeben sich daraus, wie diese Tools laut ihrer Dokumentation arbeiten.

Keine Komponente wird von jedem Tool gefunden

Jeder Generator entscheidet selbst, was als Komponente zählt und welchen Dateien er vertraut, sodass derselbe Checkout bei jedem eine andere Liste ergibt. Der Export des GitHub-Abhängigkeitsgraphen arbeitet noch einmal anders: Er entsteht aus dem, was GitHub über das Repository weiß, statt aus Dateien, die ein Scanner liest, und er liest den Default-Branch statt eines gepinnten Commits.

Kein Lockfile, keine Abhängigkeiten

Express 5.2.1 committet kein Lockfile. Auf einen sauberen Checkout gerichtet, hat ein Generator, der Abhängigkeiten aus Lockfiles oder einem installierten Baum auflöst, weder das eine noch das andere vor sich, sodass keine der in package.json deklarierten npm-Abhängigkeiten ins Dokument gelangt. Keines der Tools hier ist defekt. Die Variable, die entscheidet, ob die SBOM überhaupt Abhängigkeiten enthält, ist nicht das Tool. Es ist die Frage, ob vorher jemand eine Installation ausgeführt hat.

Ein Flag ändert die Antwort

Der Standard-Verzeichnisscan von Syft meldet, was ein Projekt deklariert, nicht was auf der Festplatte installiert ist. Bei einem installierten Checkout desselben Express-Releases entscheidet ein Cataloger-Flag, ob die installierten npm-Pakete überhaupt in der Liste erscheinen. Dasselbe Tool, dieselbe Version, derselbe Baum.

Das Produkt ist eine Binärdatei

Das Repository anthropics/claude-code hat in v2.1.259 keinerlei Abhängigkeitsmanifest oder Lockfile. Sein veröffentlichtes npm-Paket deklariert null Laufzeitabhängigkeiten und verpackt über acht Plattformpakete eine vorgefertigte native Binärdatei. @openai/codex 0.149.1 ist genauso aufgebaut. Ein Manifest-Leser hat fast nichts zu beschreiben, während das laufende Programm eine kompilierte Binärdatei ist, sodass das, was jedes Tool zurückgibt, mehr über das Tool aussagt als über das Projekt.

Dasselbe Paket, unterschiedliche Versionen

Auch wo zwei Tools dasselbe finden, sind sie sich nicht immer einig, was es ist. Das eine pinnt eine GitHub Action vielleicht auf einen Commit-SHA, während das andere ein Release-Tag meldet. Eine Schwachstellensuche mit der falschen Version liefert selbstsicher eine falsche Antwort.

Wo CRACI neben Ihrem SCA ansetzt

Behalten Sie Ihr SCA für Pull Requests. Dort lässt sich eine verwundbare Version am besten abfangen, bevor sie gemergt wird. Ergänzen Sie CRACI dort, wo es um den Build geht statt um den Diff:

• Was enthielt dieses Release tatsächlich? Die aufgezeichnete SBOM deckt npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen sowie Download-Presets ab, einschließlich transitiver Abhängigkeiten. JFrog-Artifactory-Mirrors für npm und PyPI funktionieren ebenfalls.
• Können wir der Liste vertrauen? Jeder Job und Cache hat einen Vollständigkeitsstatus, eine unvollständige Aufzeichnung ist also sichtbar, statt unbemerkt dünn zu bleiben.
• Sind wir von einem neuen Advisory betroffen? Überwachte SBOMs werden neu bewertet, sobald neue Schwachstellen veröffentlicht werden, und Befunde werden über Builds und Repositories hinweg aggregiert.

Die SBOM lässt sich über die öffentliche REST-API als CycloneDX herunterladen, zusammen mit dem Netzwerk-Trace und der Provenienz des Jobs, sodass sie jedes Tool speisen kann, das CycloneDX liest, einschließlich des SCA, das Sie bereits nutzen. Die Einrichtung ist eine Zeile im Workflow: Ändern Sie runs-on auf craci. GitHub Actions ist heute das unterstützte CI; GitLab CI, Jenkins und andere CI-Systeme 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 nutzen, statt es mühsam aus Release Notes und Tabellen zusammenzusuchen.

Lesen Sie mehr über SBOM-Generierung während des Builds und Schwachstellenverfolgung.