Links das in Schutzfolie gehüllte Gestell einer fast fertigen Maschine, rechts kniet ein Automatisierungstechniker mit Taschenlampe vor dem offenen Schaltschrank, eine Kollegin in gelber Warnweste erfasst die Module auf dem Tablet

// Der Weg: Problem → Funktionen → Adapter → Beispiel → Grenzen → frühe Nutzung

PLC SBOM Builder: eine SBOM für die ganze Maschine

SBOM-Generatoren aus der IT lesen Paketmanifeste, SPS-Projekte haben keine. Der SBOM Builder liest Geräte, Firmware-Stände und Bibliotheken über Adapter aus TIA Portal, CODESYS, TwinCAT und Studio 5000 und schreibt daraus eine CycloneDX-Datei für die ganze Maschine, in jedem Build neu.

Pilot anfragen Whitepaper zum SBOM Builder

30 Minuten · unverbindlich · kein Vertriebsgespräch

PROTOTYP 0.1.0 · CYCLONEDX 1.6 · BSI TR-03183-2 · MEHRERE HERSTELLER JE MASCHINE

// 01Kurz erklärt

Was ist der PLC SBOM Builder?

Der PLC SBOM Builder erzeugt die SBOM einer Maschine aus ihren SPS-Projekten, auch wenn darin Steuerungen mehrerer Hersteller stecken.

Der Cyber Resilience Act verlangt von Herstellern eine SBOM in einem gängigen, maschinenlesbaren Format, mindestens für die Top-Level-Abhängigkeiten; vollständig gilt er ab dem 11. Dezember 2027. Je Engineering-Umgebung liest ein Adapter die Engineering-Daten aus, der SBOM Builder führt sie mit den SBOMs der Komponentenhersteller zu einer Datei zusammen.

Auf einen Blick

Art: Kommandozeilenwerkzeug für Windows und Linux, Aufruf aus der Pipeline
Format: CycloneDX 1.6 als JSON. SPDX 3.0.1, das die TR ebenfalls zulässt, ist für später vorgesehen
Prüfung: Schema CycloneDX 1.6 und Pflichtfelder nach BSI TR-03183-2
Adapter: Siemens TIA Portal (AML-Export V17–V21, Openness V21), CODESYS V3.5, Beckhoff TwinCAT 3, Rockwell Studio 5000, B&R Automation Studio 6 (geplant)
Quellen: SPS-Projekte, Hersteller-SBOMs, Teil-SBOMs aus Syft oder cdxgen, Ist-Stände aus dem Feld
Status: Prototyp 0.1.0, Stand 01.11.2026: SBOM je Maschine, Prüfung, Bericht, Feldabgleich, Kennungsprüfung und Beispiel-Jenkinsfile laufen, dazu die Adapter für CODESYS V3.5, Studio 5000, TwinCAT 3 und den AML-Export aus TIA Portal. Es fehlt TIA Portal Openness. Frühe Nutzung mit ausgewählten Teams

So soll es aussehen · Entwürfe der Oberfläche

AI
/01 Lauf in der Pipeline
Ein Aufruf von plc-sbom build in der Pipeline liest beide Stationen aus, nimmt die Hersteller-SBOMs dazu und prüft die fertige Datei. Zwei Firmware-Stände ohne Hash stehen als Hinweis da, nicht als leeres Feld.
AI
/02 Prüfbericht
Neben der JSON-Datei ein Bericht zum Lesen: die Maschine als Baum, je Komponente Kennung und Pflichtfelder. Lücken sind auf einen Blick zu sehen.
AI
/03 Abgleich mit dem Feld
Liegt der Ist-Stand aus der Inbetriebnahme vor, steht er neben der SBOM. Bei drei von 34 Geräten läuft im Feld eine neuere Firmware als im Projekt.

Entwürfe, mit KI erzeugt, keine Bildschirmfotos. PLC SBOM Builder ist in Entwicklung; Namen und Nummern stammen aus dem Beispiel in Abschnitt 05. Ein Klick auf ein Bild öffnet es in voller Größe.

Aufbau · Komponenten im Überblick

Wie ist der PLC SBOM Builder aufgebaut?

Aus einem gemeinsamen Kern, je Engineering-Umgebung einem Adapter und weiteren Eingängen für Hersteller-SBOMs und Ist-Stände. Der Kern führt alles zu einer CycloneDX-Datei je Maschine zusammen und prüft sie, bevor der Build weiterläuft.

