Tackling the Challenge of Matching Product and Software Release Cycles

Autor: Annika Vogt | Thema: SBOM, Product Security, Supply Chain Risk

1. The Dual-Timeline Problem: Why Hardware and Software Don’t Ship Together

Ein Industrierouter verlässt die Fertigung mit einer bestimmten Firmware-Version. Sechs Monate später erscheint ein kritisches Sicherheitsupdate für eine eingebettete Bibliothek. Zwei Jahre danach läuft dasselbe Gerät noch immer bei Hunderten von Kunden – mit einer Softwarebasis, die sich mehrfach verändert hat, während die Hardware unverändert blieb.

Dieses Szenario ist kein Ausnahmefall, sondern der Normalzustand in der Embedded-, IoT- und Industriedomäne. Hardware-Releasezyklen bewegen sich in Monaten bis Jahren: Neue Platinen, Gehäuse oder Chipsätze erfordern aufwendige Zertifizierungen, Typprüfungen und Lieferkettenprozesse. Software hingegen folgt einem völlig anderen Rhythmus – Patches erscheinen wöchentlich, Abhängigkeiten aktualisieren sich täglich, CI/CD-Pipelines liefern kontinuierlich neue Artefakte.

Die Konsequenz: Produkt- und Softwareteams arbeiten auf parallelen Zeitachsen, die selten synchron laufen. Ein medizinisches Gerät, das alle drei Jahre eine Hardwarerevision erhält, kann in derselben Zeit Dutzende Software-Updates durchlaufen. Industrielle Steuerungen, die nach IEC 62443 zertifiziert sind, müssen jede sicherheitsrelevante Änderung dokumentieren – unabhängig davon, ob die Hardware sich verändert hat oder nicht.

2. Why This Mismatch Creates SBOM and Compliance Chaos

Das eigentliche Problem entsteht nicht aus der Tatsache unterschiedlicher Taktung allein, sondern aus dem Versagen klassischer SBOM-Prozesse, damit umzugehen.

Ein punktuell erstelltes SBOM – also ein Schnappschuss zum Zeitpunkt eines Releases – ist im Moment seiner Erstellung bereits auf dabei, zu veralten. Wird ein Softwarepaket drei Wochen nach dem Hardware-Launch aktualisiert, stimmt das SBOM nicht mehr mit dem tatsächlich ausgelieferten Zustand des Produkts überein. CVE-Mappings, die auf einer bestimmten Paketversion basieren, passen nicht mehr zur neuen Version – oder umgekehrt: Eine neue Schwachstelle betrifft eine alte Paketversion, die im Produkt verbaut bleibt, im SBOM aber längst durch eine neuere ersetzt wurde.

