Kostenloser CRA Readiness Check

Wo steht Ihr Produkt beim CRA? In 24 Stunden wissen Sie es.

Sie bekommen einen klaren Report: Ampel-Status zur CRA-Bereitschaft, die vollständige Liste Ihrer Software-Komponenten und bekannte Sicherheitslücken mit Schweregrad, dazu eine Lizenzprüfung. Kostenlos, einmal pro Firma (erneuter Report nach Behebung: 99 €). Meldefähig heute, nachweisfähig bis Dezember 2027 — aus demselben Datenbestand.

Sie haben schon eine Stückliste?

Ob Sie sie selbst mit Syft, cdxgen oder Trivy erzeugt haben, aus Ihrem Build exportieren oder von einem Zulieferer bekommen haben — als CycloneDX oder SPDX: Senden Sie die Datei an [email protected]. Kein Werkzeug, keine Installation, kein Zugriff auf Ihren Quellcode.

Sie bekommen den kostenlosen CRA-Bericht — und Ihre Datei zurück, in der wir Lieferant und Lizenz ergänzt haben, aus einer Datenbank mit rund 51.000 Komponenten.

Ein Beispiel zum Nachrechnen. Syfts Stückliste für den Webserver caddy enthält 265 Einträge: 10 Dateieinträge, 34 CI-Werkzeuge und 221 Go-Module. Um die 221 geht es. Ein Lieferant stand bei keinem davon. Nach dem Abgleich mit unserer Datenbank steht er bei allen 221. Namen und Versionen kamen aus Syfts Datei — ergänzt haben wir die Felder, nach denen ein Prüfer fragt.

Was wir nicht füllen konnten, nennt der Bericht. Ob eine Komponente ganz fehlt, sieht er nicht — dafür muss das Werkzeug Ihren Build selbst lesen.

Wir werten Ihre Datei aus, senden Ihnen die ergänzte Fassung zurück und löschen unsere Kopie danach. Näheres in den Datenschutzhinweisen.

Ihr Projekt liegt als Quellcode vor?

Der Generator ist frei. Quelloffen unter GPL, also frei und bleibt es. Kein Code, kein Konto, keine Gegenleistung.

pipx install jochwacht-sbom
jochwacht-sbom .

Das Werkzeug liest Ihren Build und legt Ihre SBOM, also die Stückliste Ihrer Software, als Datei in Ihrem Projektordner ab. Sie gehört Ihnen. Dabei können Sie es belassen.

Wollen Sie den kostenlosen CRA-Bericht dazu, senden Sie die Datei mit --send --email <Ihre Adresse> — oder als Anhang an [email protected]. Er kommt binnen 24 Stunden.

Das Senden ist freiwillig und unser Nutzen an der Sache. So kommen wir mit Ihnen ins Gespräch. Vor dem Senden zeigt Ihnen das Werkzeug die vollständige Liste und fragt nach.

Frühere Paketnamen funktionieren weiter und installieren die aktuelle Fassung. Fehlt Ihnen pipx: sudo apt install pipx. Mit pip geht es ebenso, dann aber in einer virtuellen Umgebung — seit Ubuntu 24.04 und Debian 12 lehnt das System-Python die direkte Installation ab.

So sieht die Sektion aus, die im Report vor den Funden steht. Sie beantwortet die Frage, an der die 24-Stunden-Frist hängt.

Aktive Ausnutzung

Geprüft: 47 Komponenten, 25 Funde
Quelle 1: CISA KEV, abgerufen beim Erstellen des Berichts
Quelle 2: EUVD (europäische Liste), abgerufen beim Erstellen des Berichts

Ergebnis: Keiner der 25 Funde ist in einer der beiden Listen verzeichnet.

„Funde" sind CVE-Einträge zu den Komponenten Ihrer Stückliste.
Ein gelisteter Fund heißt: Für diese Lücke ist aktive Ausnutzung belegt.
Die Meldepflicht nach CRA Art. 14 setzt zusätzlich voraus, dass die Lücke in
Ihrem Produkt enthalten ist — das beurteilen Sie. Er steht deshalb zuoberst,
unabhängig von seiner CVSS-Einstufung.

Meistens lautet die Antwort nein. Dann steht das da, mit beiden Quellen und dem Zeitpunkt der Abfrage. Ein Bericht ohne diese Sektion ist kein Nachweis.

  • Seit dem 11. September gilt: gemeldet werden muss, was aktiv ausgenutzt wird — nicht, was schwerwiegend ist. Ihr Report prüft das gegen die zwei Listen oben und nennt dazu die EPSS-Wahrscheinlichkeit.
  • Auch was im FPGA steckt. Vivado, Libero SoC und Quartus Prime werden gelesen; die fremden IP-Cores stehen mit Name und Version im Report.
  • Auch die Lizenzlage. Copyleft-Pflichten wertet der Report entlang der gesamten Abhängigkeitskette aus, nicht nur bei den direkt eingebundenen Paketen.
  • Keine falschen Alarme. Geprüft wird die Version, die wirklich in Ihrem Build steckt. Ergibt Ihre Baukonfiguration OpenSSL 3.0.13, prüfen wir genau 3.0.13 — nicht jede Lücke, die je für irgendeine 3.0er-Version gemeldet wurde.

Optional: Ihr persönlicher Code

Zum Senden brauchen Sie keinen Code, Ihre E-Mail-Adresse genügt. Wer einen hat, spart sich die Eingabe: Der Report geht dann automatisch an die hier registrierte Adresse. Der Code kommt per E-Mail und gilt für einen Check.

Wir verwenden Ihre Angaben, um Ihnen Code und Report zuzustellen und Sie zu unserem Angebot zu kontaktieren. Details: Datenschutzhinweise zum Check.

Häufige Fragen

Was genau verlässt unser Haus?

Von den gefundenen Komponenten nur Namen, Versionen und Paket-Ökosysteme — kein Quellcode, keine Dateipfade, keine Konfiguration. Dazu die Angaben, die Sie in Ihrer Ihrer Deklarationsdatei selbst deklariert haben (Lieferant, Lizenz, Kennungen) — das ist Ihre eigene Aufstellung, und sie macht den Bericht deutlich vollständiger; abschaltbar mit --no-declared-metadata. Sie müssen dafür nichts glauben: Die SBOM liegt als Datei in Ihrem Projektordner, bevor Sie über das Senden entscheiden. Auf Wunsch anonymisiert --anonymize sogar den Projektnamen. Damit Sie das nicht glauben müssen, sondern prüfen können, ist der Generator quelloffen unter GPL: github.com/Innomatica-GmbH/jochwacht-sbom.

Was kostet der Check?

Der Erst-Check ist kostenlos — einmal pro Firma. Ein Nachweis nach Behebung kostet 99 € netto gegen Rechnung. Für laufende Überwachung ist Jochwacht Monitor in Vorbereitung. Alle Preise stehen auf der Preisseite.

Welche Projekte werden unterstützt?

Alles mit Paketmanager- oder Build-Dateien: Conan, vcpkg, CMake, Cargo, npm/yarn/pnpm, Python, Go, Maven/Gradle, Yocto/Buildroot-Umgebungen u. v. m. Dazu FPGA-Projekte aus Vivado, Libero SoC und Quartus Prime. Reine Make-Projekte ohne solche Dateien können Komponenten manuell deklarieren — der Report weist das sauber aus.

Wer erstellt den Report?

Die Analyse läuft auf unseren eigenen Servern in Deutschland; jeder Report wird von unserem Team persönlich geprüft, bevor er rausgeht. Kein Callcenter, kein Datenverkauf — wir sind ein deutsches Embedded-Software-Haus.