Build-Agent · Windows oder Linux · Stufe der Pipeline

Umgebung
Siemens TIA Portal V17–V21
AML aus dem CAx-Export, ab V21 auch TIA Portal Openness
adapter: tia-aml · tia-portal
Geräte, Artikelnummern und Firmware-Stände; über Openness dazu Bibliothekstypen und geschützte Bausteine
stand: AML läuft, Openness folgt
Umgebung
CODESYS V3.5
PLCopen-XML-Export und Gerätebeschreibungen
adapter: codesys
Geräte mit Hersteller und Bestellnummer, Bibliotheken mit Version, soweit der Export sie festlegt
stand: läuft im Prototyp
Umgebung
Beckhoff TwinCAT 3
Projektdateien, ohne die Umgebung zu starten
adapter: twincat
EtherCAT-Teilnehmer mit Herstellerkennung und Revision, dazu Bibliotheken; die Firmware der Klemmen kommt aus dem Ist-Stand
stand: läuft im Prototyp
Umgebung
Rockwell Studio 5000
L5X-Export
adapter: studio5000
Steuerung und Module mit Katalognummer, Revision und Kodierung, dazu Add-On Instructions
stand: läuft im Prototyp
Umgebung
B&R Automation Studio 6
Projektdateien, ohne die Umgebung zu starten
adapter: automation-studio
Module mit B&R-Bestellnummer, Version der Automation Runtime und der mapp-Pakete je Konfiguration
stand: geplant

+ adapter: eigener · Weitere Umgebungen über eigene Adapter, etwa auf Basis von PLCopen XML

Weitere Quelle
Repository
Anwenderprogramm mit Git-Commit, Hersteller-SBOMs als *.cdx.json, GSDML-Dateien und CODESYS-Gerätebeschreibungen, Ihre Zuordnung von Bestellnummer zu CPE
Weitere Quelle
Teil-SBOMs
Aus Syft oder cdxgen, etwa für Webseiten und Hochsprachen-Anteile
Weitere Quelle
Ist-Stand
Ausgelesene Firmware-Stände aus der Inbetriebnahme, als eigene Liste oder als Antworten der Web-API einer S7-1500

plc-sbom

Gemeinsamer Kern

Kommandozeilenwerkzeug plc-sbom, aufgerufen als Stufe der Pipeline

/01
Inventar
Geräte mit Bestellnummer und Firmware-Stand, Anwenderprogramm und Bibliotheken.
/02
Kennungen
Hersteller, Bestellnummer und Firmware als Properties, CPE aus Ihrer Tabelle, sonst eine bom-ref.
/03
Zusammenführen
Maschine, Station, Komponente: alle Adapter und SBOMs in einer Datei.
/04
Prüfen und abgleichen
Schema CycloneDX 1.6 und Pflichtfelder der TR-03183-2, ein Fehler beendet den Build. Abweichungen zum Ist-Stand als Liste.

ausgabe

sbom-maschine.cdx.json

CycloneDX 1.6 als JSON, in jedem Build neu, dazu der Prüfbericht zum Lesen

Ihre Infrastruktur

Dependency-Track (optional)
Überwacht die SBOM auf Schwachstellen über CPE und Package URL, angebunden über das Jenkins-Plugin
Build-Archiv
Die SBOM jedes Release liegt am Build, durchsuchbar nach der Bestellnummer aus einem Advisory

Komponentenübersicht nach dem Entwicklungsstand vom 01.11.2026 (Prototyp 0.1.0). Alle Bausteine laufen bis auf TIA Portal Openness und den geplanten Adapter für B&R Automation Studio. Namen und Schnittstellen können sich bis zur ersten Version ändern. Schwachstellen bewertet der SBOM Builder nicht selbst, das übernimmt ein Überwachungssystem.

// 02Ausgangslage

Warum entsteht die SBOM einer Maschine nicht von selbst?

Weil ihre Bestandteile an verschiedenen Orten liegen. Geräte, Artikelnummern und projektierte Firmware stehen im Engineering-Projekt, bei einer gemischten Maschine in mehreren Projekten verschiedener Hersteller. Was in der Firmware steckt, weiß nur der Komponentenhersteller. Anwenderprogramm und eigene Bibliotheken liegen im Repository.

