CRA-Meldepflichten seit 11.09.2026
Firmware-Sicherheit für Gerätehersteller
Die 24-Stunden-Meldepflicht gilt. LegacyMind liefert SBOM, Schwachstellen-Analyse und Härtungs-Check aus dem Firmware-Binary, ohne Quellcode-Zugang.
Release gegen Release
Was ein Update im ausgelieferten Binary verändert, in vier Zahlen
Eine Steuerung, FW28 v04.06.01 gegen FW30 v04.08.09. Beide Stände öffentlich, beide aus dem Image analysiert, kein Kunde beteiligt. So sieht der Vergleich aus, wenn Sie ihn vor dem Release für Ihre eigene Firmware ziehen.
Komponenten, exakte ZählungKomponenten in der SBOM, exakte Zählung
KEV-Einträge
kritische Zuordnungen
CVE-Zuordnungen
CVE-Zuordnungen aus erkannter Komponente und Version. Kein Nachweis, dass die Schwachstelle auf dem Gerät erreichbar ist. version_match steht auf 99,1 % (FW28) und 98,5 % (FW30) der Zuordnungen auf assumed. KEV-Einträge und Komponenten sind exakte Zählungen.
Der Umfang ist gewachsen
33 Komponenten kommen dazu, 434 werden 467. Das Update liefert mehr Software aus, und jede neue Komponente steht ab jetzt in der SBOM, die der Kunde erwartet.
Die Zuordnungen fallen trotzdem
Mehr Komponenten und 3.098 Zuordnungen weniger: die Differenz sitzt in den Versionen. Was die Release-Notes als Bibliotheks-Update nennen, wird hier zur zählbaren Differenz, mit dem Vermerk assumed auf beiden Seiten.
Die harte Zahl sind die KEV-Einträge
25 werden 18. Das sind 7 Einträge aus dem CISA-Katalog aktiv ausgenutzter Schwachstellen, die auf FW30 nicht mehr zugeordnet sind, und 18, die es weiterhin sind. Genau diese 18 sind die, nach denen ein Kunde unter der CRA-Meldepflicht zuerst fragt.
Was Entwicklungsleiter zuerst fragen
Drei Fragen, die in jedem ersten Gespräch fallen
- Woher kommen 8.332 Zuordnungen, wenn das Gerät 434 Komponenten hat?
- Aus der Paarung von erkannter Komponente und Version mit 18 Schwachstellenquellen, von den Distributions-Trackern über die CSAF-Feeds der Hersteller bis zur NVD. Eine Komponente mit alter Version zieht viele Einträge. Auf 99,1 % dieser Zeilen steht version_match auf assumed: die Version wurde erkannt, die Erreichbarkeit der Lücke auf dem Gerät nicht geprüft. Deshalb trägt die Zahl den Vermerk, und deshalb beginnt der Bericht mit den 25 KEV-Einträgen, nicht mit den 8.332.
- Brauchen Sie unseren Quellcode oder unser Build-System?
- Nein. Die Analyse läuft auf dem ausgelieferten Firmware-Image, so wie es der Kunde bekommt. Das Image wird entpackt, die Paketdatenbanken und Manifeste werden gelesen, jede ELF-Datei wird auf ihre Schutzmechanismen geprüft. Für die beiden Stände oben waren das die öffentlich verfügbaren Downloads.
- Was steht nicht in der Komponentenliste?
- Statisch gelinkte Bibliotheken und Kernelmodule, die in keiner Paketdatenbank und keinem Manifest auftauchen. Der Bericht nennt diese Grenze in einem eigenen Abschnitt, mit den untersuchten Wurzelverzeichnissen und den Prüfungen, die nicht liefen.
Die Herausforderung
Produkt-Security unter regulatorischem Druck
- 01
Die CRA-Fristen laufen
Seit 11. September 2026 gilt die 24-Stunden-Meldepflicht für aktiv ausgenutzte Schwachstellen. Ab Dezember 2027 folgen die vollständigen Herstellerpflichten. Eine belastbare SBOM ist die Grundlage für beides.
- 02
Zulieferer-Risiken unsichtbar
Third-Party-Bibliotheken und Zulieferer-Firmware enthalten oft bekannte Schwachstellen. Ohne Analyse wissen Sie das erst nach einem Vorfall.
- 03
Härtung vor Release nicht verifiziert
Fehlen Stack Canaries? Sind Private Keys exponiert? Ohne systematischen Check geht eine neue Firmware nur größer raus, nicht sicherer.
Die Lösung
Was Sie vor dem Release in der Hand haben
SBOM-Generierung für EU CRA
CycloneDX-konformes Software Bill of Materials, automatisch aus Binär-Firmware generiert, ohne Quellcode-Zugang.
Firmware-Härtung vor Release
Binary Hardening Score zeigt fehlende RELRO, NX, PIE und Stack Canaries. Verifizieren Sie jede Firmware-Version vor dem Release.
Zwei Stände nebeneinander
Risikoscore und Härtungsgrad je Firmware-Version. Zwei ausgelieferte Stände nebeneinander zeigen, was ein Release wirklich geschlossen hat.
Zulieferer-Schwachstellen erkennen
Identifizieren Sie bekannte CVEs in Third-Party-Komponenten und Zulieferer-Bibliotheken, bevor Ihr Kunde sie findet.
Aus dem Produkt
SBOM und Härtung auf einen Blick
Jede aus den Paketdatenbanken und den Manifesten der Sprach-Ökosysteme erkannte Komponente wird mit Name und Version geführt und gegen bekannte Schwachstellen abgeglichen. Statisch gelinkte Bibliotheken und Kernelmodule sind darin nicht enthalten. Der Härtungsbefund zeigt je Binärdatei, welcher Schutzmechanismus fehlt.
- CycloneDX-Export, maschinenlesbar
- Feststellungen zu CRA Anhang I, je Anforderung mit Grundlage
- Krypto-Inventar mit BSI TR-02102-1 Bewertung
- Härtungsbefund je Binärdatei
- Schwachstellen in Third-Party-Bibliotheken
Komponenten
128 versionierte Komponenten erkannt · 9 mit bekannten Schwachstellen · 1 mit aktiv ausgenutzten (KEV)
- 1mit KEV
- 2Kritisch
- 4Hoch
- 2Mittel
- 0Niedrig
- 119ohne Befund
Beschreibung
Linux-Kernel: Speicherverwaltung, Prozess-Scheduling, Netzwerk, Gerätetreiber und Systemaufrufe
Sicherheitskontext
Der Linux-Kernel ist die kritischste Angriffsfläche dieser Firmware. 6 Schwachstellen werden aktiv ausgenutzt (CISA KEV), darunter Dirty Pipe (CVE-2022-0847) und Sequoia (CVE-2021-33909). Lokale Rechteausweitung zu Root.
Schwachstellen
- 45 CVEs
- 3Kritisch
- 12Hoch
- 22Mittel
- 8Niedrig
davon 6 aktiv ausgenutzt (CISA KEV)
Im Tab „Schwachstellen“ anzeigen- Version
- 5.4.238
- Empfohlen ab
- 5.4.269
- Hersteller
- The Linux FoundationAdvisory
- Lizenz
- GPL-2.0
- Package URL
- pkg:
generic/ linux-kernel@5.4.238 - CPE
- cpe:
2.3: o: linux: linux_kernel: 5.4.238: *: *: *: *: *: *: *
35 von 128 Komponenten gezeigt, sortiert nach Schwachstellen. 119 ohne Treffer im Abgleich.
SBOM exportieren
Erkanntes Komponenteninventar in Standardformaten
Weitere Anwendungsfälle
LegacyMind für andere Teams
Für Managed Service Provider
Alle Kundengeräte in einer Liste, oben das mit den meisten aktiv ausgenutzten Lücken. Je Gerät zwei PDF-Berichte, die Sie weitergeben.
Mehr erfahrenFür KRITIS Betreiber
Je Gerät die Mängelliste und den Maßnahmenplan für die Nachweisführung nach § 39 BSIG, jeder Befund mit Komponente und Version. Alarm, wenn eine Ihrer Komponenten neu im KEV-Katalog steht.
Mehr erfahrenIndustrien
Prüfen Sie es an Ihrer eigenen Firmware
Für OEMs, Embedded-Systems-Hersteller, IoT-Gerätebauer und alle, die vernetzte Produkte ausliefern. Analyse auf EU-Servern, ohne Quellcode-Zugang, Firmware wird nach der Analyse gelöscht.