Firmware Security Platform
LegacyMind analysiert Firmware auf Binärebene, erstellt SBOMs, erkennt Schwachstellen, Credentials und Härtungslücken und gleicht analysierte Stände täglich gegen neue CVEs ab. Ohne Quellcode. Ohne Agenten auf dem Zielgerät. Mit klarer Priorisierung für Security, OT-Betrieb und Compliance.
0000 27 05 19 56 74 8b 37 b20008 69 bd 1e 3b 00 21 5c 890010 80 00 00 00 80 00 00 000018 13 1d 2c f1 05 05 02 030020 4d 49 50 53 20 4f 70 650028 6e 57 72 74 20 4c 69 6e0030 75 78 2d 35 2e 31 35 2e0038 31 39 37 00 00 00 00 00
uImage-Header · 64 Bytes vollständig
0000 27 05 19 56 74 8b 37 b2 69 bd 1e 3b 00 21 5c 89 |'..Vt.7.i..;.!\.|0010 80 00 00 00 80 00 00 00 13 1d 2c f1 05 05 02 03 |..........,.....|0020 4d 49 50 53 20 4f 70 65 6e 57 72 74 20 4c 69 6e |MIPS OpenWrt Lin|0030 75 78 2d 35 2e 31 35 2e 31 39 37 00 00 00 00 00 |ux-5.15.197.....|
uImage-Header · 64 Bytes vollständig
Daraus gelesen
Aus dem ausgelieferten Image gelesen. Kein Quellcode, kein Zugriff auf das Gerät.
SBOM, CVE-Priorisierung, Monitoring, und je Punkt eine Feststellung zu CRA Anhang I und § 30 BSIG.
Cyber Resilience Act
Ihr Build sagt, was in das Gerät gehen sollte. Das ausgelieferte Image sagt, was drin ist. Zwischen beiden liegen die Bibliotheken Ihrer Zulieferer, und die stehen in keiner Stückliste, die Sie selbst geschrieben haben.
CRA-Readiness-Check, kostenfreiEin ausgeliefertes Image, ein prüffähiger Befundbericht. Ohne Quellcode und ohne Zugriff auf das Gerät.
Eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen. Die Frist läuft gegen das Gerät im Feld, nicht gegen Ihren Entwicklungsstand.
Komponenten und Schwachstellen des Produkts identifizieren und dokumentieren, einschließlich einer Software-Stückliste. Nicht je Produktlinie, sondern für den Stand, den der Kunde bekommt.
Quelle: Verordnung (EU) 2024/2847
Aus dem ausgelieferten Image
Jede gefundene Komponente mit Name, Version und der Stelle im Image, an der sie steht. Export als CycloneDX 1.6.
Was sich nicht lesen ließ, steht mit Grund daneben. Eine Version ohne Beleg bleibt leer.
119 von 119 Paketen erkannt, Version exakt · 3 mit geprüftem Befund · 1 mit aktiv ausgenutzten Schwachstellen (KEV)
Beschreibung
Linux-Kernel: Speicherverwaltung, Prozess-Scheduling, Netzwerk, Gerätetreiber und Systemaufrufe
Sicherheitskontext
3 Schwachstellen werden laut CISA-KEV-Katalog aktiv ausgenutzt, jede in Code, der in diesem Image gebaut ist. CVE-2024-36971: Im Linux-Kernel hält die Funktion __dst_negative_advice() die RCU-Regeln beim Leeren des Routen-Caches eines Sockets nicht ein, was zu einem Use-after-free führen kann. CVE-2025-38352: Im Linux-Kernel besteht eine Race Condition zwischen handle_posix_cpu_timers() und posix_cpu_timer_del(), wenn ein beendeter Prozess bereits abgeräumt wird, während sein CPU-Timer noch verarbeitet wird. CVE-2024-50302: Im Linux-Kernel wird der Berichtspuffer des HID-Kerns nicht mit Nullen initialisiert, sodass ein präparierter HID-Bericht Kernelspeicher preisgeben kann.
Schwachstellen
davon 3 aktiv ausgenutzt (CISA KEV)
Im Tab „Schwachstellen“ anzeigen33 von 119 Komponenten gezeigt, sortiert nach Befunden. 116 ohne geprüften Befund in diesem Auszug.
SBOM exportieren
Erkanntes Komponenteninventar in Standardformaten
Der Bericht
Der technische Befundbericht nennt das Image mit SHA-256, den Zeitpunkt und den Prüfumfang, bevor der erste Befund steht. Vier Stellen daraus, so gezeichnet, wie sie im Bericht stehen.
Vier Zeilen, bevor die Freigabe kommt. Aus einem fehlenden Befund wird nie eine Entwarnung.
Rohbestand aus dem Abgleich von Komponente und Version
Schwelle: CVSS-Schweregrad kritisch oder hoch
Signal: im KEV-Katalog der CISA geführt
Linear gezeichnet: 18 von 5.234 ist ein Strich. Dasselbe Image bei gleichem Katalogstand ergibt dieselbe Liste.
Steuerung, FW30 v04.08.09, Stand 30.08.2026. CVE-Zuordnungen aus erkannter Komponente und Version. Kein Nachweis, dass die Schwachstelle auf dem Gerät erreichbar ist.
| Binärdatei | RELRO | Canary | NX | PIE |
|---|---|---|---|---|
| nicht gestrippt | ||||
| gestrippt |
Vier Prüfungen je ausführbarer Datei, im Bericht mit der Zahl der geprüften Binärdateien. Auf gestrippten Dateien ist der Canary nicht bestimmbar und zählt als fehlend. Die Abdeckungserklärung sagt das.
Der Abgleich hinter dem Katalog läuft gegen 18 Quellen. Der Bericht nennt die CVE-Menge eine versionsbasierte Indikation, weil Hersteller-Backports nicht öffentlich prüfbar sind.
Daten der GitHub Advisory Database und von OSV unter CC BY 4.0.
Industrien
Ob Sie Kundenflotten betreuen, kritische Anlagen absichern oder vernetzte Geräte entwickeln: der Bericht ist derselbe, die erste Frage an ihn ist eine andere.
01
Alle Kundengeräte in einer Liste, oben das mit den meisten aktiv ausgenutzten Lücken. Je Gerät zwei PDF-Berichte, die Sie weitergeben.
Die erste Frage
Kann ich das je Kunde abgeben, ohne es je Kunde zu erklären?
Ja. Je Analyse zwei PDF-Berichte, die Management-Zusammenfassung und der technische Befundbericht, dazu die Flottenansicht über alle Geräte. Beide nennen Prüfumfang und Grenzen auf der ersten Seite, damit Ihr Kunde dafür nicht bei Ihnen anrufen muss.
02
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.
Die erste Frage
Reicht das als Nachweis nach § 30 BSIG?
Der Bericht ist die technische Evidenz zu Ihrem Nachweis: Mängelliste und Maßnahmenplan, gegliedert für die Nachweisführung nach § 39 BSIG, jeder Befund mit Komponente und Version. Ob der Nachweis genügt, entscheidet die Stelle, die ihn prüft. Wir stempeln nichts.
03
Die Stückliste aus dem Image, das Sie ausliefern. Härtung je Binärdatei vor dem Release, und die Schwachstellen in den Bibliotheken Ihrer Zulieferer.
Die erste Frage
Woher wissen Sie, dass die Lücke auf unserem Gerät erreichbar ist?
Das zeigt eine statische Analyse nicht, und wir behaupten es nicht. Jede Zuordnung nennt Komponente, Version und Quelle. Ob der Code im Gerät erreichbar ist, beantwortet Ihr Build, und dafür bekommen Sie die Liste zum Abarbeiten.
| Kennzahl | FW28 v04.06.01 | FW30 v04.08.09 |
|---|---|---|
| Komponenten | 434 | 467 |
| Aktiv ausgenutzt (KEV) | 25 | 18 |
| Kritisch | 109 | 99 |
| CVE-Zuordnungen | 8.332 | 5.234 |
CVE-Zuordnungen aus erkannter Komponente und Version. Kein Nachweis, dass die Schwachstelle auf dem Gerät erreichbar ist. Stand 30.08.2026.
Compliance
Kein Fragebogen. Grundlage ist das ausgelieferte Image, und zwei Läufe über dasselbe Image ergeben dieselben Zeilen. Jeden Befund ordnet die Analyse den 32 Punkten aus CRA Anhang I und § 30 BSIG zu, mit derselben Evidenz. Eine Feststellung hat fünf Formen: Befund, geprüft ohne Befund, nicht geprüft mit Grund, Beobachtung, aus dem Image nicht bestimmbar.
Der Compliance-Tab zählt Feststellungen. Eine Zeile liest sich so: sechs Befunde in zehn geprüften Punkten. Eine Prozentzahl müsste einen nicht geprüften Punkt mit halben Punkten bezahlen. Deshalb druckt der Tab Zähler und kein Konformitätsurteil.
Was das Verfahren nicht prüfen kann, steht so im Bericht: Prozesse, Schulungen, Meldewege sind aus einem Firmware-Image nicht bestimmbar. Ein Punkt, der am Image nicht messbar ist, wird nie grün.
Alle Punkte im Detail11.09.2026 · 11.12.2027
CRA Anhang I
Verordnung (EU) 2024/2847: Meldepflichten ab September 2026, volle Herstellerpflichten ab Dezember 2027. Aus dem Image beantwortet die Analyse 5 Anforderungen und zählt 1 aus; 16 führt der Bericht mit Nummer, zugeordnet zur Herstellerdokumentation.
06.12.2025
§ 30 BSIG
Risikomanagementmaßnahmen nach § 30 Abs. 2 Satz 2 BSIG. Aus dem Image beantwortet die Analyse 2 Nummern und zählt 1 aus; 7 führt der Bericht mit Nummer als Maßnahmen der Einrichtung. Im Betreiberbericht gegliedert für die Nachweisführung nach § 39 BSIG.
Fragen
Laufzeit- und Penetrationsanalyse, Quellcode-Audit, Hardware- und Seitenkanalanalyse, organisatorische Prozesse. Ob ein Dienst im Netz erreichbar ist, misst die Analyse nicht. Das steht auf der ersten Seite jedes Berichts unter Nicht im Geltungsbereich, damit ein Prüfer die Grenze kennt, bevor er den ersten Befund liest.
Firmware-Images mit Linux, Bare-Metal-Builds für Mikrocontroller (ELF und AXF, etwa aus Keil, IAR oder GNU Arm) und SBOMs Ihrer Zulieferer in CycloneDX oder SPDX. Linux-Images auch als Archive und Dateisystem-Extrakte gängiger Distributionen wie OpenWrt, DD-WRT oder Buildroot. Die Liste je Dateiendung steht unter „Unterstützte Formate“ (/formate). Die Extraktion direkt vom Gerät über den Extractor ist in geschlossener Beta.
Aus 18 öffentlichen Quellen: den Trackern von Debian, Ubuntu, Red Hat und Alpine, den CSAF-Meldungen von BSI, Siemens ProductCERT, CERT@VDE, CISA, SICK, KUNBUS und Red Hat, den Kernel-Meldungen von kernel.org, GHSA, OSV und der NVD, dazu CISA KEV und die EUVD der ENISA. Was eine Distribution schon gepatcht hat, melden wir nicht als offen. Daten der GitHub Advisory Database und von OSV unter CC BY 4.0.
Den Anforderungen aus Anhang I der Verordnung (EU) 2024/2847 (CRA) und den Risikomanagementmaßnahmen nach § 30 Abs. 2 Satz 2 BSIG. Zu jedem Punkt steht eine Feststellung in einer von fünf Formen: Befund, geprüft ohne Befund, nicht geprüft (mit Grund), Beobachtung, aus dem Image nicht bestimmbar. Kein Prozentwert, kein Konformitätsurteil.
Alle Daten werden auf europäischer Infrastruktur verarbeitet und gespeichert. Die Firmware-Datei wird nach Abschluss der Analyse gelöscht, die Originaldatei bleibt nicht im System. In Ihrem Account bleiben die Ergebnisse: Komponenten, Schwachstellen, Risikobewertung. Aufbewahrungsfristen lassen sich je Account einstellen.
Ja. Berichte als PDF, die SBOM als CycloneDX-Export für Supply-Chain-Werkzeuge, und der Firmware Extractor für die Extraktion über SSH (geschlossene Beta). Ein API-Zugang für die CI/CD-Integration steht auf der Roadmap.
Rückblick: unser Vortrag auf der MyWay 2026 in BerlinNächster Schritt
Der CRA-Readiness-Check ist kostenfrei. Sie stellen ein Firmware-Image bereit, wir analysieren es mit dem Verfahren auf dieser Seite. Sie erhalten zwei PDF-Berichte, die Management-Zusammenfassung und den technischen Befundbericht, und wir gehen ihn mit Ihnen durch: Komponenten, CVEs je Komponente mit KEV-Kennzeichnung, Anmeldedaten und Schlüssel, Härtung, Erklärung zum Prüfumfang.
Kein Quellcode, kein Zugriff auf das Gerät. Die Datei wird nach der Analyse gelöscht, die Ergebnisse bleiben in Ihrem Account.