Für Steuerungs-Hardware gibt es keine Package URLs, und CPEs führt die NVD nur je Gerätefamilie, nicht je Bestellnummer. Seit April 2026 ergänzt sie die meisten neuen Schwachstellen zudem nicht mehr um CPEs. Tragfähiger ist die Bestellnummer: Siemens nennt sie in seinen CSAF-Advisories zu jedem betroffenen Gerät. Wer die SBOM von Hand pflegt, schreibt Bestellnummer, Firmware-Stand und Kennung für jede Baugruppe einzeln.

Und das Projekt ist nicht die Anlage. Eine Steuerung läuft auch mit neuerer Firmware als der im Projekt hinterlegten. Eine SBOM, die nur das Projekt kennt, weist dann den falschen Stand aus.

Ein Kunde fragt nach einer Schwachstellenmeldung, welche seiner Maschinen die betroffene Komponente enthalten. Die Antwort steht in zwei Excel-Listen, eine für die Siemens-Steuerungen und eine für die Beckhoff-Zellen, beide zuletzt bei der Abnahme vor zwei Jahren gepflegt.

// 03Funktionen

Was soll der SBOM Builder
können?

Der geplante Funktionsumfang. PLC SBOM Builder ist in Entwicklung, Einzelheiten können sich bis zur ersten Version ändern. Was davon heute schon läuft, steht am Ende des Abschnitts.

/01
Hardware- und Firmware-Inventar
Jedes Gerät mit Bestellnummer und Firmware, soweit die Quelle sie führt.
Über den Adapter liest der SBOM Builder alle Geräte aus dem Projekt: Steuerung, Kommunikations- und E/A-Module, Panels, Antriebe und Feldgeräte, jeweils mit Artikel- oder Katalognummer und dem projektierten Firmware-Stand. Bei EtherCAT-Klemmen und bei Geräten, die über eine GSDML-Datei eingebunden sind, steht keine Firmware im Projekt. Dort vermerkt die SBOM die Lücke, bis der Ist-Stand aus der Inbetriebnahme vorliegt. Ein TwinCAT-Projekt nennt auch keine Bestellnummer, nur Herstellerkennung, Produktcode und Revision. Geräte aus einer GSDML-Datei bekommen die Bestellnummer aus dieser Datei, so genau, wie ihr Hersteller sie dort einträgt; manche GSDML nennt nur ein Muster für mehrere Artikel, und die SBOM kennzeichnet es so.
/02
Software-Inventar
Anwenderprogramm, Bibliotheken, Zugekauftes.
Das Anwenderprogramm geht mit Release-Kennung und Git-Commit in die SBOM ein, Bibliotheken mit Hersteller und Version. Steht eine Version im Projekt nicht fest, etwa bei einem CODESYS-Platzhalter ohne Umleitung, schreibt der SBOM Builder keine geratene Version, sondern vermerkt die Lücke. Geschützte Bausteine Dritter führt die SBOM mit Lieferant und Version, soweit sie bekannt sind; bei TIA Portal liest sie nur der Weg über Openness.
/03
Kennungen und Pflichtfelder
Bestellnummer zuerst, CPE wo vorhanden, Lücken sichtbar.
Jede Komponente trägt Hersteller, Bestellnummer und Firmware-Version als Properties in Ihrem Namespace; über diese Angaben lassen sich die CSAF-Advisories der Hersteller zuordnen. Die Advisories von Siemens und die OT-Advisories der CISA nennen Bestellnummern, aber keine CPE. Eine CPE kommt deshalb nur als Ergänzung aus einer Zuordnungstabelle dazu, die Sie pflegen, Komponenten ohne CPE bekommen eine eindeutige bom-ref. Wie viele Komponenten sich in den Advisories finden, misst plc-sbom ids. Fehlt für Hersteller-Firmware ein Hash, vermerkt die SBOM das ausdrücklich, statt das Feld leer zu lassen.
/04
Eine Maschine, eine SBOM
Adapter, Hersteller-SBOMs und Teil-SBOMs in einer Datei.
Die Ergebnisse mehrerer Adapter, die SBOMs der Komponentenhersteller und Teil-SBOMs für Webseiten oder Hochsprachen-Anteile, die Syft oder cdxgen erzeugt haben, führt der SBOM Builder hierarchisch zusammen: Maschine, Station, Komponente. Eine Hersteller-SBOM hängt er unter die passende Firmware, wenn sie dieselbe CPE nennt oder Hersteller, Bestellnummer und Version führt; wie Steuerungshersteller das einmal schreiben, ist offen, weil bisher keiner SBOMs je Produkt veröffentlicht. Teil-SBOMs aus Syft oder cdxgen erfüllen die TR meist nicht ganz. Er übernimmt sie unverändert und vermerkt die fehlenden Pflichtfelder; für einen Release-Build ergänzen Sie sie beim Erzeugen.
/05
Validieren und mit dem Feld abgleichen
Erst geprüft, dann archiviert.
Die fertige Datei prüft das Werkzeug gegen das Schema CycloneDX 1.6 und die Pflichtfelder der TR-03183-2; ein Fehler beendet den Build. Liegen ausgelesene Ist-Stände vor, etwa aus der Inbetriebnahme, gleicht es sie mit der SBOM ab, meldet jede Abweichung und schreibt auf Wunsch die SBOM dieser einen Maschine mit ihrer Seriennummer und den Firmware-Ständen aus dem Feld.

