CRA-Compliance-Tools im Vergleich

Für wen diese Seite gedacht ist

Sie stellen ein Produkt mit digitalen Elementen her und bringen es auf den EU-Markt. Der Cyber Resilience Act, Verordnung (EU) 2024/2847, gilt für Sie in Stufen: seine Meldepflichten ab dem 11. September 2026 und seine wesentlichen Bestimmungen ab dem 11. Dezember 2027. Sie wählen Tools für die technischen Teile dieser Arbeit aus. Wir entwickeln CRACI, berücksichtigen Sie das. Wir beschreiben jedes Tool anhand seiner eigenen Dokumentation und sagen, wo ein anderes Tool besser passt.

Eine Regel zieht sich durch diese Seite. Compliance ist ein Prozess, den der Hersteller durchführt, mit Risikobewertung, Dokumentation und Konformitätsbewertung. Tools erzeugen Nachweise und automatisieren Teile der Arbeit. Keines der unten genannten Tools macht ein Produkt für sich allein konform.

Was der CRA verlangt

Für die Software-Lieferkette zählen vor allem fünf Anforderungen.

1. Eine SBOM. Hersteller ermitteln und dokumentieren die Komponenten im Produkt, „unter anderem durch Erstellung einer Software-Stückliste in einem gängigen und maschinenlesbaren Format, die zumindest die obersten Abhängigkeiten der Produkte umfasst“ (Anhang I Teil II). Anhang VII verortet sie in der technischen Dokumentation, die eine Marktüberwachungsbehörde anfordern kann.
2. Behandlung von Schwachstellen. Schwachstellen unverzüglich angehen und beheben, auch durch Sicherheitsupdates, regelmäßig testen und eine Richtlinie zur koordinierten Offenlegung von Schwachstellen umsetzen (Anhang I Teil II).
3. Meldungen. Aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über die einheitliche Meldeplattform des CRA an Ihr CSIRT und an ENISA melden: eine Frühwarnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und ein Abschlussbericht spätestens 14 Tage, nachdem für eine Schwachstelle eine Korrektur oder Abhilfemaßnahme verfügbar ist, bzw. innerhalb eines Monats bei einem schwerwiegenden Vorfall (Artikel 14).
4. Nachweise. Technische Dokumentation, eine Konformitätsbewertung und eine EU-Konformitätserklärung (Artikel 28, 31 und 32, Anhang VII), die den Behörden mindestens 10 Jahre nach dem Inverkehrbringen des Produkts oder für den Unterstützungszeitraum zur Verfügung stehen, je nachdem, welcher Zeitraum länger ist (Artikel 13).
5. Ein Unterstützungszeitraum. Ein Zeitraum, der widerspiegelt, wie lange das Produkt voraussichtlich genutzt wird, mindestens fünf Jahre, sofern die erwartete Nutzungsdauer nicht kürzer ist, in dem Schwachstellen wirksam behandelt werden (Artikel 13).

Wie Sie auswählen

• Bei welcher Hälfte der Arbeit brauchen Sie Hilfe? Technische Tools erzeugen die SBOM, die Schwachstellenaufzeichnungen und die Build-Nachweise. Compliance-Management-Plattformen bilden Anforderungen auf Kontrollen ab, entwerfen Richtlinien und verfolgen den Prozess. Die meisten Tools sind in einer Hälfte stark; entscheiden Sie also, welche Lücke größer ist.
• Bauen Sie die Software selbst oder integrieren Sie sie? Wenn ein Großteil des Produkts von Chipherstellern und Lieferanten als Binärdateien kommt, sehen Sie mit der Binäranalyse hinein. Wenn Sie es selbst bauen, ist der Build die direkteste Quelle für Nachweise.
• Woher kommt Ihre SBOM, und woher wissen Sie, dass sie vollständig ist? Scanner, Abfragen von Build-Tools und die Aufzeichnung des Builds können für dasselbe Release unterschiedliche Antworten liefern.
• Finden Sie betroffene Releases innerhalb von Stunden? Eine Frühwarnung binnen 24 Stunden setzt ein Inventar pro Release voraus, dem Sie vertrauen.
• Brauchen Sie ein maßgebliches System? Bei vielen Produkten und Lieferanten wird SBOM-Management mit VEX und Weitergabe zu einer eigenen Aufgabe.

