Firmware-Sicherheit
Embedded-Firmware-Sicherheit für RTOS- und Bare-Metal-Geräte
Embedded-Firmware-Sicherheit heißt zu wissen, welche Komponenten auf einem Mikrocontroller oder RTOS-Gerät laufen, und sie frei von bekannten Schwachstellen zu halten, auch wenn es kein Betriebssystem gibt, das sich untersuchen ließe. KROMSE deckt heute Linux-basierte Firmware ab; Bare-Metal- und RTOS-Images sowie Hardwarekomponenten stehen auf der Roadmap.
Free-Tarif, keine Kreditkarte erforderlich.
Warum RTOS- und Bare-Metal-Firmware schwer zu scannen ist
Linux-basierte Firmware enthält ein Dateisystem mit Paketdatenbanken und separaten Binärdateien, sodass ein Scanner sie entpacken und lesen kann, was darin steckt. Bare-Metal- und RTOS-Firmware ist meist ein einziger statisch gelinkter Blob: Die Anwendung, der RTOS-Kernel (FreeRTOS, Zephyr, ThreadX, NuttX und andere), Netzwerk-Stacks wie lwIP und Kryptobibliotheken wie Mbed TLS oder wolfSSL werden ohne Namen oder Versionsdateien zusammenkompiliert.
Um Komponenten in einem solchen Image zu identifizieren, braucht es Signaturen bekannten Codes oder Build-Metadaten vom Hersteller. Ohne beides kann ein ehrlicher Scanner nur sagen, dass nichts extrahiert werden konnte.
Beim Build ansetzen, nicht beim Binary
Bei Embedded-Produkten stammt die verlässlichste Bestandsaufnahme meist aus dem Build-System, denn der Hersteller hat es, ein Scanner, der nur die Binärdatei sieht, dagegen nicht.
- Zephyr: Das West-Manifest (west.yml) legt Module und ihre Revisionen fest.
- ESP-IDF: idf_component.yml und die Lock-Datei der Abhängigkeiten listen verwaltete Komponenten auf.
- PlatformIO und Arduino: platformio.ini, library.properties und Sketch-Dateien benennen Bibliotheken.
- Conan und vcpkg: Lockfiles halten die Versionen von C- und C++-Paketen fest.
- Yocto und Buildroot: Image- und Lizenzmanifeste listen jedes Paket in einem Linux-Build auf.
Was der Cyber Resilience Act erwartet
Der CRA macht keine Ausnahme für kleine Geräte. Ein Mikrocontroller-Produkt mit Netzwerkverbindung ist ein Produkt mit digitalen Elementen; sein Hersteller braucht eine SBOM, die mindestens die obersten Abhängigkeiten abdeckt, einen Prozess zur Behandlung von Schwachstellen, Sicherheitsaktualisierungen für den Unterstützungszeitraum und die Meldungen nach Artikel 14.
Mehrere Komponententypen stehen in den Listen wichtiger Produkte der Verordnung, etwa Mikroprozessoren und Mikrocontroller mit sicherheitsrelevanten Funktionen in Klasse I sowie manipulationssichere Mikroprozessoren und Mikrocontroller in Klasse II, was eine strengere Konformitätsbewertung nach sich zieht.
Hardwarekomponenten gehören dazu
Schwachstellen werden auch für Hardware veröffentlicht: Prozessoren, Funkchipsätze, Sicherheitselemente. Mit einer Hardware-Stückliste kann ein Hersteller prüfen, welche seiner Produkte ein betroffenes Bauteil verwenden. Die SBOM-Anforderung des CRA betrifft Software, die Behandlung von Schwachstellen erfasst jedoch das gesamte Produkt.
Updates für Geräte im Feld
Eine verwundbare Komponente zu finden, ist nur die halbe Pflicht. Der CRA verlangt, dass Sicherheitsaktualisierungen während des gesamten Unterstützungszeitraums sicher und unverzüglich verteilt werden. Dieser muss mindestens fünf Jahre betragen, es sei denn, das Produkt wird voraussichtlich kürzer genutzt, und jede Aktualisierung muss mindestens zehn Jahre lang oder für den Rest des Unterstützungszeitraums verfügbar bleiben.
Für Mikrocontroller-Produkte heißt das, den Update-Weg schon beim Design zu planen: eine sichere Boot-Kette, signierte Images, genug Flash für ein Fallback-Image und einen Weg, Geräte zu erreichen, die selten verbunden sind. Das nach dem Marktstart nachzurüsten, ist meist unmöglich.
Praktische Schritte jetzt
Solange Tools nicht jedes Image lesen können, tragen die eigenen Aufzeichnungen des Herstellers die Hauptlast.
- Bewahren Sie die Build-Manifeste und Lockfiles jeder veröffentlichten Firmware-Version auf.
- Halten Sie pro Produkt die Versionen von RTOS, Netzwerk-Stack und Kryptobibliothek fest.
- Abonnieren Sie die Sicherheitshinweise jedes RTOS und jeder Bibliothek, die Sie ausliefern.
- Planen Sie, wie Geräte im Feld während des Unterstützungszeitraums Sicherheitsaktualisierungen erhalten.
Heute in KROMSE verfügbar
Was KROMSE heute für Embedded-Produkte abdeckt:
- Linux-basierte Firmware-Images: entpackt, inventarisiert und auf bekannte Schwachstellen geprüft.
- Embedded-Build-Manifeste werden in der Bestandsaufnahme aufgeführt (Zephyr west.yml, ESP-IDF, PlatformIO, Arduino, Conan, vcpkg, CMake, Yocto und Buildroot); die meisten werden noch nicht mit Sicherheitshinweisen abgeglichen.
- Yocto- und Buildroot-Manifeste lassen sich wie eine SBOM hochladen und werden mit OSV.dev abgeglichen.
- Bare-Metal- und RTOS-Images werden als nicht analysierbar gemeldet, nie als unbedenklich.
Als Nächstes geplant
Auf der Roadmap, noch nicht verfügbar. Die Termine sind Zielmarken, keine Zusagen; diese Seite wird an dem Tag aktualisiert, an dem eine Funktion live geht.
- Geplant · Q1 2027Bare-Metal- und RTOS-Firmware. KROMSE wird Komponenten in Firmware ohne Linux-Dateisystem identifizieren, etwa in Bare-Metal- und RTOS-Images auf Basis von FreeRTOS oder Zephyr.
- Geplant · Q1 2027Hardwarekomponenten. KROMSE wird die Hardwarekomponenten Ihres Produkts mit veröffentlichten Sicherheitshinweisen zu Hardware abgleichen.
- Geplant · Q4 2026 (Dezember)Robotik-Sicherheit. KROMSE wird ROS-2-Sicherheitshinweise, die Identifizierung von Komponenten in PX4- und ArduPilot-Firmware sowie robotikspezifische Schwachstellendaten ergänzen.
Häufige Fragen
Kann KROMSE FreeRTOS- oder Zephyr-Firmware scannen?
Als Binär-Image noch nicht. KROMSE führt Zephyr- und andere Embedded-Build-Manifeste in seiner Bestandsaufnahme auf, doch die Identifizierung von Komponenten in Bare-Metal- und RTOS-Images steht auf der Roadmap. Ein Scan eines solchen Images meldet, dass nichts extrahiert werden konnte.
Gilt der CRA für Mikrocontroller-Geräte?
Ja, wenn das Gerät ein Produkt mit digitalen Elementen mit direkter oder indirekter Datenverbindung ist. Die Größe spielt keine Rolle. Mikroprozessoren und Mikrocontroller mit sicherheitsrelevanten Funktionen stehen in Anhang III unter den wichtigen Produkten.
Was ist eine Hardware-Stückliste?
Eine Liste der Hardwarekomponenten eines Produkts, etwa Prozessoren, Funkchipsätze und Sicherheitselemente, mit Teilenummern. Mit ihr findet ein Hersteller schnell heraus, welche Produkte ein Bauteil verwenden, für das eine Schwachstelle veröffentlicht wurde.
Gilt der Unterstützungszeitraum auch für kleine Geräte?
Ja. Jedes Produkt mit digitalen Elementen braucht einen Unterstützungszeitraum, der seiner erwarteten Nutzungsdauer entspricht und mindestens fünf Jahre beträgt, es sei denn, das Produkt wird voraussichtlich kürzer genutzt. Für diesen Zeitraum müssen Sicherheitsaktualisierungen bereitgestellt werden, daher muss der Update-Mechanismus von Anfang an eingeplant sein.
Wie erstelle ich eine SBOM für RTOS-Firmware?
Setzen Sie beim Build-System an: Das West-Manifest von Zephyr, die Lock-Dateien der ESP-IDF-Komponenten, die PlatformIO-Konfiguration oder die Lockfiles von Conan und vcpkg halten fest, was in das Image eingeflossen ist. Wandeln Sie sie in CycloneDX oder SPDX um und bewahren Sie pro Release eine SBOM auf.