Secure SDLC für Embedded Devices

Embedded Devices werden mit Software ausgeliefert, die häufig über ein Jahrzehnt oder länger im Einsatz bleibt. Eine Schwachstelle, die zum Zeitpunkt der Fertigung in der Firmware vorhanden ist, kann Jahre nach der Markteinführung eines Produkts zu einem kritischen Sicherheitsvorfall führen. Anders als bei Webanwendungen erhalten eingebettete Softwaresysteme selten automatische Updates. Die Folgen eines Angriffs gehen häufig weit über Datenverlust hinaus und reichen bis hin zu Gefährdungen der physischen Sicherheit, Betriebsunterbrechungen oder regulatorischen Konsequenzen. Diese Realität macht einen strukturierten Secure SDLC für jedes Unternehmen, das vernetzte Hardware entwickelt, unverzichtbar: Sicherheitsmaßnahmen müssen in jede Entwicklungsphase integriert sein, nicht erst am Ende nachgerüstet werden.

Für Product-Security-, PSIRT- und Compliance-Teams in den Bereichen IoT, OT, Automotive oder Medizintechnik besteht die Herausforderung darin, einen Secure Development Lifecycle in Umgebungen umzusetzen, die individuelle Hardware-Anforderungen, Drittanbieterkomponenten und binäre Firmware-Blobs vereinen. Dieser Leitfaden erläutert, was Security im Software Development Lifecycle in diesem Kontext bedeutet. Er zeigt den Unterschied zu DevSecOps, welche Maßnahmen für Firmware-basierte Produkte besonders wichtig sind und wie speziell entwickelte Tools den gesamten Prozess messbar und nachvollziehbar machen.

Das Wichtigste in Kürze

• Sicherheitsanforderungen und Threat-Modeling-Konzepte vor Beginn der Implementierung definieren: physische Schnittstellen, Netzwerkdienste, Update-Mechanismen und kryptografische Implementierungen analysieren
• Sicherheit durchgängig in die Implementierung einbetten: durch sichere Coding-Standards, statische Analyse und Software Composition Analysis, integriert in die Build-Pipeline
• Umfassende Verifikation durchführen: Fuzz-Testing, Hardware-in-the-Loop-Tests und Penetrationstests – mit dokumentierten Nachweisen zur Erfüllung der Sicherheitsanforderungen
• Prozesse zur Nachmarktüberwachung etablieren, um veröffentlichte Firmware-Komponenten kontinuierlich gegen Schwachstellen-Datenbanken abzugleichen und regulatorische Meldefristen einzuhalten, etwa die 24-Stunden-Meldepflicht des Cyber Resilience Act
• Präzise SBOMs mithilfe von Binäranalysen erstellen, um alle Komponenten zu erfassen – einschließlich Drittanbieter-Binärdateien und statisch gelinkter Module, die Build-System-Manifeste häufig nicht berücksichtigen

Was ist ein Secure SDLC?

Ein Secure SDLC (Secure Software Development Life Cycle) ist ein Prozess für sichere Softwareentwicklung. Er verankert Sicherheit in jeder Phase, von den Anforderungen bis zur Wartung nach dem Release. Dafür ergänzt er den klassischen SDLC um Threat Modeling, sichere Coding-Praktiken, Sicherheitstests und Schwachstellenmanagement. Das Ziel ist, Schwachstellen früh zu finden und zu beheben, solange Korrekturen noch wenig kosten. Bei Embedded Devices umfasst ein Secure SDLC zusätzlich Firmware, Drittanbieterkomponenten und Produkte, die jahrelang im Feld bleiben.

In seiner einfachsten Form beschreibt der Software Development Life Cycle (SDLC) die strukturierte Abfolge von Phasen, in denen ein Entwicklungsteam Software konzipiert, entwickelt, testet und wartet. Ein Secure Development Lifecycle erweitert dieses Modell. Er integriert Sicherheitsziele, Kontrollen und Verifikationsaktivitäten in jede einzelne Phase, statt nur ein einziges Security-Review am Ende der Entwicklung durchzuführen.