Auf einen Blick

Zwei Tabellen: zuerst SBOM-, SCA- und SBOM-Management-Tools, dann Tools für Firmware und Geräte. Die Zeilen folgen den obigen Anforderungen. „Keine Angabe“ bedeutet, dass die von uns zitierten Seiten des Anbieters dazu weder das eine noch das andere sagen.

SBOM, SCA und SBOM-Management

Firmware und Geräte

CRACI

CRACI ist ein GitHub-Actions-Runner. Für Software, die Sie selbst bauen, zeichnet er auf, was jeder Job geladen hat, einschließlich Paketen aus CI-Caches, und erzeugt eine CycloneDX- oder SPDX-SBOM mit einem Vollständigkeitsstatus pro Job und pro Cache. Er bewertet die SBOMs des Ausgelieferten laufend neu, unterstützt VEX und reicht die CRA-Meldungen in Ihrem Namen ein, wenn eine aktiv ausgenutzte Schwachstelle gemeldet werden muss. Bei Yocto zeichnet er auf, was die eigene SPDX-Ausgabe von Yocto auslässt. Hilft bei: SBOM-Generierung, Behandlung von Schwachstellen, CRA-Meldungen, Nachweisen. Zu beachten: Er analysiert keine Binärdateien, die Sie nicht selbst gebaut haben, bietet keine Zuordnung von Kontrollen und kein Richtlinienmanagement und unterstützt heute GitHub Actions (GitLab CI und Jenkins sind auf der Roadmap). CRA-Compliance mit CRACI

SBOM-Management

Cybeats

Cybeats SBOM Studio bezeichnet sich selbst als „the SBOM system of record“, das maßgebliche System für SBOMs. Es speichert SBOMs Ihrer Produkte und Lieferanten in SPDX 2.2 bis 3.0.1 und CycloneDX 1.2 bis 1.7, validiert sie vor dem Import mit einem Quality Score, gleicht jede Komponente mit Schwachstelleninformationen ab, stellt VEX aus und teilt SBOMs mit Kunden, auch über die Transparency Exchange API. Sein Leitfaden zu Regulierungen legt die Fristen des CRA von 24 Stunden, 72 Stunden und 14 Tagen dar. Hilft bei: SBOM-Management, Behandlung von Schwachstellen, Nachweisen. Zu beachten: Für die Generierung verweist es auf Anbieter in seinem Marketplace, die SBOM selbst stammt also aus einem anderen Tool. CRACI vs. Cybeats und Cybeats-Alternativen

FOSSA

FOSSA begann bei der Lizenz-Compliance und deckt heute den gesamten SBOM-Lebenszyklus ab. Es erzeugt SPDX- und CycloneDX-SBOMs, optional mit VDR- oder VEX-Statements, importiert SBOMs von Lieferanten mit Richtlinien für die Mindestelemente von NTIA und FDA, überwacht sie auf Schwachstellen und teilt sie in Enterprise über ein SBOM Portal. Stand September 2026 gibt es einen kostenlosen Plan, und Business kostet $20 pro Projekt und Monat bei jährlicher Abrechnung. Hilft bei: SBOM, Weitergabe an Behörden, Lizenzen. Zu beachten: Die FOSSA CLI analysiert das Projekt über sein Build-Tool oder zieht Rückschlüsse aus dem Quellcode, statt den Build aufzuzeichnen. CRACI vs. FOSSA

Anchore

Anchore Enterprise baut auf den Open-Source-Tools Syft und Grype auf. Es scannt Container-Images, Dateisysteme und importierte SBOMs, scannt gespeicherte SBOMs ohne das ursprüngliche Artefakt erneut, wendet Richtlinienpakete wie FedRAMP und NIST an und läuft selbst gehostet, auch air-gapped. Seine CRA-Materialien behandeln SBOM-Management, Überwachung anhand von Quellen wie CISA KEV, Unterstützung für die Fristen von 24 und 72 Stunden, VEX-Annotationen und Audit-Trails. Hilft bei: SBOM, Behandlung von Schwachstellen, Nachweisen. Zu beachten: Seine SBOMs beschreiben, was ein Scanner in einem Image oder Verzeichnis findet, nicht, was der Build geladen und zurückgelassen hat. CRACI vs. Anchore