Für Compliance-Teams bedeutet das konkret: Nachweise für CRA (Cyber Resilience Act), IEC 62443 oder die BSI TR 03183-2 driften auseinander. Ein Audit-Dokument, das auf dem SBOM zum Zeitpunkt der CE-Kennzeichnung basiert, bildet den tatsächlichen Produktzustand im Feld nur bedingt ab (s.a. https://www.eacg.de/en/podcast/s03-fix-is-available/). Im schlimmsten Fall führt das zu Haftungsrisiken, Rückrufaktionen oder dem Verlust von Zulassungen.

Das Kernproblem: SBOMs werden als statische Dokumente behandelt, obwohl sie dynamische Realitäten beschreiben müssen.

3. Core Concepts: What a Product-Level SBOM Actually Needs to Track

Ein produktbezogenes SBOM-Management muss mehr leisten als die Auflistung von Paketen und Versionen. Es braucht mehrere Dimensionen gleichzeitig:

Versionierung über Softwarekomponenten hinweg: Jede Softwarekomponente muss mit ihrer exakten Version und ihrem Zeitstempel einer bestimmten Produktkonfiguration zugeordnet sein – nicht abstrakt, sondern konkret für jede ausgelieferte Hardware-Revision.
CVE-Mapping auf Produktebene: Eine Schwachstelle darf nicht nur einer Bibliothek zugeordnet werden, sondern muss konkret mit der betroffenen Produktkonfiguration, dem Auslieferungszeitraum und dem aktuellen Mitigationsstatus verknüpft sein.
Lifecycle-Tracking über Hardware-Revisionen: Wenn Hardware-Revision 1.2 durch 1.3 abgelöst wird, müssen beide SBOMs parallel gepflegt und historisch nachvollziehbar bleiben.
Normkonformität als kontinuierlicher Zustand: Standards wie IEC 62443-2-4, der EU Cyber Resilience Act und die BSI TR 03183-2 in ihrer aktuellen Fassung verlangen nicht nur einen Nachweis zum Zeitpunkt des Inverkehrbringens, sondern eine fortlaufende Dokumentation des Sicherheitszustands über den gesamten Produktlebenszyklus.

Diese Anforderungen lassen sich mit traditionellen Werkzeugen – Tabellen, Git-Snapshots, manuell gepflegte Dokumente – nicht konsistent erfüllen.

4. How TrustSource’s Product Package Bridges Both Timelines

TrustSource adressiert dieses Problem mit einem produktzentrierten SBOM-Ansatz, der SBOMs nicht als einmalige Artefakte, sondern als lebendige, versionierte Objekte behandelt.

Das TrustSource Product Package erlaubt es, Produkte als eigenständige Entitäten zu modellieren, denen Softwarekomponenten in bestimmten Versionen zugeordnet werden. Wenn eine Software-Komponente aktualisiert wird, wird nicht das gesamte Produkt-SBOM überschrieben, sondern die neue Softwareversion wird dem Produkt zugeordnet, während die alte Version historisch erhalten bleibt.

CVE-Mappings werden automatisch aktualisiert und bleiben immer an die spezifische Produktkonfiguration gebunden. Wenn eine neue Schwachstelle für eine Bibliotheksversion gemeldet wird, die in Produktrevision 1.2, aber nicht in 1.3 verbaut ist, zeigt TrustSource genau diese Differenzierung – ohne manuellen Abgleich.

Der Compliance-Status wird nicht als einmaliges Testat gespeichert, sondern kontinuierlich über beide Release-Zyklen hinweg nachvollzogen. Teams können zu jedem Zeitpunkt abfragen: Welche CVEs sind für welche Produktkonfiguration offen? Welche Mitigationen wurden dokumentiert? Welcher Compliance-Stand gilt für welche Hardware-Revision?

5. Workflow Walkthrough: From Software Release to Product SBOM Update

Ein typischer Workflow mit TrustSource sieht in der Praxis so aus:

Software-Patch wird entwickelt: Im CI/CD-System wird ein neues Release einer Firmware-Komponente gebaut. TrustSource generiert automatisch ein aktualisiertes SBOM für diese Komponente.
Produkt-Zuordnung erfolgt: Das neue Software-Release wird einer oder mehreren Produktkonfigurationen zugeordnet. TrustSource aktualisiert das jeweilige Produkt-SBOM und markiert die geänderten Komponenten.
CVE-Auswirkungsanalyse wird ausgeführt: TrustSource prüft automatisch, welche bekannten Schwachstellen durch das neue Release behoben oder neu eingeführt werden. Die Ergebnisse werden produktspezifisch dargestellt.
Differenzanalyse über Produktvarianten: Teams sehen sofort, welche Produktvarianten vom Update profitieren und welche noch auf der alten Softwareversion laufen.
PLM-Integration: Über Schnittstellen zu PLM-Systemen kann der aktualisierte SBOM-Status in bestehende Produktlebenszyklusdokumentationen zurückgespielt werden.

6. Handling CVE Lifecycles Across Frozen Hardware Configurations

Die härteste Nuss in diesem Kontext: Hardware-Konfigurationen werden eingefroren, Schwachstellen aber nicht.

Ein Gerät, das 2021 mit einer bestimmten Prozessorarchitektur und Firmware ausgeliefert wurde, kann 2025 von einer neu entdeckten Schwachstelle betroffen sein – ohne dass es eine realistische Möglichkeit gibt, die Hardware zu ändern. Die Frage ist dann nicht mehr, wie man die Schwachstelle behebt, sondern wie man sie dokumentiert, bewertet und die Risikoakzeptanz nachweisbar macht.

—- Ergänzend empfiehlt sich der Einsatz des MITRE EMB3D Framework als Instrument zur strukturierten Bedrohungsmodellierung für eingebettete Systeme. EMB3D hilft dabei, hardwarespezifische Angriffsvektoren zu identifizieren, die über klassische CVE-Listen hinausgehen. Die EACG bietet dazu eine dedizierte Schulung an: EACG Academy – EMB3D Kurs. —-

TrustSource ermöglicht genau das: Für jede CVE, die eine eingefrorene Produktkonfiguration betrifft, können Teams den Risikoakzeptanzprozess dokumentieren, Mitigationsmaßnahmen (z. B. Netzwerksegmentierung, zusätzliche Authentifizierung) hinterlegen und den Bearbeitungsstatus für Audits und Behördenanfragen nachweisbar halten.

Dieser Ansatz entspricht dem, was CRA und IEC 62443 unter Vulnerability Disclosure und Post-Market Surveillance fordern: keine Verleugnung bekannter Risiken, sondern transparente, dokumentierte und nachvollziehbare Handhabung.

7. Getting Started: Practical Steps for Product Security Teams

Wer diesen Ansatz einführen möchte, sollte pragmatisch vorgehen:

Schritt 1: Bestandsprodukte priorisieren. Nicht alle Produkte gleichzeitig angehen. Beginnen mit Produkten, die den höchsten Risikograd haben – entweder durch bekannte CVEs, kritische Einsatzumgebungen oder bevorstehende Audits.

Schritt 2: SBOM-Taxonomie festlegen. Bevor SBOMs importiert oder generiert werden, muss klar sein, wie Produkte, Hardware-Revisionen und Software-Releases strukturiert und benannt werden. Eine konsistente Taxonomie ist die Grundlage für alle späteren Automatisierungen.

Schritt 3: Entwicklungs- und Produktteams abstimmen. SBOM-Management ist keine reine Entwickleraufgabe. Produktmanager, Compliance-Verantwortliche und Security-Teams müssen gemeinsam definieren, welche Informationen wann und wie dokumentiert werden.

Schritt 4: TrustSource Product Package einbinden. Mit dem Product Package lassen sich Produkte schnell anlegen, Software-Releases zuordnen und erste CVE-Auswertungen durchführen – ohne monatelange Implementierungsprojekte.

Schritt 5: CI/CD-Integration aktivieren. Der größte Effizienzgewinn entsteht, wenn SBOM-Updates automatisch aus dem Build-Prozess heraus ausgelöst werden. TrustSource bietet hierfür Integrationen für gängige CI/CD-Systeme.

Fazit

Die Entkopplung von Hardware- und Software-Releasezyklen ist kein unlösbares Organisations- oder Koordinationsproblem. Es ist eine strukturelle Realität, die ein strukturelles Werkzeug erfordert.

Drei Kernergebnisse:

Statische SBOMs versagen in Produktumgebungen mit unterschiedlichen Release-Taktungen. Nur ein lebendiges, versioniertes Produkt-SBOM bildet den tatsächlichen Sicherheitszustand zuverlässig ab.
CVE-Lifecycle-Management muss produktspezifisch und nicht nur komponentenspezifisch erfolgen – insbesondere für eingefrierte Hardware-Konfigurationen, bei denen technische Fixes nicht möglich sind.
TrustSource’s Product Package bietet einen praxistauglichen Ansatz, der beide Zeitachsen zusammenführt, Compliance-Nachweise kontinuierlich pflegt und Audit-Anforderungen nach CRA, IEC 62443 und BSI TR 03183-2 erfüllt.