Dependency-Track für Maschinenhersteller sinnvoll strukturieren

Maschinenhersteller müssen Software-Releases mit den tatsächlich installierten Konfigurationen ihrer ausgelieferten Maschinen verbinden. Nur dann lässt sich eine neue Schwachstelle bis zu den betroffenen Anlagen verfolgen, ohne Produktlisten und Serviceberichte manuell abzugleichen.

Bei der fiktiven Musterwerk Maschinenbau GmbH zeigt sich diese Aufgabe an der modularen Baureihe MX-400. Einige Maschinen nutzen noch das Fieldbus Gateway 4.2.1, andere wurden auf 4.2.2 aktualisiert und einzelne Geräte nach einem fehlgeschlagenen Update zurückgesetzt. Entscheidend ist die Trennung zwischen der Software Bill of Materials (SBOM) eines Releases und dem nachgewiesenen Zustand einer einzelnen Maschine.

Vom Release zur ausgelieferten Maschine

Dependency-Track beantwortet, welche Komponenten in einem Software- oder Firmware-Release enthalten sind und welche Schwachstellen dafür bekannt sind. Wenn du die Plattform zunächst einordnen möchtest, schau in unseren Artikel: Dependency-Track für die SBOM-Analyse. Welche ausgelieferten Maschinen dieses Release tatsächlich nutzen, beantwortet dagegen die Installed Base oder ein anderes führendes Konfigurationsverzeichnis.

Die benötigten Informationen liegen bei Maschinenherstellern häufig in mehreren Systemen. Das Product Lifecycle Management (PLM) kennt die Produktstruktur, das Enterprise Resource Planning (ERP) die Auslieferung, das Manufacturing Execution System (MES) den Fertigungsstand und das Service-System spätere Umbauten. Geräteabfragen oder eine IoT-Plattform liefern zusätzlich Beobachtungen aus dem Betrieb.

Ein Installed-Base-Verzeichnis führt diese Informationen über eine stabile Asset-ID zusammen. Dafür muss nicht zwangsläufig ein neues Produkt eingeführt werden. Das vorhandene Service- oder Asset-System kann weiterhin Kunde, Standort, Zuständigkeit und Betriebszustand verwalten.

Dependency-Track benötigt diese personenbezogenen und betrieblichen Daten nicht. Die Verbindung zwischen beiden Seiten entsteht durch eindeutige Referenzen auf freigegebene Releases sowie nachvollziehbare Meldungen und Beobachtungen pro Maschine.

Releases und SBOMs in Dependency-Track

Für die MX-400 Control Suite 7.6.3 und das Fieldbus Gateway 4.2.1 legt Musterwerk jeweils ein Projekt mit dieser Release-Version und einer zugehörigen SBOM in Dependency-Track an. Die SBOM des Gateway-Releases beschreibt etwa dessen Runtime 2.8.0 und weitere bekannte Abhängigkeiten. Installieren 800 Maschinen genau dieses Release, muss diese Stückliste nicht 800-mal in Dependency-Track abgelegt werden. Die Impact Analysis von Dependency-Track zeigt betroffene Projekte und Releases. Der Weg zu den konkreten Maschinen führt anschließend über die Installed Base.

Dabei sind drei Kennungen auseinanderzuhalten. 4.2.1 bezeichnet das Gateway-Release, eine spätere Korrektur seiner Komponentenangaben betrifft die Revision der SBOM, und MW-2025-0042 mit einem Serviceereignis bezeichnet den Zustand eines Assets. Ein korrigiertes SBOM-Dokument erzeugt nicht automatisch ein neues Gateway-Release. Auslieferung und Rollback erzeugen ebenfalls keine neuen Release-Versionen in Dependency-Track, sondern Einträge in der Maschinenhistorie.