SCA-Suiten

Black Duck

Black Duck SCA kombiniert Paketmanager-, Signatur-, Snippet- und Binärscans und findet so Open Source, das niemand deklariert hat; seine KnowledgeBase erfasst mehr als 2.750 Lizenzen. Binary Analysis untersucht Firmware ohne Quellcode, Coverity bietet SAST mit einer auf den CRA abgestimmten Checker-Option, die im Juli 2026 angekündigt wurde, und Defensics übernimmt Fuzz-Tests. Black Duck vertritt die Ansicht, dass der CRA mehrere Testebenen erfordert, nicht nur SCA. Hilft bei: SBOM, Behandlung von Schwachstellen in Komponenten und eigenem Code, Tests. Zu beachten: Preise gibt es auf Anfrage, und jede Technik untersucht Code oder Ergebnis statt des Builds. CRACI vs. Black Duck

Sonatype

Sonatype Lifecycle setzt Open-Source-Richtlinien mit Daten zu Erreichbarkeit und Upgrades durch und öffnet Golden Pull Requests. Repository Firewall stellt Komponenten, die gegen Richtlinien verstoßen, unter Quarantäne, bevor sie in Ihre Repositories gelangen. SBOM Manager importiert, überwacht und teilt SBOMs mit einem VEX-Workflow, und Sonatype positioniert ihn als sein CRA-Produkt; sein Leitfaden nennt außerdem Nexus Repository als Update-Site für Sicherheitsupdates. Hilft bei: Behandlung von Schwachstellen, SBOM-Management, Fernhalten problematischer Komponenten. Zu beachten: Das Produktangebot ändert sich (Neukunden kaufen Sonatype Guide), und Lifecycle analysiert, was der Build erzeugt hat, nicht, was er geladen hat. CRACI vs. Sonatype

Firmware und Geräte

ONEKEY

ONEKEY analysiert kompilierte Firmware, ganz ohne Quellcode oder Netzwerkzugang („no source code or network access needed“). Es erzeugt eine SBOM aus der Binärdatei, importiert SBOMs von Lieferanten, sucht nach wahrscheinlichen Zero-Days wie fest codierten Zugangsdaten und analysiert Firmware täglich neu. Sein Compliance Wizard führt Teams durch den CRA, IEC 62443-4-2, ETSI EN 303 645 und die Funkanlagenrichtlinie. Hilft bei: SBOM für Firmware, die Sie nicht selbst gebaut haben, Behandlung von Schwachstellen, geführte Prüfungen. Zu beachten: Es arbeitet nach dem Build mit dem Image und zeichnet daher nicht auf, was der Build geladen hat. CRACI vs. ONEKEY und ONEKEY-Alternativen

Finite State

Finite State analysiert Firmware, Binärdateien, Quellcode und SBOMs von Lieferanten, mit Unterstützung für mehr als 50 Befehlssatzarchitekturen, und führt sie in einem Produktdatensatz zusammen. Es priorisiert Befunde nach Erreichbarkeit und Exploit-Informationen, hält VEX-Entscheidungen fest, und sein Compliance-Workflow umfasst die Zuordnung von CRA-Kontrollen und auditfertige Berichte mit SBOM- und VEX-Artefakten. Hilft bei: SBOM über Lieferanten hinweg, Triage von Schwachstellen, Nachweisen. Zu beachten: Es geht von Artefakten aus; zu kontrollieren, was Ihr eigener Build erreichen konnte, liegt außerhalb seines Bereichs. CRACI vs. Finite State und Finite-State-Alternativen

Exein