Entwicklungsstand · 01.11.2026 · Version 0.1.0

Was läuft heute schon?

Alles bis auf TIA Portal Openness und den neu geplanten Adapter für B&R Automation Studio. plc-sbom build erzeugt aus Projekten von CODESYS V3.5, Studio 5000, TwinCAT 3 und dem AML-Export aus TIA Portal die SBOM einer ganzen Maschine, prüft sie und schreibt den Prüfbericht. Abgleich mit dem Feld und Kennungsprüfung laufen ebenfalls, und ein Beispiel-Jenkinsfile bindet das Werkzeug in die Pipeline ein. Es fehlt der Weg über Openness.

Läuft im Prototyp
Eine SBOM je Maschine
plc-sbom build --config machine.yml liest alle Stationen über ihre Adapter, hängt Hersteller- und Teil-SBOMs ein und schreibt eine Datei, das Anwenderprogramm jeder Station mit Hash über die Quellen. Gleiche Eingabe ergibt Byte für Byte dieselbe Datei, unter Linux und Windows. Belegt an einer Beispielmaschine mit drei Stationen aus CODESYS, TIA Portal und TwinCAT.
Läuft im Prototyp
Prüfung gegen Schema und TR
Jede SBOM wird gegen CycloneDX 1.6 und die Regeln der BSI TR-03183-2 v2.1.0 geprüft, im Build und einzeln mit plc-sbom validate. Die Ergebnisdatei wertet die Pipeline aus. Das freie Werkzeug sbomqs prüft dieselben Dateien in jedem Lauf gegen, bisher ohne Abweichung.
Läuft im Prototyp
Adapter für vier Umgebungen
CODESYS V3.5 über den PLCopen-XML-Export und die Gerätebeschreibungen, Studio 5000 über L5X, TwinCAT 3 über die Projektdateien, TIA Portal V17 bis V21 über den AML-Export mit den GSDML-Dateien. Getestet an echten Exporten aus öffentlichen Projekten.
Läuft im Prototyp
Prüfbericht
HTML oder Markdown neben der SBOM: die Maschine als Baum, die Komponenten je Station, jede Lücke mit dem, was sie schließt, und ein Anhang mit der Hardware ohne eigene Firmware. Den Anhang schreibt der Build; plc-sbom report erzeugt den Bericht auch zu einer fertigen SBOM, dann ohne ihn.
Läuft im Prototyp
Abgleich mit dem Feld
plc-sbom compare liest den Ist-Stand einer Maschine, als eigene Liste oder als Antworten der Web-API einer S7-1500, und endet bei jeder Abweichung mit Fehler. Auf Wunsch entstehen die SBOM dieser Maschine mit ihrer Seriennummer und eine CSV-Datei für Excel.
Läuft im Prototyp
Kennungsprüfung gegen CSAF
plc-sbom ids zählt, wie viele Komponenten sich über Bestellnummer oder CPE in CSAF-Advisories finden. Gegen sechs Advisories von Siemens trägt die Bestellnummer; eine CPE nennt keines davon.
Läuft im Prototyp
Beispiel-Pipeline und Pakete
Ein Jenkinsfile mit den Stufen SBOM, Archiv und optional Dependency-Track. Ein Entwicklungs-Build mit Warnungen wird instabil, ein Build auf einem Tag prüft streng als Release und hält bei jeder Lücke an. Ergebnisdatei und Bericht werden auch bei einem Fehlschlag archiviert. Getestet in einem Jenkins unter Linux. Pakete für Windows und Linux brauchen keine installierte .NET-Laufzeit und enthalten die SBOM des Werkzeugs selbst, mit 182 Komponenten, die die eigene Prüfung im Release-Modus besteht.
Als Nächstes
TIA Portal über Openness
Der Weg über TIA Portal Openness V21 auf einem Windows-Agenten, für Bibliothekstypen und geschützte Bausteine. Im Jenkinsfile ist die Stufe für den AML-Export dafür schon vorgesehen.
Danach
Adapter für B&R Automation Studio
Ein fünfter Adapter für Projekte aus Automation Studio 6: Module aus Hardware.hw, die Version der Automation Runtime aus Cpu.pkg und die mapp-Pakete aus der Projektdatei, ohne Automation Studio zu starten.

