Industrien

Drei Teams, ein Bericht, derselbe Beweis

Wer Geräte verwaltet, betreibt oder herstellt, stellt der Firmware eine andere erste Frage. Die Analyse darunter ist dieselbe.

Der Beweis zuerst

Ein Firmware-Update, am ausgelieferten Binary nachgezählt

Eine Steuerung, zwei ausgelieferte Stände. FW28 v04.06.01 und FW30 v04.08.09 sind beide öffentlich, beide mit dem Produkt aus dem Image analysiert. Der neuere Stand trägt 7 KEV-Einträge und 10 kritische Zuordnungen weniger, dazu 33 Komponenten mehr. Die Ergebnisse gehören zu keinem Kunden.

KEV-Einträge, exakte Zählung

25
nach
18
−7

FW28 v04.06.01 nach FW30 v04.08.09, dieselbe Steuerung

CISA-Katalog aktiv ausgenutzter Schwachstellen. 18 Einträge stehen nach dem Update noch auf der Liste.

Komponenten

434
nach
467
+33

kritische Zuordnungen

109
nach
99
−10

CVE-Zuordnungen

8.332
nach
5.234
−3.098

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.

Öffentlich verfügbare Firmware, mit dem Produkt analysiert. Keine Kundendaten. Produktionsdatenbank, Stand 09.09.2026.

Drei erste Fragen

Derselbe Bericht, drei Einstiege

Ein Hersteller fragt, was zwischen zwei Releases passiert. Ein Betreiber fragt, welche Steuerung zuerst dran ist. Ein Dienstleister fragt, wie er das seinen Kunden liefert. Die Zahlen oben beantworten alle drei, nur beginnt jeder an einer anderen Stelle des Berichts.

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. Hersteller- und branchenunabhängig. Analyse auf EU-Servern, Firmware wird nach der Analyse gelöscht. Alle Formate

  1. 01

    Managed Service Provider

    Welches Kundengerät ist heute zuerst dran?

    Alle Kundengeräte in einer Liste, oben das mit den meisten aktiv ausgenutzten Lücken. Je Gerät ein Bericht mit Risikoscore, Komponentenliste und Compliance-Einordnung, den Sie weitergeben, ohne dass jemand die Zahlen von Hand erhebt.

    Im Bericht zuerst
    Flotten-Übersicht, dann der Bericht je Gerät
    Typisch
    Systemintegratoren, IT-Dienstleister, MSSPs
    Zur Seite
  2. 02

    KRITIS-Betreiber

    Welche aktiv ausgenutzte Lücke steht noch auf der Steuerung?

    Geräte-Evidenz für den Nachweis nach BSIG: Risikobewertung pro Gerät, Feststellungen zu CRA Anhang I und § 30 BSIG, laufende Prüfung gegen KEV und EUVD mit Alarm, wenn sich die Lage für ein Gerät ändert.

    Im Bericht zuerst
    KEV-Einträge, dann die Compliance-Einordnung
    Typisch
    Energie, Wasser, Fertigung, Gesundheitswesen, Transport
    Zur Seite
  3. 03

    Gerätehersteller

    Was hat das Update im ausgelieferten Binary verändert?

    SBOM als CycloneDX aus dem Firmware-Image, ohne Quellcode-Zugang. Binary Hardening je Executable, Zulieferer-Schwachstellen vor Release. Der Vergleich zweier Stände, wie oben an der Steuerung, für die eigene Firmware.

    Im Bericht zuerst
    Release gegen Release, dann die SBOM
    Typisch
    OEMs, Embedded-Hersteller, IoT-Gerätebauer
    Zur Seite

Ihre Branche ist nicht dabei?

LegacyMind 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. Hersteller- und branchenunabhängig. Sprechen Sie mit uns über Ihren konkreten Einsatzbereich.

Kontakt aufnehmenPlattform ansehen