Exein arbeitet auf dem Gerät. Exein Runtime nutzt eBPF, um schädliches Verhalten auf Embedded Linux zu überwachen und zu blockieren, und der Open-Source-Yocto-Layer meta-exein bringt seinen Pulsar-Agenten in Ihr Image. Exein Analyzer scannt Firmware vor dem Release oder Ihre SBOM, wenn die Binärdatei nicht verfügbar ist, priorisiert mit einer Bewertung der Erreichbarkeit und ordnet Befunde den CRA-Anforderungen zu. Hilft bei: Behandlung von Schwachstellen im Feld, Firmware-SBOM, CRA-Zuordnung. Zu beachten: Der Yocto-Layer verändert, was auf dem Gerät läuft; er führt Ihren Build weder aus noch zeichnet er ihn auf. CRACI vs. Exein

Compliance-Management-Plattformen

Diese Tools erzeugen keine SBOMs und scannen keinen Code. Sie arbeiten an der Governance-Hälfte: die Anforderungen des CRA auf Kontrollen abbilden, Richtlinien entwerfen und Fristen und Freigaben verfolgen. Technische Nachweise müssen von anderswo kommen.

Venvera

Venvera ist eine in der EU entwickelte Compliance-Plattform, die den CRA neben NIS2, DORA, ISO 27001 und SOC 2 abdeckt. Für den CRA verfolgt sie die Meldefristen von 24 und 72 Stunden, die Behandlung von Schwachstellen, die SBOM als fortlaufend gepflegte Anforderung, den Weg der Konformitätsbewertung je Produktklasse sowie die technische Dokumentation nach Anhang VII und die EU-Konformitätserklärung. Hilft bei: Zuordnung von Kontrollen, Meldefristen, Verfolgung des Konformitätsprozesses. Zu beachten: Venvera verfolgt, dass eine SBOM existiert und gepflegt wird; die SBOM selbst stammt aus einem anderen Tool.

ZeroRisk

ZeroRisk ist eine agentenbasierte Compliance-Plattform für DSGVO, ISO 27001, SOC 2, NIS2, DORA und den CRA. Für den CRA bildet ihr Agent die Anforderungen auf Ihre Organisation ab, füllt eine Bereitschaftsbewertung vor, entwirft fehlende Kontrollen und Richtlinien und überwacht die Lieferanten in Ihren Produkten, alle 24 Stunden neu geprüft, mit menschlicher Freigabe jeder Schlussfolgerung. Hilft bei: Bereitschaft, Richtlinien, Lieferantenabsicherung. Zu beachten: Die CRA-Seite von ZeroRisk erwähnt weder SBOM-Generierung noch die Schwachstellenüberwachung Ihrer eigenen Builds.

Melden innerhalb der Fristen

Artikel 14 legt die Meldung in die Verantwortung des Herstellers und gilt seit dem 11. September 2026, auch für Produkte, die bereits auf dem Markt sind. Tools können die Zeit verkürzen zwischen „diese Schwachstelle wird ausgenutzt“ und „wir wissen, welche Produkte und Releases sie enthalten“. Das hängt von Inventaren pro Release ab, denen Sie vertrauen, von kontinuierlicher Überwachung und von einer Verknüpfung jedes ausgelieferten Artefakts mit seinen Komponenten. Anchore und Cybeats beschreiben die Meldefristen in ihren CRA-Materialien, Venvera verfolgt die Fristen, und die Binäranalyse von ONEKEY, Finite State oder Exein deckt Code von Lieferanten ab, den Sie nicht neu bauen können. Die API von CRACI liefert SBOMs, Netzwerk-Traces und Provenienz, und CRACI reicht die Frühwarnung, die Meldung und den Abschlussbericht im Namen des Herstellers ein.

Wo CRACI passt

CRACI ist ein GitHub-Actions-Runner. Für Software, die Sie selbst bauen, zeichnet er auf, was jeder Job geladen hat, einschließlich Paketen aus CI-Caches, und erzeugt eine CycloneDX- oder SPDX-SBOM mit einem Vollständigkeitsstatus pro Job und pro Cache. Er setzt eine Egress-Richtlinie für den Build durch, bewertet die SBOMs des Ausgelieferten laufend neu, unterstützt VEX und exportiert SBOMs als CycloneDX oder SPDX, einschließlich Schwachstellen, für Ihre CRA-Nachweise. Wenn eine aktiv ausgenutzte Schwachstelle gemeldet werden muss, reicht CRACI die CRA-Meldungen in Ihrem Namen ein. Bei Yocto führt er BitBake auf Runnern mit bis zu 32 vCPUs und 96 GB RAM aus und zeichnet auf, was die eigene SPDX-Ausgabe von Yocto auslässt, etwa Host-Pakete und Package-URLs für Rust-Crates. Die Inventaransicht von CRACI zeigt genau, welche Softwareversionen in welchen Produkten im Einsatz sind, weltweit. CRACI automatisiert einen erheblichen Teil der Transparenz und der Nachweise zur Software-Lieferkette, die Unternehmen für ihren umfassenderen CRA-Compliance-Prozess brauchen.

