CRACI vs. Mend.io

Die kurze Antwort

Mend.io ist eine Plattform für Anwendungssicherheit. Mend AppSec kombiniert Mend SAST für Ihren eigenen Code mit Mend SCA für Open-Source-Abhängigkeiten und Container, und Mend Renovate hält Abhängigkeiten mit automatisierten Pull Requests aktuell. CRACI ist ein GitHub-Actions-kompatibler CI-Runner, der jede externe Abhängigkeit aufzeichnet, die ein Build lädt, und aus dieser Aufzeichnung SBOM, Provenienz und Compliance-Nachweise erzeugt. Mend ist ein Scanner. CRACI ist ein Rekorder. Wenn Sie heute Mend nutzen, fügt CRACI eine Ebene hinzu, statt eine zu ersetzen.

Auf einen Blick

Was Mend.io gut kann

Priorisieren, was erreichbar ist. Mend SCA verfolgt den Aufrufgraphen von Ihrem Code durch direkte und transitive Abhängigkeiten, um zu ermitteln, ob Ihre Anwendung eine verwundbare Funktion tatsächlich aufruft. Das verkürzt die Liste der Befunde, um die sich ein Team kümmern muss. CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen, führt aber keine Erreichbarkeitsanalyse durch.

Code ebenso wie Abhängigkeiten. Mend SAST deckt mehr als 30 Sprachen ab, und die Mend CLI scannt Open-Source-Komponenten, eigenen Code, Container-Images und Infrastructure as Code. CRACI leistet nichts davon.

Abhängigkeiten aktuell halten. Mend Renovate öffnet Pull Requests für veraltete Pakete über mehr als 90 Paketmanager hinweg. Die Editionen Renovate CLI und Community sind kostenlos; Enterprise ergänzt Sicherheitsfunktionen und Support.

Lizenzen, bösartige Pakete und SBOMs. Mend SCA erkennt die Lizenzen direkter und transitiver Abhängigkeiten und setzt Richtlinien durch, etwa das Blockieren von AGPL in kommerziellen Produkten. Es kennzeichnet Typosquats, Dependency Confusion und Pakete mit Hintertüren oder Code zur Datenexfiltration. Es erzeugt SPDX- und CycloneDX-SBOMs, nimmt SBOMs von Dritten auf und wendet VEX-Daten an.

Worin sich CRACI unterscheidet

Beobachtung statt Rekonstruktion

Die Dokumentation von Mend selbst empfiehlt, nach dem Build-Schritt zu scannen, weil der Build dem Scanner Zugriff auf private Registries und externe Artefakte verschafft und ein Scan ohne Build ungenaue Ergebnisse liefern kann. Das ist der richtige Instinkt. CRACI geht einen Schritt weiter: Statt das Projekt nach Abschluss des Builds zu lesen, zeichnet es den Build selbst auf.

Ein paketbewusster Proxy auf dem CRACI-Runner beobachtet während des Jobs den Datenverkehr zu Paketquellen, für npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen, dazu Download-Presets. Die Abhängigkeitsnachweise reisen mit CI-Caches mit, sodass auch aus einem Cache wiederhergestellte Pakete erfasst werden. Jede SBOM gibt ihre Vollständigkeit pro Job und pro Cache an: Complete, Complete with connections, Incomplete, Unavailable oder Not recorded.

Kontrolle über das Build-Netzwerk

Weil CRACI den Job ausführt, kann es begrenzen, wohin der Job sich verbindet. Egress-Richtlinien sind standardmäßig sperrend oder standardmäßig erlaubend, mit 24 integrierten Presets für Softwarequellen und typisierten eigenen Quellen für npm, PyPI, apt, apk, den Go-Proxy, Nix, Cargo, OCI-Registries und Git. Sie werden vor dem Start des Jobs validiert und blockieren im Zweifel (fail closed). Mend erkennt ein bösartiges Paket, sobald es in Ihrem Abhängigkeitsbaum ist. Eine Egress-Richtlinie begrenzt von vornherein, welche Quellen ein Build erreichen kann. Die beiden Ebenen greifen zu unterschiedlichen Zeitpunkten.

Nachweise aus dem Build

Die API liefert SBOMs, Netzwerk-Traces und Provenienz. CRACI signiert Provenienz nicht.

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

• Ihr Hauptproblem ist ein Rückstau an Befunden in Code und Abhängigkeiten. Mend ist mit SAST, Erreichbarkeit und Renovate dafür gebaut.
• Sie müssen belegen, was in jedes Release eingeflossen ist. CRACI zeichnet es pro Build auf und gibt an, wie vollständig die Aufzeichnung ist.
• Ihre Builds tun mehr, als aus einem Lockfile zu installieren. Bei Toolchain-Downloads, Basis-Images und curl-Abrufen bringt die Beobachtung am meisten.
• Ihre Pipelines laufen auf Azure DevOps, Bitbucket oder CircleCI. Mend passt heute. CRACI unterstützt heute nur GitHub Actions; GitLab CI und Jenkins sind auf der Roadmap.

Für den Cyber Resilience Act

Mend.io veröffentlicht einen Leitfaden zur CRA-Compliance und eine Compliance-Seite, die seine Produkte der Verordnung zuordnet: Mend AppSec für CycloneDX- und SPDX-SBOMs und erreichbarkeitsbasierte Priorisierung, Mend Renovate für die laufende Schwachstellenbehandlung durch Abhängigkeits-Updates und Lizenz-Compliance, dokumentiert neben der Sicherheitslage.

CRACI trägt Nachweise aus dem Build bei: eine SBOM für jedes Release mit angegebener Vollständigkeit, Provenienz, laufende Überwachung und SBOM-Export 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. Kein einzelnes Tool macht ein Produkt konform. Siehe CRA-Compliance und Was der CRA ist.

CRACI neben Mend.io einsetzen

CRACI ersetzt den Runner, nicht GitHub Actions. Ändern Sie runs-on in einem Workflow auf craci, und Läufe erscheinen weiterhin in der GitHub-Oberfläche. Ihr Mend-CLI-Schritt bleibt, wo er ist: nach dem Build. Führen Sie eine Release-Pipeline auf CRACI aus und vergleichen Sie ihre SBOM mit dem Inventar von Mend für denselben Commit.