Ein freigegebenes Produkt- oder Modul-Release sagt noch nichts darüber aus, ob es auf einer bestimmten Maschine läuft. Der Cyber Resilience Act verlangt die Dokumentation von Komponenten und Schwachstellen einschließlich einer maschinenlesbaren SBOM, aber nicht ein Dependency-Track-Projekt pro Seriennummer. Die BSI TR-03183-2 bietet zusätzliche Orientierung zur Erstellung von SBOMs. Sie ersetzt weder die Installed Base noch einen Nachweis der laufenden Maschinenkonfiguration.

Die Maschinenkonfiguration in der Installed Base

Die Asset-ID MW-2025-0042 bleibt über die Lebensdauer der Maschine stabil. Ihr Konfigurationseintrag verweist auf die installierten Releases und bewahrt Fertigungs-, Service- und Beobachtungsereignisse auf. Eine Maschine kann die MX-400 Control Suite 7.6.3 und das Fieldbus Gateway 4.2.1 nutzen, während eine andere Maschine derselben Baureihe bereits Gateway 4.2.2 hat. Nicht installierte, lediglich kompatible Module gehören nicht zur Konfiguration des Assets.

Das folgende verkürzte Beispiel zeigt den zuletzt beobachteten Gateway-Stand. Das Format ist ein internes Konfigurationsereignis und weder eine CycloneDX-SBOM noch ein vorgegebenes Dependency-Track-API-Format. Für weitere Komponenten benötigt das Asset-System eigene Meldungen und Nachweise.

{
  "eventId": "MW-2025-0042-gateway-2026-05-20T14:32:00Z",
  "assetId": "MW-2025-0042",
  "module": "Fieldbus Gateway",
  "release": "4.2.2",
  "source": "gateway-version-readback",
  "observedAt": "2026-05-20T14:32:00Z",
  "evidenceRef": "service-4711/gateway-readback-01"
}

Dieser Eintrag verbindet den gelesenen Gateway-Stand mit dem Asset und einer nachprüfbaren Evidenz. Die Release-Referenz verknüpft ihn mit der entsprechenden SBOM in Dependency-Track. Eine Maschine enthält das Gateway, während das Gateway von seiner Runtime abhängig ist. Deshalb wird die Maschine hier nicht als Rootkomponente einer Release-SBOM mit dependsOn auf das Gateway modelliert.

Fremdkomponenten und Datenlücken erfassen

In der MX-400 stecken neben eigener Software auch zugekaufte Steuerungen, Antriebe, ein Industrie-PC und eine Kamera mit eigener Firmware. Für solche Produkte ist nicht immer eine vollständige SBOM verfügbar. Musterwerk hält deshalb wenigstens Lieferant, Produkt- und Bestellnummer, Hardware-Revision, Firmware-Version, Quelle der Hersteller-Advisories und Support-Ende fest. Unbekannte interne Abhängigkeiten bleiben als Datenlücke sichtbar, statt stillschweigend als nicht vorhanden zu gelten.

Package URLs (purls) für Softwarepakete und passende Common Platform Enumerations (CPEs) für Betriebssysteme, Hardware oder Firmware können die Zuordnung zu bekannten Schwachstellen verbessern. Die Dependency-Track Best Practices empfehlen diese Kennungen. Eine selbst vergebene purl für ein proprietäres Gateway liefert aber nicht automatisch Treffer aus öffentlichen Datenquellen. Bei OT-Komponenten sind Herstellerkennung, Bestellnummer und präzise betroffene Firmware-Bereiche oft aussagekräftiger als ein ungenauer CPE-Treffer.

Eine Release-SBOM bleibt eine Aussage über den bekannten Komponentenbestand dieses Releases, keine vollständige Hardwareliste der Maschine. Wo Lieferanteninformationen enden, muss der Abdeckungsgrad kenntlich bleiben. CycloneDX kann mit Compositions solche Grenzen beschreiben und mit BOM-Link getrennte Dokumente verbinden. Ob der eigene Auswerteprozess diese Angaben tatsächlich nutzt, ist gesondert zu prüfen.

Gemeldeten und verifizierten Zustand trennen

