Vergleich
CRACI vs. Legit Security
Legit Security beobachtet, wie Ihre Softwarefabrik aufgesetzt ist und gesteuert wird. CRACI ist die Maschine, auf der Ihr Build läuft, und führt Aufzeichnungen darüber, was dieser Build tatsächlich getan hat.
Aktualisiert am
Die kurze Antwort
Legit Security ist eine Plattform für Application Security Posture Management (ASPM). Sie verbindet sich mit Ihrer Quellcodeverwaltung, Ihrem CI, Ihren Registries und Scannern, bildet Ihren Softwareentwicklungs-Lebenszyklus ab, setzt darin Richtlinien durch und führt Sicherheitsbefunde in einer priorisierten Ansicht zusammen. CRACI ist ein GitHub-Actions-Runner, der aufzeichnet, was jeder Build lädt, kontrolliert, was der Build erreichen kann, und das Ausgelieferte weiter überwacht. Legit steuert die Pipeline von außen; CRACI ist die Ausführungsschicht der Pipeline. Beide verkaufen an Teams mit dem Auftrag, „unsere Software-Lieferkette abzusichern“, und manche Teams werden beides wollen.
Auf einen Blick
| Funktion | CRACI | Legit Security |
|---|---|---|
| Führt Ihre Builds aus | Jobs laufen auf CRACI-Runnern | Verbindet sich mit Ihren SCM- und CI-Systemen |
| Aus dem Build aufgezeichnete Abhängigkeiten | Beobachtete Abrufe, einschließlich Paketen aus CI-Caches | Native SCA, dazu Befunde der Scanner, die Sie einsetzen |
| Egress-Richtlinie für das Build-Netzwerk | Standardmäßig sperrend oder erlaubend, blockiert im Zweifel (fail closed) | Außerhalb des Umfangs: Legit führt keine Builds aus |
| SBOM-Export | Jeder Build, mit Vollständigkeit pro Job und Cache | Erstellt und exportiert SBOMs |
| Signierte Provenienz | Keine signierte Provenienz | Signierte Software-Attestierungen |
| SDLC- und Pipeline-Posture | Bildet SDLC-Systeme, Pipelines und Sicherheitskontrollen ab | |
| SAST und Secrets-Erkennung | Natives SAST und Secrets-Scanning | |
| Konsolidiert andere Scanner | Korreliert und dedupliziert vorhandene Scanner-Befunde | |
| Compliance-Reporting | SBOMs in CycloneDX oder SPDX, Aufzeichnungen über die API; kein Berichtsexport | ISO 27001, SSDF, SLSA, SOC 2 und weitere |
| CI-Systeme | Heute GitHub Actions; GitLab CI und Jenkins auf der Roadmap | GitHub Actions, GitLab CI, Jenkins, Azure DevOps Pipelines, CircleCI und weitere |
- Enthalten
- Teilweise
- Nicht enthalten
Was Legit Security gut kann
Den gesamten SDLC sehen. Das Produkt von Legit für Software-Lieferkettensicherheit will „discover and correlate your entire SDLC automatically“ und führt ein laufend aktualisiertes Inventar der SDLC-Assets und ihrer Sicherheitskontrollen, mit visuellen Modellen von Systemen und Pipelines. Für ein Sicherheitsteam, das Hunderte von Repositories und mehrere CI-Systeme geerbt hat, ist diese Karte schon für sich wertvoll.
Richtlinien über viele Systeme hinweg. Laut Legit setzt es Hunderte von Richtlinien durch, um SDLC-Systeme, CI/CD-Pipelines, Code und Teams abzusichern. Die Liste der Integrationen ist breit: GitHub, GitLab, Bitbucket und Azure DevOps für die Quellcodeverwaltung; GitHub Actions, GitLab CI, Jenkins, CircleCI, TeamCity und andere für CI; Container- und Paket-Registries wie JFrog Artifactory und Sonatype Nexus; dazu Cloud-Plattformen.
Eine Ansicht der Befunde. Legit orchestriert vorhandene Scanner wie Snyk, Checkmarx, Veracode und GitHub Advanced Security und korreliert und dedupliziert dann deren Befunde. Es bietet außerdem natives SAST und SCA, wobei Erreichbarkeitsanalyse und die Erkennung von Lizenzrisiken 2025 hinzukamen.
Secrets und KI-generierter Code. Seine Secrets-Erkennung reicht über den Quellcode hinaus in die Git-Historie, Build-Logs und gemeinsame Arbeitsbereiche wie Slack, Confluence und Jira. VibeGuard bringt seine Prüfungen für KI-generierten Code in die IDE. Legit veröffentlicht außerdem Legitify, ein Open-Source-Tool unter Apache 2.0, das unsichere GitHub- und GitLab-Einstellungen findet.
SBOMs und Attestierungen. Legit erstellt SBOMs und signierte Software-Attestierungen und unterstützt Compliance-Reporting nach Frameworks wie ISO 27001, SSDF, SLSA, NIST, SOC 2 und PCI DSS.
Worin sich CRACI unterscheidet
Eine Posture-Plattform liest Konfigurationen und Scanner-Ausgaben über APIs. Sie kann Ihnen sagen, dass eine Pipeline riskant aufgesetzt ist. Den Netzwerkverkehr eines laufenden Jobs kann sie nicht sehen, weil sie nicht die Maschine ist, auf der der Job läuft. CRACI ist es.
Der Build ist die Quelle der Wahrheit
Ihr Workflow wechselt mit einer einzeiligen Änderung an runs-on zu CRACI. Ein paketbewusster Proxy zeichnet dann auf, was
jeder Job von Paketquellen über npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen hinweg herunterlädt, und aus
CI-Caches wiederhergestellte Pakete werden fortgeschrieben. Jede SBOM gibt an, wie vollständig sie ist, pro Job und pro Cache:
Complete, Complete with connections, Incomplete, Unavailable oder Not recorded. Die SBOM beschreibt, was der Build geladen hat, nicht
was er laut einem Manifest hätte laden sollen.
Kontrolle, nicht nur Transparenz
Eine Egress-Richtlinie auf dem Runner entscheidet, welche Hosts ein Job erreichen darf. Richtlinien sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen und typisierten eigenen Quellen. Sie werden vor dem Start des Jobs validiert, blockieren im Zweifel (fail closed) und senden bei einem Verstoß eine Warnung. Ein Posture-Befund sagt Ihnen, dass Sie eine Einstellung korrigieren sollen; eine Egress-Richtlinie stoppt die Verbindung während des Builds.
Nachweise aus dem Build
Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht. Es bewertet überwachte SBOMs laufend neu, sobald neue Schwachstellen veröffentlicht werden, und führt Befunde über Builds und Repositories hinweg zusammen.
Auch hier zählt, was CRACI nicht leistet. Es hat kein SAST, kein Secrets-Scanning, kein SDLC-Inventar und keine Zusammenführung von Scannern, und es unterstützt heute nur GitHub Actions; GitLab CI und Jenkins 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.
Was passt und wann Sie beide einsetzen
- Sie betreiben viele SCM- und CI-Systeme und brauchen eine Governance-Schicht. Legit. Entscheidend ist hier seine breite Abdeckung von GitHub, GitLab, Bitbucket, Azure DevOps, Jenkins und mehr.
- Sie brauchen den Nachweis, was in jedes Release eingeflossen ist. CRACI. Die Aufzeichnung stammt vom Runner, mit Vollständigkeitsstatus.
- Ein kompromittiertes Paket versucht während eines Builds, nach Hause zu telefonieren. Die Egress-Richtlinie von CRACI blockiert Verbindungen außerhalb der erlaubten Quellen. Die Ad-hoc-Abfragen von Legit über Ihren SDLC helfen bei der anschließenden Untersuchung.
- Sie nutzen Legit bereits und bauen auf GitHub Actions. Behalten Sie Legit für Posture, Secrets und Befunde. Verlegen Sie die Builds, die Sie ausliefern, auf CRACI-Runner, damit SBOM, Provenienz und Netzwerkaufzeichnung aus dem Build selbst stammen.
Für den CRA
Der Cyber Resilience Act verlangt von Herstellern, die Komponenten ihrer Produkte zu dokumentieren, einschließlich einer SBOM, und Schwachstellen zu behandeln, solange ein Produkt unterstützt wird. Die Meldepflicht für aktiv ausgenutzte Schwachstellen gilt ab September 2026. Legit hilft, indem es den Entwicklungsprozess steuert und über die Sicherheits-Posture berichtet. CRACI hilft, indem es pro Build Nachweise darüber erzeugt, was in jedes Release eingeflossen ist, mit Provenienz, laufender Überwachung und SBOM-Export als CycloneDX oder SPDX. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen; keines der beiden Tools macht ein Produkt allein konform. Lesen Sie, was der CRA verlangt und wie CRACI die CRA-Compliance unterstützt.
CRACI neben Legit Security einsetzen
Setzen Sie runs-on: craci in den Workflows, die bauen, was Sie ausliefern. CRACI ersetzt den Runner, nicht GitHub Actions,
die Repositories und Workflows bleiben also in GitHub, und Läufe erscheinen weiterhin in der GitHub-Oberfläche. CRACI exportiert SBOMs
in CycloneDX und SPDX für jedes Tool, das sie verarbeiten kann. Teams mit Pipelines auf GitLab, Jenkins oder Azure DevOps müssten diese Builds
zu GitHub Actions verlegen, um CRACI-Runner zu nutzen. GitLab CI und Jenkins sind auf der Roadmap. Mehr über
SBOM-Generierung während des Builds und
CI/CD-Integration.
Sie wägen mehr als zwei Tools ab? Legit-Security-Alternativen vergleicht neun Optionen nebeneinander.
Führen Sie einen echten Build aus und vergleichen Sie
Stellen Sie einen GitHub-Actions-Workflow auf CRACI um und sehen Sie, was es aufzeichnet, im Vergleich zu dem, was Ihre Posture-Tools bereits berichten.
Demo buchen