Stand des Prototyps vom 01.11.2026. Reihenfolge und Umfang können sich bis zur ersten Version ändern.

// 04Adapter

Welche Hersteller unterstützt der SBOM Builder?

Adapter für fünf Engineering-Umgebungen, für TIA Portal auf zwei Wegen. Bedienung und Regeln bleiben gleich, der Adapter übernimmt, was die jeweilige Umgebung anders macht. Im Prototyp laufen CODESYS V3.5, Studio 5000, TwinCAT 3 und der AML-Export aus TIA Portal; TIA Portal Openness folgt als Nächstes, danach B&R Automation Studio. Weitere Umgebungen lassen sich über eigene Adapter anbinden.

Umgebung	Was der Adapter tut
Siemens TIA Portal V17–V21	Zwei Wege. Der AML-Export aus V17 bis V21 läuft auf jedem Build-Agenten ohne TIA-Installation und liefert Geräte, Artikelnummern und Firmware-Stände. Bibliotheken und geschützte Bausteine stehen darin nicht, und Geräte aus einer GSDML-Datei bekommen ihre Bestellnummer erst aus dieser Datei im Repository. Weil Bibliotheken im Export fehlen und Geräte wie Stromversorgungen kein Firmware-Attribut haben, erklären Sie beides beim AML-Weg in machine.yml; sonst bleibt es bei Warnungen, und ein Release-Build hält an. Über TIA Portal Openness V21 auf einem Windows-Agenten kommen Bibliothekstypen wie die LGF mit Typversion und die geschützten Bausteine dazu.AML-Export läuft im Prototyp, Openness folgt als Nächstes
CODESYS V3.5	Liest Geräte und Bibliotheken aus dem PLCopen-XML-Export von CODESYS V3.5, Hersteller und Bestellnummer der Geräte aus deren Gerätebeschreibungen. Bei einem Bibliotheks-Platzhalter ohne Umleitung nennt der Export nur die Standardauflösung, nicht die Version, die die Gerätebeschreibung festlegt. Solche Bibliotheken meldet der SBOM Builder als nicht aufgelöst; wer den Platzhalter im Projekt umleitet, bekommt die feste Version.Läuft im Prototyp
Beckhoff TwinCAT 3	Liest die EtherCAT-Teilnehmer aus der .tsproj und die Bibliotheken aus der .plcproj, ohne die Umgebung starten zu müssen. Das Projekt nennt je Teilnehmer Herstellerkennung, Produktcode und Revision, aber weder Bestellnummer noch Firmware; beides vermerkt die SBOM als Lücke, die Firmware kommt aus dem Ist-Stand. Bibliotheks-Platzhalter behandelt er wie bei CODESYS. PROFINET-Geräte im TwinCAT-Projekt meldet er, liest sie aber noch nicht.Läuft im Prototyp
Rockwell Studio 5000	Liest Steuerung und Module mit Katalognummer, Revision und elektronischer Kodierung sowie Add-On Instructions aus dem L5X-Export. Ist die Kodierung eines Moduls ausgeschaltet, meldet er das, weil im Feld dann auch ein anderes Modul stecken kann. IP-Adressen liest er nicht.Läuft im Prototyp
B&R Automation Studio 6	Liest die Projektdateien, ohne Automation Studio zu starten: je Konfiguration die Module aus Hardware.hw, deren Typ der B&R-Bestellnummer entspricht, aus Cpu.pkg Steuerung und Version der Automation Runtime, aus der Projektdatei die Versionen der mapp-Pakete wie mapp Motion oder mapp Safety. Systembibliotheken tragen in Automation Studio 6 keine eigene Version; die SBOM vermerkt das als Lücke, statt eine Version zu raten. Die Cyber-Security-Advisories von B&R im CSAF-Format nennen Produkte mit Versionsbereichen, etwa die Automation Runtime vor einer bestimmten Version, aber keine Bestellnummern. Zugeordnet wird deshalb über Produktname und Version.Geplant, im Prototyp noch nicht umgesetzt