Ein Serviceauftrag beschreibt den Sollzustand, ein Installationsmanifest zunächst nur einen gemeldeten Zustand. Auch eine gültige Signatur belegt nur Herkunft und Unversehrtheit der Meldung, sofern der verwendete Schlüssel vertrauenswürdig ist. Ein Hash prüft die erfassten Daten. Eine erfolgreiche Verarbeitung der Release-SBOM in Dependency-Track belegt, dass ihre Komponenten bewertet werden können. Keiner dieser Schritte weist für sich genommen nach, welche Firmware gerade auf der Steuerung läuft.

Für einen beobachteten Zustand braucht Musterwerk eine belastbare Quelle, etwa eine Geräteabfrage, einen Update-Client oder ein Engineering-Tool, das den Stand nach der Installation ausliest. Das Konfigurationsverzeichnis speichert je Komponente Quelle, Zeitpunkt und Evidenz und legt fest, welche Quellen als hinreichend verlässlich gelten. Erst wenn Identität des Geräts, Beobachtung und Zuordnung zum Release plausibel geprüft wurden, führt es diesen Stand als verifiziert. Auch dann beschreibt die Verifikation nur den beobachteten Zeitpunkt, nicht eine dauerhafte Garantie für den laufenden Zustand.

Ein Servicetechniker kann Gateway 4.2.2 als installiert melden, während die Maschine offline ist. Die Installed Base zeigt dann gemeldet, Beobachtung ausstehend und daneben den zuletzt verifizierten Stand 4.2.1 mit Prüfzeitpunkt. So verwechselt das Security-Team weder die Meldung mit einer Beobachtung noch einen alten Nachweis mit einer aktuellen Bestätigung.

Updates und Rollbacks nachvollziehen

Bei der Auslieferung erfasst die Installed Base MW-2025-0042 und die auf der Maschine gemeldeten Release-Versionen. Eine geeignete Inventarisierung bestätigt anschließend die einzelnen Stände. Für spätere Updates liegen die SBOMs der Releases 4.2.1 und 4.2.2 bereits in Dependency-Track. Das Asset-System speichert, welches Release auf dieser Maschine beobachtet wurde.

Im Mai 2026 aktualisiert ein Serviceauftrag das Gateway von 4.2.1 auf 4.2.2. Das Ereignis enthält Auftrag, Asset-ID, Zielversion und das Ergebnis der Installation. Erst ein passender Nachweis des Geräts bestätigt 4.2.2 als beobachteten Stand. Eine neue vollständige Gateway-SBOM wird für das Release 4.2.2 bereitgestellt, nicht für jede Maschine, auf der es installiert wird.

Schlägt das Update fehl und der Service stellt 4.2.1 wieder her, dokumentiert die Installed Base den Rollback als neues Ereignis und prüft auch dessen Ergebnis. Ein ausgebautes Bildverarbeitungsmodul ändert ebenfalls die Maschinenkonfiguration, nicht rückwirkend die SBOM des Modul-Releases. Aus den Ereignissen muss sich die vollständige Konfiguration zu einem Prüfzeitpunkt rekonstruieren lassen, ohne bei jedem Vorgang alle Release-SBOMs zu kopieren.

Bleibt eine Rückmeldung aus oder ist die Maschine offline, kennzeichnet das Verzeichnis den aktuellen Zustand als ungeklärt. Doppelte Manifeste werden anhand einer stabilen Ereignis-ID erkannt. Verspätete Meldungen dürfen neuere Beobachtungen nicht überschreiben. Eine ungültige Signatur, ein abweichender Hash oder eine nicht auflösbare Release-Referenz erfordern Klärung durch den zuständigen Service- oder Asset-Owner. Fehler bei der Verarbeitung einer Release-SBOM sind ein eigener Vorgang und dürfen nicht mit einer erfolgreichen Zustandsverifikation gleichgesetzt werden.

Schwachstellen bis zur Maschine verfolgen

