Einleitung: Zwischen Funktionalität und Sicherheitsrisiko
Vernetzte Geräte sind längst Teil unseres Alltags und bilden das Rückgrat industrieller Systeme, von der Automobiltechnik über Medizingeräte bis hin zur Gebäudesteuerung. Was diese Geräte antreibt, bleibt jedoch oft im Verborgenen: Embedded Firmware – spezifisch programmierte Software, die direkt auf der Hardware ausgeführt wird. Sie sorgt für zentrale Funktionen, wird aber häufig als gegeben hingenommen, statt als sicherheitsrelevanter Risikofaktor betrachtet zu werden.
Embedded Software findet sich in nahezu allen modernen elektronischen Geräten: In Steuergeräten von Fahrzeugen (ECUs), in Routern und WLAN-Repeatern, in Smartwatches und Fitness-Trackern, in medizinischen Implantaten wie Insulinpumpen oder Herzschrittmachern, in Produktionsrobotern, Geldautomaten, vernetzten Haushaltsgeräten (Stichwort „Smart Home“) und selbst in Spielzeugen. Trotz dieser breiten Verbreitung wird der Softwareunterbau dieser Systeme häufig unterschätzt – insbesondere in Bezug auf Wartbarkeit, Herkunft der Softwarekomponenten und Sicherheitsrisiken.
Was wissen wir eigentlich über die Software in unseren Geräten – und was bedeutet es, es nicht zu wissen?
Was ist Embedded Software – und warum ist sie so kritisch?
Embedded Software ist spezialisierte, oft hardwareabhängige Software, die in elektronische Systeme integriert ist, um spezifische Aufgaben zu erfüllen. Anders als allgemeine Betriebssysteme oder Desktop-Software ist sie meist auf minimale Ressourcen ausgelegt und tief mit der zugrundeliegenden Hardware verwoben.
Typische Merkmale:
- Direkte Kontrolle über Sensorik, Aktorik oder Kommunikation
- Häufig keine oder nur eingeschränkte Updatefähigkeit
- Entwicklung über Jahre hinweg, oft mit langem Produktlebenszyklus
Genau diese Charakteristika machen Embedded Software so anfällig: Sie wird selten vollständig dokumentiert, ist schwer zu auditieren und vereint Module verschiedenster Herkunft – von proprietären Libraries über Open Source bis hin zu automatisch generiertem Code. Hinzu kommt die technische Heterogenität: Embedded Software wird in einer Vielzahl unterschiedlicher Programmiersprachen geschrieben – klassisch etwa in C oder C++, zunehmend aber auch unter Einsatz von Python, Rust oder modellbasierter Entwicklungswerkzeuge wie MATLAB/Simulink. Selbst Low-Code- oder KI-generierte Module halten Einzug.
Die Vielfalt an Sprachen geht häufig mit unterschiedlichen Programmierparadigmen, Entwicklungsphilosophien und Qualitätsstandards einher. Dadurch entstehen Schnittstellenprobleme und Kompatibilitätsrisiken, insbesondere wenn Softwaremodule von unterschiedlichen Teams oder externen Zulieferern stammen. Die Nachvollziehbarkeit leidet – ebenso wie die Fähigkeit, im Ernstfall schnell und präzise auf Sicherheitsvorfälle zu reagieren.
Entstehung unter Komplexitätsdruck: Ein Produkt vieler Hände
Die Entwicklung moderner Embedded Firmware erfolgt selten aus einer Hand. Vielmehr ist sie das Resultat eines arbeitsteiligen Prozesses, der sich über mehrere Teams, Organisationen und häufig auch Länder erstreckt. In global verteilten Projekten wirken unterschiedlichste Akteure mit – interne Entwicklerteams, externe Dienstleister, Open-Source-Communities, Zulieferer und zunehmend auch KI-gestützte Programmierwerkzeuge. Das Ergebnis ist ein komplexes Softwaremosaik, das zwar funktional sein mag, in seiner Gesamtheit jedoch selten vollständig verstanden oder zentral dokumentiert ist.
Diese verteilte Entwicklung bringt eine zusätzliche, oft unterschätzte Komplexitätsebene mit sich: kulturelle Unterschiede in der Arbeitsweise und im Umgang mit Qualität und Sicherheit. Während in einigen Regionen und Unternehmen Sicherheit und Dokumentation hohe Priorität genießen, dominieren andernorts Pragmatismus und Zeitdruck. Dies führt zu Inkonsistenzen bei Coding-Standards, Testabdeckung und Updatefähigkeit.
Auch die Verfahren zur Absicherung und Freigabe – etwa Security-Assessments, funktionale Sicherheitsbewertungen oder Homologationen – unterliegen internationalen Unterschieden. Sie variieren nicht nur in Bezug auf gesetzliche Anforderungen, sondern auch hinsichtlich Mentalität und Prüftiefe. Während beispielsweise in sicherheitskritischen Branchen wie der Medizintechnik oder der Luftfahrt umfangreiche Prüfprozesse etabliert sind, genügt in anderen Bereichen mitunter eine formale Selbstzertifizierung. Diese Unterschiede erschweren es zusätzlich, ein einheitliches Sicherheitsniveau über alle Komponenten hinweg zu gewährleisten.
Open-Source-Komponenten, die in der Softwareentwicklung heute fest etabliert sind, finden auch in der Embedded-Welt zunehmend Verwendung. Doch nicht jeder Beitrag stammt von erfahrenen Spezialisten. Häufig fehlen nachvollziehbare Wartungsprozesse, Versionierung oder Sicherheitsupdates. Hinzu kommt: Wer eine Bibliothek einbindet, übernimmt nicht nur deren Funktionalität, sondern auch deren potenzielle Schwachstellen – eine Verantwortung, die im Tagesgeschäft leicht übersehen wird.
Diese Gemengelage aus technischer Vielfalt, verteilten Verantwortlichkeiten, variierendem Sicherheitsbewusstsein und uneinheitlichen Prüfprozessen macht es nahezu unmöglich, Embedded Firmware vollständig zu durchdringen – geschweige denn ihre Risiken ad hoc zu bewerten.
Fokus auf Funktionalität – Sicherheit bleibt oft außen vor
In vielen Embedded-Projekten steht die Funktionalität im Vordergrund. Die Entwicklung folgt häufig technischen Zielvorgaben, etwa zur Realisierung bestimmter Steuerungsfunktionen, Kommunikationsprotokolle oder Benutzerinteraktionen. Sicherheitsaspekte – ob in Bezug auf Manipulationsschutz, Zugriffskontrollen oder Integrität der Software – werden dabei meist erst spät oder gar nicht adressiert. Das gilt insbesondere für Systeme, die nicht direkt mit dem Internet verbunden sind. Hier dominiert oft der trügerische Gedanke eines „Security by Obscurity“: Was nicht sichtbar ist, scheint auch nicht angreifbar.
In der Realität offenbart sich jedoch regelmäßig das Gegenteil. Sicherheitslücken in Embedded-Systemen werden meist erst dann ernst genommen, wenn sie aktiv ausgenutzt werden – etwa durch Cyberangriffe, Produktionsausfälle oder Rückrufaktionen. Cybersecurity wird so zur reaktiven Disziplin, statt integraler Bestandteil der Systemarchitektur zu sein.
Ein weiterer kritischer Punkt ist das Fehlen einer vollumfänglichen Systemdefinition. In der Praxis mangelt es oft an einem systematischen Planungsschritt, der die Funktion und das Umfeld eines Systems ganzheitlich beschreibt – etwa in Form einer sogenannten „Item Definition“ (wie sie etwa im Kontext funktionaler Sicherheit nach ISO 26262 gefordert wird). Ohne diese strukturierte Analyse fehlt die Grundlage, um Sicherheitsbedarfe überhaupt zu identifizieren, Bedrohungsszenarien abzuleiten oder geeignete Schutzmaßnahmen zu entwerfen.
Diese Versäumnisse führen dazu, dass potenzielle Risiken häufig unterschätzt werden. Die Ursachen liegen dabei nicht in böswilliger Absicht, sondern in strukturellen und methodischen Lücken:
- Unklarer Herkunft einzelner Softwarekomponenten
- Fehlender Versionierung oder Abhängigkeiten
- Fehlenden Prozessen zur Aktualisierung der Firmware
- Keine konsolidierte Sicht auf Funktionen, Schnittstellen und Risiken des Systems als Ganzes
Embedded-Systeme werden so zu Black Boxes, deren wahre Komplexität und Verwundbarkeit erst im Ernstfall sichtbar wird – mit potenziell gravierenden Auswirkungen auf Produkte, Nutzer und Unternehmen.
SBOM: Transparenz als Grundlage der Sicherheitsstrategie
Ein vielversprechender Ansatz zur Bewältigung der Komplexität moderner Embedded Firmware ist die Einführung einer Software Bill of Materials (SBOM). Sie fungiert als strukturierte Inventarliste aller eingesetzten Softwarebestandteile – vergleichbar mit einer Stückliste in der Hardwareproduktion. Eine SBOM dokumentiert, welche Module, Bibliotheken, Frameworks und Tools in einem System enthalten sind – unabhängig davon, ob sie eigenentwickelt, von Drittanbietern zugekauft oder aus Open-Source-Quellen integriert wurden.
Diese Transparenz ist essenziell, um Sicherheitsrisiken nachvollziehbar zu machen, Schwachstellen zu identifizieren, Abhängigkeiten zu verstehen und gezielt reagieren zu können – etwa im Fall öffentlich gewordener Sicherheitslücken. Gleichzeitig bietet eine SBOM eine solide Grundlage für Compliance- und Zertifizierungsprozesse, insbesondere bei wachsendem regulatorischem Druck.
Vorteile einer SBOM:
- Erhöhte Transparenz über eingesetzte Softwarekomponenten und deren Herkunft
- Nachvollziehbarkeit von bekannten Schwachstellen (z. B. CVEs) und technischen Abhängigkeiten
- Unterstützung bei regulatorischer Compliance und in Audits
In regulatorischen Rahmenwerken ist die SBOM bislang nur teilweise verankert. In der Automobilindustrie etwa taucht sie in der ISO/SAE 21434 („Road Vehicles – Cybersecurity Engineering“) und der UNECE R155 („Cybersecurity and Cybersecurity Management System“) zwar als hilfreiches Werkzeug auf, wird jedoch nicht explizit vorgeschrieben. Beide Normen fordern ein strukturiertes Cybersecurity-Management, das nachvollziehbar dokumentiert, wie Risiken kontrolliert und Softwarebestandteile überwacht werden – Aufgaben, die eine gut gepflegte SBOM effektiv unterstützen kann. Ein verpflichtendes Element der Homologation ist sie aktuell jedoch nicht.
Diese Unverbindlichkeit hat zur Folge, dass SBOMs zwar vermehrt eingesetzt werden – häufig auf Druck von OEMs oder als Reaktion auf externe Prüfungen –, jedoch mit stark variierender Qualität und Detailtiefe. Viele SBOMs bleiben auf der Ebene einfacher Dateinamen oder Modulnamen stehen und verzichten auf essenzielle Informationen wie Versionsnummern, Hashwerte oder Bezugsquellen. Damit verlieren sie einen Großteil ihres sicherheitstechnischen Nutzens.
Herausforderung: Präzision und Aktualität
Die Herausforderung liegt weniger in der grundsätzlichen Erstellung einer SBOM, sondern in ihrer nachhaltigen Pflege. Softwareprojekte sind dynamisch: Module werden aktualisiert, ersetzt oder verworfen – oft ohne zentrale Nachverfolgung. Eine SBOM ist daher nur dann ein wirksames Sicherheitsinstrument, wenn sie kontinuierlich aktualisiert und idealerweise automatisiert erzeugt wird. Nur so lässt sich sicherstellen, dass die dokumentierte Softwarebasis auch tatsächlich dem ausgelieferten Stand entspricht – und damit als belastbare Entscheidungsgrundlage für Security-Maßnahmen, Reaktionsstrategien und Audits dient.
Dabei zeigt sich: Präzision ist nicht nur eine technische, sondern auch eine konzeptuelle und kulturelle Frage. In manchen Organisationen oder Regionen dominiert ein minimalistischer Ansatz: Hauptsache dokumentiert, Detailtiefe zweitrangig. In anderen Kontexten hingegen gelten höchste Anforderungen an Nachvollziehbarkeit und formale Vollständigkeit. Diese Spannweite zeigt sich etwa in der Frage, ob lediglich Dateinamen und Modulbezeichnungen gelistet werden, oder ob zusätzlich Versionsnummern, kryptografische Hashwerte, Herkunftsangaben und Lizenzinformationen erfasst werden – allesamt entscheidend für die Aussagekraft einer SBOM.
Zudem fehlt häufig ein einheitliches Verständnis darüber, was eine „gute“ SBOM ausmacht. Während einige Unternehmen SBOMs als lebende Dokumente mit direkter Anbindung an CI/CD-Pipelines pflegen, betrachten andere sie als statisches Annex-Dokument zur Auslieferung – oft manuell erstellt und ohne Aktualisierungsprozess. In der Folge entsteht ein breites Spektrum an Umsetzungsqualität, das sich direkt auf die Wirksamkeit von Sicherheitsmaßnahmen auswirkt.
Langfristig wird die Qualität von SBOMs daher auch eine Frage der Organisationskultur sein: Wie ernst nimmt ein Unternehmen Transparenz, Nachverfolgbarkeit und Verantwortung in der Softwarelieferkette?
Firmware-Analyse als ergänzende Maßnahme
SBOMs allein reichen nicht aus. Sie bieten zwar Transparenz über bekannte Komponenten – basieren jedoch auf der Annahme, dass die eingesetzte Software vollständig und korrekt dokumentiert wurde. In der Realität ist das jedoch häufig nicht der Fall: Bibliotheken werden nicht deklariert, modifizierte Open-Source-Komponenten weichen vom Original ab oder externe Module wurden nie eindeutig identifiziert. Genau hier setzt die Firmware-Analyse an.
Mithilfe spezialisierter Werkzeuge lassen sich Binärdateien – also das tatsächlich ausgelieferte Softwareabbild – untersuchen, ohne auf Quellcode oder externe Dokumentation angewiesen zu sein. Zu den eingesetzten Verfahren zählen unter anderem statische Codeanalyse, Pattern Matching, Heuristiken, Entropieanalysen oder der Abgleich mit bekannten Komponenten-Datenbanken.
Die zentralen Aufgaben einer Firmware-Analyse umfassen:
- Identifikation von Softwarekomponenten: Welche Libraries, Frameworks oder proprietären Module sind tatsächlich enthalten?
- Abgleich mit deklarierter SBOM: Stimmen Soll- und Ist-Zustand überein oder fehlen Angaben?
- Extraktion technischer Metadaten: Informationen zu Version, Herkunft, Architektur und Konfiguration der Komponenten
- Aufbereitung der Analyseergebnisse: Strukturiertes Reporting zur Weiterverarbeitung in Security-Tools, Schwachstellendatenbanken oder Compliance-Systemen
Die Genauigkeit und Aussagekraft solcher Analysen hängt stark vom jeweiligen Tool, der eingesetzten Methodik und dem konkreten Anwendungskontext ab. Während sich in standardisierten Systemlandschaften mit gängigen Komponenten oft eine hohe Abdeckung erzielen lässt, stoßen viele Analyseverfahren bei stark proprietären, obfuskierten1 oder verschlüsselten Firmwares an technische Grenzen.
Zudem beeinflusst auch die Beschaffenheit des Embedded Systems die Erkennungsqualität: etwa das verwendete Betriebssystem, das Build-System, eingesetzte Compilertechniken oder Schutzmaßnahmen gegen Reverse Engineering. In der Praxis ergibt sich dadurch ein heterogenes Bild – von nahezu vollständiger Transparenz bis hin zu schwer interpretierbaren Binärdaten ohne klare Referenzen.
Die Erwartungshaltung an Firmware-Analysen sollte daher realistisch bleiben: Eine vollständige Rekonstruktion aller Komponenten ist nicht immer möglich – insbesondere in stark geschützten Systemen. Dennoch liefern die Analysen wertvolle Einblicke, decken Inkonsistenzen auf und machen bislang verborgene Risiken sichtbar. Ihre Ergebnisse sprechen oft für sich – gerade dann, wenn sie zeigen, was in offiziellen Unterlagen bisher nicht dokumentiert war.
Eine vertiefte Betrachtung der technischen Verfahren, etwa Unterschiede zwischen statischer und dynamischer Analyse oder die Rolle von maschinellem Lernen, ist Gegenstand eines separaten Beitrags. Für das Management ist jedoch zentral: Die Firmware-Analyse bildet eine unverzichtbare Ergänzung zur SBOM – nicht als Redundanz, sondern als absichernde Kontrollinstanz im Rahmen einer ganzheitlichen Sicherheitsstrategie.
1„Obfuskiert“ bedeutet, dass der Code absichtlich unleserlich gemacht wurde – etwa durch Umbenennung von Variablen oder komplexe Verschachtelungen – um Rückschlüsse auf Funktionsweise und Struktur zu erschweren.
Strategischer Nutzen für das Management
Für Unternehmen ergibt sich ein klarer strategischer Vorteil: Wer über vollständige SBOMs und ein wirksames Firmware-Audit verfügt, gewinnt nicht nur technische Transparenz, sondern auch Kontrolle über zentrale Geschäftsrisiken. Die systematische Erfassung und Analyse eingebetteter Software schafft eine belastbare Grundlage für unternehmerische Entscheidungen – von der Produktentwicklung über das Risikomanagement bis hin zur Vorbereitung auf regulatorische Prüfungen.
Konkret lassen sich durch professionelle Softwaretransparenz:
- Sicherheitsvorfälle schneller einordnen, priorisieren und beheben
- Lieferkettenrisiken gezielt erkennen und Gegenmaßnahmen planen
- Regulatorische Anforderungen und Auditpflichten proaktiv erfüllen
- Haftungs- und Reputationsrisiken durch fehlende Sicherheitsnachweise minimieren
- Partnerschaften mit OEMs und Behörden auf Basis nachvollziehbarer Dokumentation stärken
Damit wird Embedded Security vom operativen Randthema zur Führungsaufgabe. Denn mangelnde Transparenz in Firmware ist nicht nur ein technisches Risiko, sondern ein strategisches Versäumnis mit potenziellen Folgen für Produkthaftung, Marktakzeptanz und Unternehmenswert. Investitionen in SBOM-Prozesse und Analysekompetenz zahlen sich doppelt aus: Sie reduzieren Unsicherheiten in der Entwicklung und schaffen Vertrauen bei Kunden, Aufsichtsbehörden und Investoren.
Vor allem in regulierten Märkten – etwa der Automobilindustrie, der Medizintechnik oder kritischen Infrastrukturen – können Unternehmen, die ihre Embedded Software nachvollziehbar beherrschen, ihre Wettbewerbsposition aktiv stärken. Sicherheitskompetenz wird so zum Differenzierungsmerkmal – sichtbar dokumentiert und revisionssicher belegbar.
Fazit: Sicherheit beginnt mit Sichtbarkeit
Embedded Firmware ist mehr als nur technisches Beiwerk – sie ist die Lebensader unzähliger Systeme und ein zunehmend sicherheitskritischer Bestandteil moderner Produkte. Ihre Qualität und Integrität entscheiden nicht nur über die Zuverlässigkeit einzelner Funktionen, sondern über das Vertrauen in ganze Produktgenerationen. In sicherheitsrelevanten Anwendungen – etwa in Fahrzeugen, Medizingeräten oder industriellen Steuerungen – kann mangelnde Transparenz fatale Folgen haben.
Wer diese Verantwortung ernst nimmt, muss Transparenz über die eigene Firmware-Landschaft schaffen. Das beginnt mit einer präzisen Dokumentation aller eingesetzten Softwarekomponenten (SBOM) und setzt sich fort in deren technischer Überprüfung durch spezialisierte Firmware-Analysen. SBOMs und begleitende Analysemethoden sind dabei keine Kür, sondern zunehmend ein Muss – sowohl aus regulatorischer Sicht als auch im Hinblick auf Kundenanforderungen und den Schutz der eigenen Lieferkette.
Sichtbarkeit ist dabei mehr als eine technische Maßnahme – sie ist Ausdruck von Führungsverantwortung. Denn in einer Welt zunehmender Cyberbedrohungen, wachsender Vernetzung und verschärfter Compliance-Vorgaben ist es Aufgabe des Managements, Sicherheit nicht nur zu fordern, sondern auch strukturell zu ermöglichen. Wer heute nicht weiß, was in seinen Systemen steckt, kann morgen kaum erklären, warum etwas schieflief.
Die gute Nachricht: Die Werkzeuge und Methoden zur Herstellung dieser Transparenz existieren – es braucht lediglich den strategischen Willen, sie konsequent einzusetzen. Wer das tut, investiert nicht nur in Schutz, sondern in Resilienz, Vertrauen und nachhaltige Wettbewerbsfähigkeit.
Praxisbeispiele: SBOMs und Firmware-Analysen im Einsatz
Reale Fallstudien zeigen, wie SBOMs und Firmware-Analysen in der Praxis eingesetzt werden, um Sicherheitsrisiken zu identifizieren und zu mitigieren:
- Automatisierte Firmware-Analyse bei Embedded Web Interfaces: Eine Studie präsentierte ein Framework zur dynamischen Analyse von Firmware in eingebetteten Geräten wie Routern und IP-Kameras. Durch Emulation und Analyse von 1.925 Firmware-Images wurden Schwachstellen in 185 Fällen entdeckt, was die Effektivität solcher Analysen unterstreicht. [Quelle]
- SBOMs in der Medizintechnik: Philips implementierte SBOMs in seinen Produkten, um den Anforderungen der US-amerikanischen FDA gerecht zu werden. Seit März 2023 verlangt die FDA SBOMs in der Zulassung von Medizinprodukten, was die Bedeutung von Transparenz in sicherheitskritischen Bereichen hervorhebt. [Quelle]
- Firmware-Sicherheitsanalyse bei Siemens S7-1500 Steuerungen: Forscher entdeckten eine Schwachstelle in der Firmware von Siemens S7-1500 PLCs, die es Angreifern ermöglicht, manipulierte Firmware zu installieren. Diese Lücke kann nicht durch ein Software-Update behoben werden, was die Notwendigkeit von Firmware-Integritätsprüfungen betont. [Quelle]
Diese Beispiele verdeutlichen, dass SBOMs und Firmware-Analysen nicht nur theoretische Konzepte sind, sondern in der Praxis entscheidende Werkzeuge zur Erhöhung der Systemsicherheit darstellen.