In einem konventionellen Software Development Lifecycle ohne explizite Sicherheitsintegration entdecken Teams Schwachstellen oft erst spät. Die Behebung ist dann teuer und zeitaufwendig. Ist Sicherheit bereits ab der Anforderungsphase verankert, fließen Threat Models in die Designentscheidungen ein. Sichere Coding-Standards steuern die Implementierung, und automatisierte Scans erkennen Probleme, bevor der Code in die Produktions-Firmware gelangt. Das Ergebnis ist eine messbar geringere Schwachstellendichte in ausgelieferten Produkten. Hinzu kommt ein belastbarer Prozess, dessen Dokumentation Regulierungsbehörden und Kunden zunehmend erwarten.

Hersteller von Embedded Devices müssen in ihrem Secure Development Lifecycle Herausforderungen adressieren, die klassische Softwareentwicklungsteams selten kennen. Firmware enthält häufig Open-Source-Bibliotheken, kommerzielle Standardkomponenten (COTS) und Binary Blobs von Chipsatzherstellern. Die Lieferkette ist komplex. Das SDLC Framework muss daher auch geerbte Schwachstellen aus vorgelagerten Komponenten berücksichtigen, nicht nur intern geschriebenen Code. Normen wie IEC 62443-4-1 für die industrielle Automatisierung und ISO/SAE 21434 für den Automotive-Bereich haben diese Erwartungen festgeschrieben. Ein dokumentierter Secure Development Lifecycle ist damit eine Compliance-Anforderung und nicht mehr nur eine Best Practice.

Ein Secure SDLC umfasst typischerweise fünf Phasen:

• Anforderungserhebung: Sicherheitsziele gemeinsam mit funktionalen Zielen definieren, bevor die erste Zeile Code entsteht.
• Design: Threat Models nutzen, um Architekturentscheidungen und Sicherheitskontrollen fundiert festzulegen.
• Implementierung: Sichere Coding-Standards und automatisierte Scans während der Entwicklung anwenden.
• Verifikation: Vor dem Release gegen die definierten Sicherheitsanforderungen testen.
• Deployment und Wartung: Ausgelieferte Produkte über ihre gesamte Lebensdauer auf neu entdeckte Schwachstellen überwachen.

Secure SDLC und DevSecOps im Vergleich

Die Begriffe Secure SDLC und DevSecOps werden häufig synonym verwendet, bezeichnen zwar verwandte, jedoch keine identischen Konzepte. Ein Secure Development Lifecycle ist ein Framework: eine definierte Abfolge von Phasen, Aktivitäten und Prüfpunkten, die regeln, wie Software von der Konzeption bis zur Außerbetriebnahme entwickelt wird. DevSecOps ist ein kulturelles und operatives Modell, das Sicherheitsmaßnahmen kontinuierlich in agile oder CI/CD-Pipelines integriert und Automatisierung nutzt, um Security nach links zu verlagern und in jeden Commit, Build und Deployment einzubetten.

In der Praxis sind DevSecOps-Tools wie Scanner für statische Analyse, Plattformen für Software Composition Analysis und Container-Security-Tools die Mechanismen, mit denen Security im Software Development Lifecycle in einem schnell getakteten Entwicklungsumfeld umgesetzt wird. Das Verwalten einer Firmware-SBOM in DevSecOps ist dabei ein zentraler Baustein für einen präzisen und kontinuierlichen Prozess. DevSecOps operationalisiert das SDLC-Framework. Organisationen, die DevSecOps ohne ein zugrundeliegendes Framework einführen, verfügen oft über kontinuierliches Scanning, aber kein strukturiertes Threat Modeling, keine definierten Sicherheitsanforderungen und keine Post-Market-Überwachungsprozesse, die ein vollständiger Lebenszyklus erfordert.

Für Embedded-Device-Teams ist diese Unterscheidung relevant, weil Firmware-Entwicklungszyklen einer typischen Webanwendungs-Pipeline selten ähneln. Build-Zeiten sind länger, Hardware-in-the-Loop-Tests verursachen Verzögerungen und Release-Gates sind aufgrund regulatorischer Anforderungen formeller. Ein klar definiertes SDLC Framework gibt Teams die Struktur, die sie benötigen, um Regulierungsanforderungen wie den europäischen Cyber Resilience Act zu erfüllen. DevSecOps-Tools helfen dabei, die Sicherheitsaktivitäten innerhalb dieser Struktur zu automatisieren. Beides ist notwendig, keines davon allein ausreichend.

