Thought Leadership
Smart Devices bleiben oft viele Jahre im Einsatz. Ihre Software entwickelt sich während dieser Zeit kontinuierlich weiter und erreicht unterschiedliche Supportzeiträume.
Mit dem Cyber Resilience Act (CRA) entsteht für Hersteller daraus eine zentrale Aufgabe: Sie müssen ihre Produkte über den festgelegten Unterstützungszeitraum sicher halten und Schwachstellen beheben können. Ob das langfristig gelingt, entscheidet sich bereits bei Architektur, Technologieauswahl und Entwicklung.
Denn ein vernetztes Gerät vereint Komponenten mit verschiedenen Lebenszyklen. In einem Smart-Home-Gateway, einer vernetzten Maschine oder einem anderen IoT-Produkt arbeiten Hardware, Firmware, Betriebssystem, Softwarebibliotheken, Schnittstellen und Lösungen verschiedener Anbieter zusammen. Während die Hardware über viele Jahre zuverlässig funktionieren kann, entwickeln sich Softwarebibliotheken und Schnittstellen kontinuierlich weiter. Betriebssysteme erreichen definierte Supportzeiträume und neue Schwachstellen erfordern Updates einzelner Bausteine.
Entwicklungsteams müssen sich deshalb früh fragen: Lässt sich das Produkt auch in einigen Jahren noch sicher aktualisieren? Die technologische Langlebigkeit gehört deshalb von Beginn an in die Produktarchitektur.
Komponentenwahl entscheidet über langfristige Updatefähigkeit
Die Weichen stellen Hersteller bereits bei der Auswahl ihrer Komponenten. Neben den aktuellen technischen Anforderungen zählen auch die erwartete Supportdauer, die Qualität der Pflege, vorhandene Abhängigkeiten und die spätere Austauschbarkeit.
Softwarekomponenten bilden häufig komplexe Abhängigkeitsketten. Eine Bibliothek greift auf weitere Lösungen zurück, die wiederum eigene Voraussetzungen mitbringen. Aktualisiert oder ersetzt das Entwicklungsteam später einen Baustein, können sich Schnittstellen und Anforderungen an angrenzende Bereiche verändern.
Deshalb lohnt sich der Blick auf den gesamten Produktlebenszyklus. Eine eingesetzte Technologie sollte sowohl die aktuellen Anforderungen erfüllen und zugleich eine tragfähige Perspektive für Wartung und künftige Updates bieten.
Eine hilfreiche Leitfrage lautet: Wie tauschen wir diese Komponente in fünf oder zehn Jahren aus? Wer diese Frage früh beantwortet – etwa mit dokumentierten Schnittstellen und geprüften Alternativen –, schafft langfristigen Handlungsspielraum. Voraussetzung dafür ist Transparenz über den eigenen Software-Stack.
SBOM schafft Transparenz über Softwareabhängigkeiten
Eine Software Bill of Materials (SBOM) schafft diesen Überblick. Sie dokumentiert die Softwarebestandteile eines Produkts und deren Abhängigkeiten (z. B. im SPDX- oder CycloneDX-Format). Hersteller können damit nachvollziehen, welche Komponenten und Versionen sie in ihren Produkten einsetzen.
Der praktische Nutzen zeigt sich besonders beim Bekanntwerden einer neuen Schwachstelle. Mit einer aktuellen SBOM kann das Entwicklungsteam gezielt prüfen: Setzen wir die betroffene Komponente ein? In welchen Produkten und Versionen kommt sie vor? Welche weiteren Bestandteile hängen davon ab? Der Fall Log4Shell zeigte 2021, wie entscheidend das ist: Viele Unternehmen mussten nach Bekanntwerden der Schwachstelle erst mühsam klären, wo die betroffene Bibliothek über indirekte Abhängigkeiten überhaupt verbaut war.
Eine kontinuierlich gepflegte SBOM begleitet deshalb den gesamten Produktlebenszyklus. Aktualisiert das Team eine Bibliothek oder ersetzt einen Baustein, bildet es diese Veränderung auch in der Komponentenübersicht ab. Automatisierte Werkzeuge können die erfassten Daten zusätzlich mit Schwachstellendaten abgleichen. So erkennen Verantwortliche frühzeitig, wenn ein eingesetzter Baustein Aufmerksamkeit erfordert, und gewinnen Zeit für die Planung geeigneter Maßnahmen.
Die SBOM beantwortet damit die Frage, was im Produkt steckt. Bei Komponenten von Drittanbietern kommt eine zweite Frage hinzu: Wie lange können Hersteller mit deren Unterstützung planen?
Vendor Risk Management nimmt die technische Lieferkette in den Blick
Viele Bestandteile eines Smart Device stammen von Drittanbietern. Die langfristige Updatefähigkeit hängt daher auch von Zulieferern, Softwareanbietern und Open-Source-Projekten ab. Ein technisches Vendor Risk Management – über die klassische kommerzielle Lieferantenbewertung hinaus – schafft hier Orientierung. Entwicklung, Einkauf und IT-Sicherheit können gemeinsam bewerten: Wie lange unterstützt ein Anbieter seine Komponente? Wie geht er mit gemeldeten Schwachstellen um? Wie schnell stellt er Sicherheitsupdates bereit? Und welche weiteren Abhängigkeiten bringt seine Software mit?
Gerade der Blick auf diese Abhängigkeitsketten liefert wichtige Informationen. Eine eingekaufte Bibliothek kann Komponenten anderer Projekte oder Anbieter verwenden. Damit umfasst die technische Lieferkette mehrere Ebenen. Für zentrale Bestandteile sollten Hersteller deshalb frühzeitig eine Exit-Strategie entwickeln. Die 2024 entdeckte Backdoor in der weitverbreiteten Bibliothek XZ Utils, eingeschleust über einen über Jahre aufgebauten vertrauenswürdigen Maintainer-Zugang, zeigt zudem: Auch die Vertrauenswürdigkeit einzelner Open-Source-Maintainer gehört in die Bewertung. Sie können prüfen, welche Alternativen zur Verfügung stehen, wie sich eine Komponente austauschen lässt und welche kritischen Funktionen sie gegebenenfalls selbst weiterentwickeln können. Bei Open-Source-Software kann in bestimmten Fällen auch ein eigener Fork eine Option darstellen.
Die passende Strategie richtet sich nach Produkt, Einsatzgebiet und Kritikalität der jeweiligen Komponente. Eine frühzeitige Planung erweitert dabei die verfügbaren Handlungsoptionen. Damit diese später praktisch umsetzbar bleiben, muss auch die Produktarchitektur den Austausch von Komponenten unterstützen.
Secure-by-Design schafft Austauschbarkeit
Wer langfristige Updatefähigkeit anstrebt, muss sie bereits in der Architektur mitdenken. Hersteller können ihre Produkte so strukturieren, dass Entwicklungsteams einzelne Bestandteile später gezielt verändern und aktualisieren können.
Modulare Architekturen schaffen dafür eine wichtige Grundlage. Klar definierte Schnittstellen begrenzen Abhängigkeiten zwischen einzelnen Bereichen. Aktualisiert oder ersetzt ein Entwicklungsteam später einen Baustein, kann es die Auswirkungen auf andere Teile des Systems gezielt steuern. Diese Entkopplung erleichtert Wartung und Tests. Gleichzeitig reduziert sie den Umfang der Änderungen, die ein einzelnes Sicherheitsupdate im Gesamtsystem auslöst.
Bei geeigneten Systemen können beispielsweise Container-Technologien Funktionsbereiche und deren Abhängigkeiten stärker voneinander isolieren. Bei Embedded-Systemen bestimmen Hardware, verfügbare Ressourcen und Einsatzzweck, welche Form der Modularisierung den größten Mehrwert bietet.
Secure-by-Design bedeutet in diesem Zusammenhang, spätere Sicherheitsanforderungen bereits in Architekturentscheidungen einzubeziehen. So entsteht die technische Grundlage, um auf neue Schwachstellen und Veränderungen im Software-Stack flexibel reagieren zu können. Gleichzeitig braucht das Produkt einen sicheren Weg, über den Updates tatsächlich auf das Gerät gelangen.
Sichere Update-Mechanismen von Anfang an integrieren
Der Update-Mechanismus gehört genauso früh in die Planung wie andere zentrale Produktfunktionen. So wird der Updatepfad von Beginn an Bestandteil der Sicherheitsarchitektur. Je nach Produkt können geeignete Mechanismen beispielsweise Herkunft und Integrität eines Updates überprüfen.
Update- und Recovery-Mechanismen sollten dabei zusammenspielen. So schaffen Hersteller einen kontrollierten Prozess für reguläre Aktualisierungen und unerwartete Situationen. Auch hier zahlt sich eine modulare Architektur aus. Kann ein Unternehmen einzelne Komponenten unabhängig aktualisieren, kann es Sicherheitsupdates gezielt ausspielen und den Umfang notwendiger Änderungen begrenzen.
Langfristige Updatefähigkeit umfasst außerdem die Infrastruktur hinter dem Updateprozess. Zertifikate haben definierte Laufzeiten, kryptografische Verfahren entwickeln sich weiter und Backend-Systeme verändern sich. Hersteller sollten deshalb bereits beim Produktdesign berücksichtigen, wie sie diese Bestandteile über den gesamten Unterstützungszeitraum betreiben und weiterentwickeln können.
Updatefähigkeit wird zum Qualitätsmerkmal
Mit dem CRA gewinnt die langfristige Updatefähigkeit über die regulatorischen Anforderungen hinaus an Bedeutung. Kunden und Geschäftspartner werden stärker darauf achten, wie lange Hersteller ihre vernetzten Produkte zuverlässig steuern und kontinuierlich optimieren können. Ein belastbares Update-Konzept kann damit Vertrauen in die Qualität und Langlebigkeit eines Produkts stärken.
Hersteller müssen dadurch auch ihre Produktplanung anpassen. Supportzeiträume, Wartbarkeit und Weiterentwicklung gehören künftig stärker in strategische Entscheidungen rund um Entwicklung und Produktlebenszyklus. Wer diese Perspektive früh einbezieht, kann Sicherheit und Langlebigkeit zu einem festen Bestandteil seiner Produktqualität machen.