// 05Beispiel

Wie sieht die SBOM einer gemischten Maschine aus?

Ein stark verkürzter Entwurf für eine Maschine mit einer Siemens-Steuerung und einer Beckhoff-Zelle. Aufbau und Property-Namen folgen dem Prototyp, auch die Runtime ohne Version, weil TwinCAT sie im Projekt nicht führt; CPE, Bestellnummer und Versionen sind Platzhalter, der Namespace firma: steht für Ihren eigenen.

Bei der nächsten Schwachstellenmeldung sucht niemand in Excel-Listen. Die SBOM jedes Release liegt am Build, für alle Steuerungen der Maschine, und die Bestellnummer aus dem Advisory des Herstellers findet sich mit einer Suche über alle SBOMs.

sbom-maschine.cdx.json

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "tools": { "components": [
      { "type": "application", "name": "PLC SBOM Builder" } ] },
    "component": { "type": "device", "name": "Maschine XY", "version": "R2026.10" }
  },
  "components": [
    { "bom-ref": "plc1-fw", "type": "firmware",
      "supplier": { "name": "Siemens AG" },
      "name": "SIMATIC CPU-Firmware", "version": "x.y.z",
      "cpe": "cpe:2.3:o:siemens:<cpu-typ>_firmware:x.y.z:*:*:*:*:*:*:*",
      "properties": [ { "name": "firma:device:orderNumber", "value": "6ES7xxx-xxxxx-xxxx" },
                      { "name": "firma:adapter", "value": "tia-aml" } ] },
    { "bom-ref": "plc1-app", "type": "application",
      "name": "Station PLC_1, Anwenderprogramm", "version": "R2026.10 (git a1b2c3d)" },
    { "bom-ref": "zelle-rt", "type": "application",
      "supplier": { "name": "Beckhoff Automation" },
      "name": "TwinCAT 3 Runtime",
      "properties": [ { "name": "firma:adapter", "value": "twincat" } ] },
    { "bom-ref": "zelle-app", "type": "application",
      "name": "Roboterzelle, Anwenderprogramm", "version": "R2026.10 (git a1b2c3d)" }
  ],
  "dependencies": [
    { "ref": "plc1-app", "dependsOn": [ "plc1-fw" ] },
    { "ref": "zelle-app", "dependsOn": [ "zelle-rt" ] }
  ]
}

Entwurf · Befehle, Bezeichnungen und Ausgabe können sich bis zur ersten Version ändern.

// 06Grenzen

Was der SBOM Builder
nicht tut

/01
Der SBOM Builder bewertet keine Schwachstellen. Das übernimmt ein Überwachungssystem. Dependency-Track etwa prüft die SBOM über CPE und Package URL, die CSAF-Advisories der Hersteller liest es bisher nicht.
/02
Er schreibt keine VEX-Bewertungen. Ob eine Schwachstelle in Ihrer Maschine ausnutzbar ist, entscheiden Sie, und das gehört in ein eigenes VEX-Dokument.
/03
Er kann keine Hersteller-SBOMs ersetzen. Die fordern Sie bei den Komponentenherstellern an.
/04
Er liest die Anlage nicht selbst aus. Den Ist-Stand liefern die Diagnosewerkzeuge der Hersteller, bei Siemens etwa PRONETA oder der Webserver der CPU.
/05
Eine SBOM allein erfüllt den Cyber Resilience Act nicht. Schwachstellenüberwachung und Meldewege gehören dazu.

// 07Voraussetzungen

Was braucht der SBOM Builder?