Allein reicht es nicht, wenn der Großteil Ihres Produkts als Binärdateien von Lieferanten kommt oder wenn Sie geführte Prüfungen gegen Standards, die Zuordnung von Kontrollen und Richtlinienmanagement, Schutz auf dem Gerät oder heute schon andere CI-Systeme als GitHub Actions brauchen (GitLab CI und Jenkins sind auf der Roadmap). Für die Builds, die Ihnen gehören, deckt CRACI SBOM, Überwachung und CRA-Meldungen in einem Produkt ab; bei Firmware, die Sie nicht neu bauen können, sieht die Binäranalyse, was Ihr Build nie gesehen hat. Lesen Sie, was der CRA ist, und mehr zu CRA-Compliance und Industrial IoT.

CRA-Compliance-Tools: häufige Fragen

Was CRA-Compliance-Software leistet und was beim Hersteller bleibt

Was ist CRA-Compliance-Software?

Software, die einem Hersteller hilft, den Cyber Resilience Act zu erfüllen. Es gibt sie in zwei Arten: technische Tools, die SBOM, Schwachstellenaufzeichnungen und Build-Nachweise erzeugen, und Compliance-Management-Plattformen, die die Anforderungen auf Kontrollen abbilden und die Meldefristen, die Risikobewertung und die Konformitätsbewertung verfolgen. Keine davon macht ein Produkt für sich allein konform.

Welche CRA-Pflichten kann ein Tool automatisieren?

Vor allem die Seite der Schwachstellenbehandlung: die SBOM erzeugen, sie auf neue Schwachstellen überwachen, betroffene Releases finden, Triage- und VEX-Entscheidungen festhalten, die Meldungen nach Artikel 14 vorbereiten und einreichen und Nachweise für die technische Dokumentation exportieren. Risikobewertung, sicheres Design, Konformitätsbewertung und Konformitätserklärung bleiben Entscheidungen des Herstellers.

Brauche ich ein Tool oder mehrere?

Meist mehr als eines. Ein technisches Tool liefert Ihnen die SBOM und die Schwachstellennachweise; eine Compliance-Management-Plattform oder ein Berater deckt Kontrollen, Richtlinien und den Weg zur Konformität ab. Für Firmware, die Sie von Lieferanten als Binärdateien erhalten, ergänzt die Binäranalyse, was Ihr eigener Build nicht sehen kann.

Welche Fristen gelten für CRA-Meldungen?

Artikel 14 gilt seit dem 11. September 2026: eine Frühwarnung innerhalb von 24 Stunden, nachdem Sie von einer aktiv ausgenutzten Schwachstelle Kenntnis erlangt haben, eine Meldung innerhalb von 72 Stunden und ein Abschlussbericht spätestens 14 Tage, nachdem eine Korrektur oder Abhilfemaßnahme verfügbar ist. Er gilt auch für Produkte, die bereits auf dem Markt sind. Der Rest des CRA gilt ab dem 11. Dezember 2027.

Reicht CRACI CRA-Meldungen ein?

Ja. CRACI reicht die Frühwarnung, die Meldung und den Abschlussbericht im Namen des Herstellers ein. Die Meldepflicht bleibt beim Hersteller.

Führt ein Tool die CRA-Konformitätsbewertung durch?

Kein Software-Tool ersetzt sie. Der Hersteller führt die Bewertung durch, per interner Kontrolle oder, bei wichtigen und kritischen Produkten, mit einer benannten Stelle oder einem Zertifizierungsschema, wo der CRA dies verlangt. Tools liefern die Nachweise, auf die sich die Bewertung stützt.