H2: Die Phasen des Secure Development Lifecycle

Die Integration von Sicherheitsmaßnahmen über einen vollständigen Development Lifecycle hinweg erfordert, jede Phase an die Gegebenheiten von Firmware, ressourcenbeschränkter Hardware und langen Produktlebenszyklen anzupassen.

H2: Anforderungen und Threat Modeling

Sicherheitsanforderungen müssen definiert sein, bevor eine einzige Zeile Code geschrieben wird. In der Anforderungsphase identifizieren Teams die zu schützenden Assets des Geräts, die wahrscheinlichsten Angreifer und die Sicherheitseigenschaften, die das Produkt nachweisen muss. Diese Anforderungen fließen direkt in Designentscheidungen ein und bilden die Messlatte für spätere Tests. Fehlen sie, haben Sicherheitsaktivitäten im weiteren Lifecycle kein klares Ziel.

Threat Modeling formalisiert den Prozess, mögliche Angriffswege auf ein Gerät zu identifizieren. Die Rolle des Threat Modeling in SDLC zu verstehen ist für Teams essenziell, die komplexe Embedded Products mit mehreren Schnittstellen entwickeln. Bei einem Embedded Device umfasst das die Analyse folgender Aspekte:

• Physischen Schnittstellen wie JTAG und UART, die Low-Level-Hardware-Zugriff ermöglichen.
• Netzwerkdiensten, die über WLAN, Ethernet, Bluetooth oder Mobilfunk exponiert sind.
• Update-Mechanismen, die zur Auslieferung schadhafter Firmware missbraucht werden könnten.
• Kryptografischen Implementierungen, bei denen schwache Algorithmen oder Schlüsselverwaltungsfehler systemische Risiken erzeugen.

Designentscheidungen, die in dieser Phase getroffen werden, wie die Implementierung von Secure Boot, die Konfiguration der Memory Protection Unit und das Layout verschlüsselter Speicherbereiche, sind in der frühen Phase deutlich kostengünstiger umzusetzen als nachträglich nach dem Tapeout des Chips. Teams, die Sicherheitsanforderungen als optional behandeln oder Threat Modeling auf spätere Phasen verschieben, stehen regelmäßig vor der Wahl: Hardware-Redesign oder bekannte Risiken in ausgelieferten Produkten akzeptieren.

Implementierung, Verifikation und Release

In der Implementierungsphase legen sichere Coding-Standards fest, wie Entwickler Code schreiben und reviewen. Für Embedded C und C++ bedeutet das die Durchsetzung von Regeln zu Speicherverwaltung, Integer-Overflow-Behandlung und dem sicheren Einsatz externer Bibliotheken. In die Build-Pipeline integrierte Static-Analysis-Tools erkennen gängige Schwachstellenklassen automatisch. Das entlastet Code-Reviews und erzeugt gleichzeitig einen Audit-Trail, der Compliance-Dokumentationsanforderungen erfüllt.

Die Verifikation umfasst sowohl dynamische Tests als auch Binäranalysen. Zu dieser Phase gehören folgende Aktivitäten:

• Fuzz-Tests von Netzwerkschnittstellen und Parsern, um unerwartete Fehler bei der Eingabeverarbeitung aufzudecken.
• Hardware-in-the-Loop-Tests von Update-Mechanismen unter realistischen Bedingungen.
• Penetrationstests exponierter Dienste zur Validierung der Angriffssicherheit unter realen Bedingungen.

Bei Produkten, die IEC 62443-4-1 oder der Medical Device Regulation unterliegen, muss die Verifikationsphase dokumentierte Nachweise erbringen, dass Sicherheitsanforderungen erfüllt wurden. Aus dem ursprünglichen Threat Model abgeleitete Testfälle schließen den Kreislauf zwischen Planung und tatsächlicher Prüfung.