Build-Agent: Für Exportdateien wie L5X, AML, PLCopen XML oder die TwinCAT-Projektdateien jeder Agent unter Windows oder Linux. Für TIA Portal Openness ein Windows-Agent mit TIA Portal V21 und denselben Gerätebeschreibungen wie die Arbeitsplätze (HSP, GSDML)
Lizenzen: Engineering-Lizenz der jeweiligen Umgebung, soweit der Adapter sie zum Lesen braucht
Repository: Hersteller-SBOMs als *.cdx.json neben den Projektquellen, dazu die Gerätebeschreibungen der eingebundenen Geräte: GSDML-Dateien für den AML-Export aus TIA Portal, *.devdesc.xml für CODESYS. Ohne sie fehlen Hersteller und Bestellnummer, die SBOM vermerkt die Lücke
Maschine: Eine Datei machine.yml im Repository: Stationen mit Adapter und Pfad, Hersteller- und Teil-SBOMs, Kontakt für die SBOM, Kontakte und Lizenzen der Hersteller, optional die Tabelle von Bestellnummer zu CPE. Beim AML-Export aus TIA Portal zusätzlich die Bibliotheken je Station und die Geräte ohne eigene Firmware, etwa Stromversorgungen
Weiterverarbeitung: Optional Dependency-Track mit dem Jenkins-Plugin

Titelseite des Comquent-Whitepapers „Eine SBOM für die ganze Maschine“

Whitepaper · 27 Seiten · PDF · November 2026

Wie der SBOM Builder arbeitet, auf 27 Seiten.

Diese Seite zeigt, was der SBOM Builder kann. Das Whitepaper erklärt, wie er es macht: was die Adapter aus TIA Portal, CODESYS, TwinCAT und Studio 5000 lesen und was in den Projekten fehlt, wie die SBOM aufgebaut ist und wie sie in Jenkins als Quality Gate läuft. Ein eigenes Kapitel fasst zusammen, was der Prototyp an öffentlichen Projektdateien gezeigt hat.

/01Was Cyber Resilience Act, Maschinenverordnung und BSI TR-03183-2 von der SBOM einer Maschine verlangen, mit den Fristen bis Dezember 2027
/02Was die Adapter je Engineering-Umgebung lesen, die zwei Wege für TIA Portal und welche Angaben in den Projekten fehlen
/03Aufbau der SBOM, Kennungen über Bestellnummer und CPE, sichtbar vermerkte Lücken und die Pflichtfelder der TR-03183-2
/04Aufruf in der Pipeline, Exit-Codes als Quality Gate, Jenkinsfile, Prüfbericht und Abgleich mit dem Feld
/05Was der Prototyp gezeigt hat, eine Einführung in Stufen und typische Fehler

Whitepaper anfordern

Kostenlos · per E-Mail · DSGVO-konform

// 08Einordnung

Wo steht der SBOM Builder
in der Kette?

Die vier Werkzeuge bauen aufeinander auf: versionieren, bauen und testen, nachweisen, mit KI entwickeln. Jedes läuft auch allein, in Ihrer vorhandenen Pipeline. Die ganze Strecke bis zur Anlage deckt die Plattform IndustrialFlow ab.

01 · Versionieren
PLC Git Bridge
02 · Bauen und testen
PLC Build Tool
03 · Nachweisen
PLC SBOM Builder
Diese Seite
04 · Mit KI entwickeln
PLC KI Tool

Plattform · Verfügbar als 90-Tage-Pilot

IndustrialFlow

Entspricht in IndustrialFlow der SBOM im IEC-62443-Gate.

// 09Frühe Nutzung

Ab wann geht das
bei uns?

Wir suchen Maschinen- und Anlagenbauer, die ihre SBOM für den Cyber Resilience Act aufbauen und den SBOM Builder früh an einer Baureihe einsetzen wollen, gern mit Steuerungen mehrerer Hersteller. Was dafür nötig ist und ab wann es geht, klären wir in einem kurzen Gespräch.

Pilot anfragen

30 Minuten · unverbindlich · kein Vertriebsgespräch

PLC SBOM Builder: eine SBOM für die ganze Maschine

Was ist der PLC SBOM Builder?

Wie ist der PLC SBOM Builder aufgebaut?

Warum entsteht die SBOM einer Maschine nicht von selbst?

Was soll der SBOM Builderkönnen?

Hardware- und Firmware-Inventar

Software-Inventar

Kennungen und Pflichtfelder

Eine Maschine, eine SBOM

Validieren und mit dem Feld abgleichen

Was läuft heute schon?

Eine SBOM je Maschine

Prüfung gegen Schema und TR

Adapter für vier Umgebungen

Prüfbericht

Abgleich mit dem Feld

Kennungsprüfung gegen CSAF

Beispiel-Pipeline und Pakete

TIA Portal über Openness

Adapter für B&R Automation Studio