Wird eine Schwachstelle für eine Komponente des Gateways 4.2.1 bekannt, identifiziert Dependency-Track zunächst das betroffene Release. Die Installed Base sucht anschließend nach Maschinen mit einer Referenz auf 4.2.1 und ergänzt Standort, Servicefenster und zuständige Personen. Ein Komponenten-Treffer ist dabei ein Prüfanlass, noch kein Beweis, dass die Schwachstelle im konkreten Produkt ausnutzbar ist. Konfiguration, aktivierte Funktionen, Erreichbarkeit und Informationen des Lieferanten gehören zur Bewertung.

Gerade bei zugekauften Industriekomponenten veröffentlicht der Hersteller oft genauere Versionsgrenzen und Maßnahmen als eine allgemeine Schwachstellendatenbank. Siemens ProductCERT stellt beispielsweise Advisories als Common Security Advisory Framework (CSAF) bereit und kennzeichnet auch ausdrücklich nicht betroffene Produkte. Solche Aussagen brauchen einen Abgleich mit Hersteller, Bestellnummer, Hardware-Revision und Firmware-Version. Ein pauschaler CPE- oder purl-Treffer darf eine begründete produktspezifische Prüfung nicht ersetzen.

CSAF-Feeds lassen sich derzeit nicht als native Datenquelle einer regulären Dependency-Track-Installation konfigurieren. Die Anforderung für den CSAF-Import ist noch offen. Ein Teil der Implementierung wurde vor der Freigabe von Version 5 entfernt. Eine separate Verarbeitung der Lieferanten-Advisories muss deshalb Produktkennungen abgleichen und ihre Aussagen im Security-Prozess nachvollziehbar halten. Ausgewählte, eindeutig zuordenbare Treffer können über das interne Schwachstellenverzeichnis in Dependency-Track erfasst werden. Das ist keine automatische Übernahme aller CSAF-Aussagen.

Das Security-Team prüft pro Release, ob ein Fund tatsächlich anwendbar ist, und dokumentiert die Begründung. Dependency-Track unterstützt dafür auch CycloneDX Vulnerability Exploitability Exchange (VEX), das nicht mit einem nativen CSAF-Import gleichzusetzen ist. Erst danach priorisiert die Installed Base die betroffenen Maschinen anhand ihres beobachteten Stands. Bei ungeklärtem Zustand bleibt der letzte Nachweis samt Alter sichtbar. Eine Remediation gilt erst nach dokumentierter Maßnahme und erneuter Beobachtung als bestätigt.

Mit wenigen Maschinen beginnen

Ein Pilot mit wenigen MX-400 zeigt, ob die Zuordnung im Alltag trägt. Zwei Maschinen teilen sich zunächst Gateway 4.2.1, nur eine erhält ein Update auf 4.2.2, und nach einem Rollback unterscheiden sich ihre Historien erneut. Der Test umfasst eine fehlende, verspätete oder doppelte Rückmeldung sowie einen Servicebericht ohne technische Gerätebeobachtung. Auch eine ungültige Signatur, ein abweichender Hash und eine fehlgeschlagene SBOM-Verarbeitung sollen sichtbar bleiben.

Zusätzlich bewertet das Security-Team ein Lieferanten-Advisory für ein Produkt ohne vollständige SBOM und prüft einen ausdrücklich als nicht betroffen ausgewiesenen Versionsstand. Es verfolgt den Weg von der Schwachstelle über das Release zu den Maschinen und zurück von einer Asset-ID zu ihren aktuell belegten Releases. Der Pilot ist gelungen, wenn unsichere Stände erkennbar bleiben und ein Update erst nach passendem Nachweis als abgeschlossen gilt.

Für wenige individuell gebaute Sondermaschinen kann ein Projekt pro Asset in Dependency-Track als Pilotlösung trotzdem vertretbar sein. Bei einer Serie mit vielen gleichen Releases vervielfacht dieses Modell jedoch Komponenten und Bewertungen. Eine verlässliche Installed Base und wiederverwendbare Release-SBOMs sind dann die bessere Grundlage. Zugriffsrechte, Aufbewahrung und der Aufwand für die Integration der vorhandenen Systeme müssen vor dem Ausbau geklärt werden.

Wie hältst du die Softwarestände ausgelieferter Maschinen nachvollziehbar? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.