Freigabe-Gates stellen sicher, dass Firmware ein Mindestsicherheitsniveau erfüllt, bevor sie ausgeliefert wird. Dazu gehören typischerweise ein sauberer Software-Composition-Analysis-Bericht, eine vollständige und präzise Software Bill of Materials, erstellt mit einem zuverlässigen SBOM-Management-Tool, sowie die Freigabe aller akzeptierten Restrisiken. Die Automatisierung dieser Gates in einer CI/CD-Pipeline reduziert den Aufwand für Compliance und stellt sicher, dass keine Freigabe die erforderlichen Prüfungen umgeht. Die Freigabe ist zugleich der Zeitpunkt, an dem Post-Market-Überwachungsprozesse initialisiert werden und die Baseline für das Schwachstellen-Tracking gegen die ausgelieferte SBOM festgelegt wird.

Post Market Monitoring

Bei Embedded Devices endet die Sicherheitsverantwortung nicht mit der Auslieferung der Firmware. Produkte bleiben jahrelang im Einsatz, und in Drittanbieterkomponenten werden kontinuierlich neue Schwachstellen entdeckt. Post-Market-Monitoring bedeutet, die Komponenten jeder veröffentlichten Firmware-Version aktiv gegen Schwachstellendatenbanken wie die National Vulnerability Database abzugleichen und neue CVEs, sobald sie veröffentlicht werden, gegen den bekannten Komponentenbestand des Geräts zu priorisieren.

Ein wirksamer Post-Market-Überwachungsprozess steht und fällt mit der Genauigkeit und Vollständigkeit der bei der Freigabe erstellten SBOM. Ein Schwachstellenmanagement-Tool, das dieses Inventar kontinuierlich auswertet, macht eine operative Post-Market-Überwachung im großen Maßstab erst möglich. Wenn die SBOM den tatsächlichen Inhalt des Firmware-Binärs nicht präzise abbildet, entstehen sowohl falsch positive als auch falsch negative Treffer beim Schwachstellen-Abgleich. Automatisierte Binäranalyse-Tools, die Komponentendaten direkt aus Firmware-Images extrahieren, anstatt sich ausschließlich auf Build-System-Metadaten zu stützen, liefern die Genauigkeit, die eine effektive Post-Market-Überwachung erfordert.

Der Cyber Resilience Act verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden zu melden und Sicherheitsvorfälle innerhalb von 72 Stunden zu notifizieren. Diese Pflichten ohne strukturierten Post-Market-Monitoring-Prozess zu erfüllen, ist operativ sehr anspruchsvoll. Teams, die Monitoring von Beginn an in ihr SDLC Framework integriert haben, sind deutlich besser aufgestellt, diese Fristen einzuhalten, als jene, die Komponenteninventare erst nach der Veröffentlichung einer Schwachstelle rekonstruieren müssen.

Secure SDLC Best Practices für Firmware

Firmware bringt Rahmenbedingungen mit sich, die einige Standard-Sicherheitspraktiken im Software Development Lifecycle schwieriger umsetzbar und andere umso wichtiger machen.

Die Analyse von Binärdateien ohne Quellcode ist für Embedded Security Teams eine alltägliche Herausforderung. Drittanbieterkomponenten, Chipsatz-Bibliotheken und Legacy-Module werden häufig als kompilierte Binärdateien ohne begleitenden Quellcode geliefert. Klassische Static Analysis Tools können diese Komponenten nicht direkt analysieren. Binäranalyse-Techniken, darunter Binary Software Composition Analysis und symbolische Ausführung, extrahieren Komponentenidentitäten, Versionsstrings und bekannte Schwachstellenmuster aus kompilierten Firmware-Images, ohne dass Quellcodezugriff erforderlich ist.

Die Erstellung eines Software Bill of Materials für jeden Release ist unter mehreren regulatorischen Rahmenwerken eine explizite Anforderung. Das SBOM muss folgende Bestandteile erfassen:

• Intern entwickelte Eigenkomponenten einschließlich Versions- und Build-Metadaten.
• Open-Source-Bibliotheken, die direkt oder transitiv in das Firmware-Image eingebunden sind.
• Drittanbieter-Binärdateien und statisch gelinkte Module, die Build-System-Manifeste häufig nicht erfassen.

Bei Firmware ist dafür die Analyse des Binärimages selbst notwendig, da Build-System-Manifeste häufig statisch gelinkte oder ohne explizite Abhängigkeitsdefinitionen eingebettete Komponenten übersehen. Ein aus der Binäranalyse erzeugtes SBOM spiegelt die tatsächliche Zusammensetzung des ausgelieferten Produkts wider, nicht das, was das Build-System vermeintlich enthält.

Die Compliance-Anforderungen von CRA und IEC 62443-4-1 konvergieren in mehreren zentralen Punkten:

• Dokumentierte Sicherheitsanforderungen, die vor Entwicklungsbeginn festgelegt werden.
• Strukturierte Bedrohungsanalyse nach anerkannten Methoden wie STRIDE oder TARA.
• Schwachstellenmanagement-Prozesse, die sowohl die Entwicklungsphase als auch die Post-Market-Phase abdecken.
• Eine definierte Richtlinie zur koordinierten Offenlegung von Schwachstellen, die regulatorische Meldefristen erfüllt.

IEC 62443-4-1 definiert einen Security Development Lifecycle für industrielle Produkte, der eng an die in diesem Leitfaden beschriebenen Phasen angelehnt ist. Der Cyber Resilience Act erstreckt vergleichbare Anforderungen auf nahezu alle vernetzten Produkte, die in der Europäischen Union vertrieben werden. Teams mit einem dokumentierten SDLC Framework sind deutlich besser positioniert, die Konformität mit beiden Standards nachzuweisen, als Teams, die auf informelle Prozesse setzen.

ONEKEY und der Secure SDLC

ONEKEY ist eine Firmware-Analyse-Plattform, die speziell für die Sicherheitsanforderungen von Herstellern von Embedded Devices entwickelt wurde. Sie automatisiert die Analyse von Firmware-Binärdateien, erstellt detaillierte Komponenteninventare und SBOMs und gleicht erkannte Komponenten gegen bekannte Schwachstellen aus mehreren Threat-Intelligence-Quellen ab. Diese Fähigkeit adressiert die mit Abstand häufigste Lücke in Embedded-Secure-SDLC-Implementierungen: die fehlende Möglichkeit, den Inhalt eines Firmware-Binärimages ohne Quellcode-Zugriff präzise zu erfassen.

In den Implementierungs- und Verifikationsphasen integriert sich ONEKEY in CI/CD-Pipelines und liefert bei jedem Build eine automatisierte Firmware-Analyse. Security-Teams erhalten für jede Firmware-Version einen strukturierten Schwachstellenbericht und ein SBOM, wodurch ein lückenloses Sicherheitsposturen-Protokoll für jeden Release-Kandidaten entsteht. Release-Gates lassen sich so konfigurieren, dass Firmware-Builds blockiert werden, die definierte Schwachstellen-Schwellenwerte überschreiten. Damit werden Sicherheitsanforderungen automatisch durchgesetzt, ohne auf manuelle Reviews angewiesen zu sein.

Für das Post-Market-Monitoring überwacht ONEKEY den Komponentenbestand ausgelieferter Firmware-Versionen kontinuierlich gegen aktualisierte Schwachstellen-Intelligence. Wird ein neuer CVE gegen eine Bibliotheksversion veröffentlicht, die in einem ausgelieferten Produkt vorhanden ist, erhalten Security-Teams sofort eine Benachrichtigung mit Kontext zu betroffenen Produkten und dem Schweregrad. Diese Funktion unterstützt direkt die Meldefristen des Cyber Resilience Act und liefert die dokumentierten Nachweise eines laufenden Schwachstellenmanagements, die IEC 62443-4-1 und ISO/SAE 21434 voraussetzen. ONEKEY macht den Secure SDLC für Teams, die komplexe Firmware-Produkte mit vielen Komponenten in regulierten Märkten entwickeln, operativ umsetzbar.