Vergleich
CRACI und Dependabot
Dependabot ist oft das erste Lieferketten-Tool, das ein GitHub-Team einschaltet, und es sollte eingeschaltet bleiben. CRACI ergänzt, was Dependabot nie sehen sollte: was Ihre Builds tatsächlich getan haben.
Aktualisiert am
Behalten Sie Dependabot. Das deckt es ab.
Wenn Ihr Code auf GitHub liegt, nutzen Sie Dependabot vermutlich bereits. Es leistet drei nützliche Dinge. Dependabot-Warnungen sagen Ihnen, wenn eine Abhängigkeit in Ihrem Repository einer bekannten Schwachstelle entspricht. Security Updates öffnen Pull Requests, die verwundbare Abhängigkeiten aktualisieren. Version Updates halten Abhängigkeiten aktuell, auch wenn nichts verwundbar ist.
All das baut auf dem Abhängigkeitsgraphen von GitHub auf, der die Manifeste und Lockfiles in Ihrem Repository auswertet. GitHub kann diesen Graphen als SPDX-SBOM exportieren. Für Ökosysteme wie Go, Gradle und Maven können vorgefertigte Actions zur Build-Zeit aufgelöste Abhängigkeiten über die Dependency Submission API einreichen.
Um Abhängigkeiten mit wenig Aufwand gepatcht zu halten, ist Dependabot kaum zu schlagen, und CRACI öffnet keine Pull Requests. CRACI ergänzt die andere Hälfte: eine Aufzeichnung dessen, was jeder Build tatsächlich geladen hat, überwacht auf neue Schwachstellen, sodass Sie wissen, welche ausgelieferten Builds ein neues Advisory betrifft und welche Update-Pull-Requests Sie zuerst mergen sollten.
Die Fragen, die Dependabot nicht beantwortet
Dependabot ist um das Repository herum gebaut. Es scannt den Default-Branch und stützt sich auf Ihre Manifeste und Lockfiles. Die Dokumentation von GitHub sagt das direkt: Warnungen können nicht jedes Sicherheitsproblem erfassen, Sie sollten Manifeste und Lockfiles für eine genaue Erkennung aktuell halten, und nur von GitHub geprüfte Advisories lösen Warnungen aus.
Damit bleiben Fragen, die einer Sicherheits- oder Compliance-Leitung irgendwann gestellt werden:
- Was hat der Build für Release 4.2 tatsächlich heruntergeladen, einschließlich Tools und Images, die in keinem Manifest stehen?
- Konnte ein Build während der Ausführung einen beliebigen Host im Internet erreichen?
- Können Sie belegen, dass die Binärdatei, die ein Kunde erhalten hat, aus diesem Build stammt?
- Können Sie diesen Nachweis Monate später für einen Auditor vorlegen?
Um das zu beantworten, braucht es den Blick aus dem Build heraus, und genau dort läuft CRACI.
| Funktion | CRACI | Dependabot |
|---|---|---|
| Führt Ihre Builds aus | Jobs laufen auf CRACI-Runnern | Liest Repository-Daten, nicht den Build |
| Abhängigkeiten aus dem Build aufgezeichnet | Beobachtete Abrufe, einschließlich Wiederherstellungen aus CI-Caches | Manifeste und Lockfiles, plus Dependency Submission API |
| SBOM-Export | CycloneDX und SPDX, Vollständigkeit pro Job und Cache | SPDX-Export des Abhängigkeitsgraphen |
| Netzwerk-Egress-Richtlinie für den Build | Standardmäßig sperrend oder erlaubend, blockiert im Zweifel (fail closed) | Außerhalb des Aufgabenbereichs |
| Schwachstellenwarnungen | Zusammengeführt über Builds und Repositories | Aus von GitHub geprüften Advisories |
| Überwachung auf neue Advisories | Überwachte SBOMs werden laufend neu bewertet | Warnungen für den Default-Branch, wenn Advisories hinzukommen |
| Öffnet Update-Pull-Requests | Security Updates und Version Updates | |
| Triage und Weiterleitung an zuständige Teams | Über Builds und Repositories hinweg | Warnungen pro Repository |
| Funktioniert ohne Runner-Wechsel | Jobs müssen auf CRACI laufen | In GitHub-Repositories integriert |
| Compliance-Nachweise | SBOMs als CycloneDX oder SPDX, Aufzeichnungen über die API; kein Berichtsexport | Warnungsansichten und der SPDX-Export in GitHub |
- Enthalten
- Teilweise
- Nicht enthalten
Was CRACI ergänzt
Transparenz zur Build-Zeit
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 die Läufe weiterhin in der GitHub-Oberfläche erscheinen.
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. Aus CI-Caches wiederhergestellte Pakete werden
mitgeführt, weil die Abhängigkeitsnachweise mit dem Cache reisen.
Jede SBOM gibt an, wie vollständig sie ist, pro Job und pro Cache: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Das unterscheidet sie von einem Graphen, der nur so gut ist wie die Dateien, die er auswertet.
Der Unterschied zeigt sich in der Praxis. Der Export des Abhängigkeitsgraphen von GitHub entsteht aus dem, was GitHub über das Repository weiß. Er kann also Komponenten auflisten, die kein dateibasierter Scanner findet, und er spiegelt den Default-Branch wider statt des Commits, den Sie gebaut haben. Für den Zweck des Graphen ist beides nicht falsch. Es zeigt aber, warum eine Repository-Ansicht und eine Build-Aufzeichnung verschiedene Dinge sind. (CRACI lässt sich so nicht vergleichen, da es Builds aufzeichnet, statt Verzeichnisse zu scannen.)
Kontrollen zur Laufzeit
Dependabot informiert Sie über ein verwundbares Paket, nachdem es in Ihrem Manifest steht. Worauf ein Build zugreifen kann, darauf hat Dependabot keinen Einfluss. Bei CRACI ist das anders, weil es den Build ausführt. Egress-Richtlinien sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen, typisierten eigenen Quellen für npm, PyPI, apt, apk, den Go-Proxy, Nix, Cargo, OCI-Registries und Git sowie expliziten Regeln für TLS, TCP, UDP und ICMP. Richtlinien werden vor dem Start des Jobs validiert, blockieren im Zweifel (fail closed) und lösen bei einem Verstoß eine Warnung aus.
Provenienz
CRACI erzeugt die SBOM in seinem eigenen Runner aus dem, was der Job geladen hat. Die API liefert SBOMs, Netzwerk-Traces und Provenienz.
Compliance-Nachweise
Regulierungen wie der EU Cyber Resilience Act verlangen von Herstellern, zu wissen, was in jedem Produkt-Release steckt, und dessen Schwachstellen zu behandeln. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen, bewertet überwachte SBOMs laufend neu, wenn neue Advisories erscheinen, und exportiert SBOMs als CycloneDX oder SPDX, einschließlich Schwachstellen. Es automatisiert einen wesentlichen Teil der Transparenz und Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen. Mehr dazu unter Was ist der CRA und CRA-Nachweise.
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.
Wie Teams beide nutzen
- Dependabot hält Abhängigkeiten auf dem Default-Branch gepatcht und öffnet Pull Requests, wenn Advisories erscheinen.
- CRACI führt die GitHub-Actions-Jobs aus, zeichnet auf, was jeder Build geladen hat, begrenzt, wohin sich Builds verbinden können, überwacht das von jedem Build Geladene auf neue Schwachstellen und bewahrt die Release-Nachweise auf.
Es gibt nichts zu migrieren. Dependabot arbeitet weiter auf Ihren Repositories, und Ihre Workflows laufen weiter auf GitHub Actions, nur auf einem anderen Runner.
CRACI unterstützt heute GitHub Actions, also genau den Ort, an dem auch Dependabot zu Hause ist. Lesen Sie mehr über SBOM-Generierung während des Builds, Schwachstellenverfolgung und Preise.
CRACI und Dependabot: häufige Fragen
Was jedes Tool abdeckt, SBOMs, Preise und Compliance
Ersetzt CRACI Dependabot?
Nein. Lassen Sie Dependabot eingeschaltet. Es kennzeichnet verwundbare Abhängigkeiten in Ihren Repositories und öffnet Pull Requests, die sie aktualisieren. CRACI führt Ihre GitHub-Actions-Jobs aus, zeichnet auf, was jeder Build tatsächlich geladen hat, kontrolliert, wohin sich Builds verbinden können, und überwacht das Ausgelieferte auf neue Schwachstellen.
Ersetzen die Schwachstellenansichten von CRACI die Dependabot-Warnungen?
Nein. Sie beantworten eine andere Frage. Dependabot-Warnungen betreffen den Default-Branch eines Repositorys. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs laufend neu, sodass Sie sehen, welche Builds eine verwundbare Abhängigkeit teilen, und Sicherheitsteams Befunde sichten und an das Team schicken können, das für den Fix zuständig ist. Policy-Gates können einen Build blockieren; Schwellenwert-Warnungen sind auf der Roadmap.
Öffnet CRACI Pull Requests wie Dependabot?
Nein. Dependabot Security Updates und Version Updates öffnen Pull Requests, CRACI nicht. CRACI ergänzt die Build-Aufzeichnung: Wenn ein neues Advisory erscheint, wissen Sie, welche ausgelieferten Builds es betrifft und welche Update-Pull-Requests Sie zuerst mergen sollten.
Wie unterscheiden sich die SBOMs von GitHub und CRACI?
GitHub exportiert den Abhängigkeitsgraphen als SPDX-SBOM, erstellt aus den Manifesten und Lockfiles im Repository und der Dependency Submission API, und sie spiegelt den Default-Branch wider. CRACI zeichnet die SBOM auf, während jeder Build läuft, und exportiert sie als CycloneDX oder SPDX, mit einem Vollständigkeitsstatus pro Job und pro Cache, der Ihnen sagt, ob die Aufzeichnung eine Lücke hatte.
Hilft CRACI, wenn eine Abhängigkeit in keinem Manifest steht?
Ja, wenn der Build sie aus einer Paketquelle lädt. Weil CRACI den Datenverkehr während des Jobs aufzeichnet, erscheint ein von einem Skript heruntergeladenes Tool oder ein aus einem Cache wiederhergestelltes Paket trotzdem in der Build-Aufzeichnung, und der Vollständigkeitsstatus der SBOM sagt Ihnen, ob etwas nicht aufgezeichnet werden konnte.
Was kosten Dependabot und CRACI?
Dependabot Security Updates und Version Updates sind in jedem GitHub-Plan enthalten, auch in Free (Stand September 2026). CRACI berechnet nur Build-Minuten: $0.002 pro vCPU-Minute ($0.004 für einen Standard-Runner mit 2 vCPU), sekundengenau abgerechnet, ohne Monatsgebühr und ohne Gebühr pro SBOM. Die aktuellen Konditionen finden Sie unter Preise.
Ist CRACI nur für Teams mit Compliance-Anforderungen?
Nein, aber dort zahlen sich die Nachweise am meisten aus. Wenn Sie Software in der EU verkaufen, gehören durch den Cyber Resilience Act ein Komponenteninventar pro Release und die Behandlung von Schwachstellen zu Ihren Aufgaben. Für alle anderen bleibt das Wissen darüber, was Ihre Builds laden, die Grundlage der Reaktion auf Lieferkettenvorfälle. Buchen Sie eine Demo, um die Build-Aufzeichnung eines Ihrer eigenen Workflows zu sehen.
Sehen Sie, was Dependabot nicht sieht
Führen Sie einen GitHub-Actions-Workflow auf CRACI aus und vergleichen Sie seine Build-Aufzeichnung mit Ihrem Abhängigkeitsgraphen.
Demo buchen