SBOM tools for plant builders: capturing the bill of materials, the engineering project and the network scan
In brief · As of July 2026
The well-known SBOM generators run over a build – in special machinery and plant engineering there is none. The tooling question is therefore a different one: what captures the three realistic sources? For the bill of materials it is an export from ERP, PDM or EPLAN. For the engineering project it is the hardware export from the respective engineering system – in TIA Portal the CAx export, at Beckhoff, Rockwell or B&R the equivalent – where order or type number and configured firmware sit side by side in machine-readable form. For the network scan in the acceptance window, the tools already on the engineering laptop are usually enough; from regular acceptance tests onwards, a discovery tool that captures several vendor worlds in one run pays off. Continuous OT monitoring platforms are built for permanent operation at the operator's site.
Searching for an "SBOM tool" reliably leads to tools that assume a build or at least a file system. For a packaging machine made of PLCs, HMIs, drives, industrial PCs and sensors from dozens of suppliers, none of them works: there is no build that produces this plant and no package manager that describes it. Where the data comes from instead is covered in the article on creating an SBOM in plant engineering; which platform category carries vulnerability management afterwards, in the article on tool selection. This one is about the step in between: what is the data actually captured with?
Bill of materials, engineering project and network scan are three separate sources
The tools sort themselves by the source they read. The bill of materials holds what was ordered, the engineering project what was configured and the scan the state actually running.
| Bill of materials (ERP/EPLAN) | Engineering project (TIA Portal, TwinCAT, Studio 5000 …) | Network scan (acceptance) | |
|---|---|---|---|
| Provides | Article number, supplier, quantity, plant assignment | Order number + configured firmware, network structure | Real firmware version, devices actually present |
| Does not provide | Firmware version | Actual state; anything outside the automation project | Non-networked devices; devices below the fieldbus; assignment to order and supplier |
| Tools | ERP/EPLAN export (CSV/Excel), CycloneDX libraries for the format | Hardware export of the engineering system (CAx/AutomationML or Openness in TIA Portal), octoplant/Octovision, OTbase | PRONETA, engineering system online view, Wireshark, OTbase Discovery |
| Effort | Export is trivial, reproducibility is the work | Set up the export once, then retrievable per project | One appointment per plant – if anchored in the acceptance procedure |
Route 1: The bill of materials comes from ERP, ECAD or PDM
For the commercial and design half, this comes down to an export from a system that is running anyway. The three usual systems are not equally suited:
- ERP. Supplies the order-related bill of materials with supplier and plant assignment and is therefore the mandatory basis. Weakness: purchasing carries order descriptions, not consistently normalised manufacturer article numbers.
- ECAD, usually EPLAN. The more precise list for the control cabinet: device tag plus the real manufacturer article number per device, because electrical design works with manufacturer data. Where both exist, the EPLAN summary parts list is the better starting point for advisory matching, and the ERP export the source for order, supplier and assignment.
- PDM/PLM. Adds the assembly structure – useful once a series model is maintained, dispensable for the first plant.
This route needs no dedicated tool. A CSV or Excel extract with article number, description, quantity, supplier and installation location is enough. The work starts with the demand to retrieve it reproducibly, per plant.
Route 2: The hardware export of the engineering project supplies the firmware version
The source that is fully present at most machine builders and still rarely used. Every engineering project – TIA Portal at Siemens, TwinCAT at Beckhoff, Studio 5000 at Rockwell, Automation Studio at B&R – holds, for every configured device, the order or type number and the configured firmware version. Exactly the field where the bill of materials ends. What the export looks like differs by vendor; the content is the same.
The route is best documented at Siemens. The CAx export writes the configured hardware out as an AutomationML file; devices carry a type identifier of the form OrderNumber:6ES7 510-1DJ01-0AB0/V2.9 – order number, slash, configured firmware version. TIA Openness exposes the same attributes per device.
This is reliable for devices from the hardware catalogue that were configured with a concrete firmware version. For GSD/GSDML-based third-party devices the type identifier names the GSD file rather than an order number, and devices configured only as placeholders carry no defensible version. How large that share is in your own engineering standard is something a first export of a real plant shows.
Tools that offer this step ready-made do exist – but for the operator side. octoplant (AUVESY-MDT) is a version management system that cyclically backs up the controllers; the Octovision layer on top turns that data into an asset inventory with CVE context. Like the continuous monitoring platforms, this assumes the software runs where the plant stands – for the plant builder's view of plants already shipped, the model does not fit. OTbase (Langner) merges engineering data and network discovery into one inventory and thereby covers route 2 and route 3 in the same tool.
Werkspilot works directly with these sources: hardware export from the engineering system, parts list from EPLAN or bill of materials from the ERP – the file goes in as the respective system writes it. A network scan from the acceptance test can be processed on top, but is not a prerequisite. The devices are normalised, matched against supplier advisories and tracked per delivered plant – in use today with plant builders and component manufacturers who run exactly this matching. The perspective is the plant builder's view of their field base, not an operator's view of a monitored network.
The engineering project still remains the second-best source:
- It describes the as-configured state. What gets configured is often "firmware version x or later", what gets installed is the version the supplier ships at that moment.
- It knows nothing about the stock room. Components that sat in your own stock for a while often leave with an older firmware version than the manufacturer's current shipment, and nobody updates them before installation.
- It only covers the automation scope. The industrial PC running the vision system, the camera system and the remote-access router do not exist for this source.
Route 3: For the network scan a commissioning tool serves better than a security product
The best tools for the acceptance window already sit on the engineering laptop. Which one is right depends on two questions: how many control platforms sit in the plant, and is the scan a one-off or a process step? The table sorts the tools by those two questions. The continuous OT monitoring platforms are listed too, because they surface first in any search; they are built for the operator who monitors a site permanently.
| Tool | How it works and what it is good at | Firmware version | Cost | The right tool when … |
|---|---|---|---|---|
| PRONETA Basic (Siemens) | Actively queries all devices via PROFINET DCP, without a PLC and independent of IP configuration; lists devices and topology and exports the result | yes, for PROFINET devices | free | … the plant mostly speaks PROFINET and this is a one-off acceptance |
| Engineering system online view (TIA Portal, TwinCAT, Studio 5000, Automation Studio) | Compares the devices actually connected against what the project says – one system per vendor world | yes, for configured devices | already owned | … the project is open anyway and only the automation scope matters |
| Fieldbus diagnostics (EtherCAT, EtherNet/IP, PROFIBUS) | Shows the devices below the head module that never appear on the IP network and are therefore in no network scan | yes, for devices on that bus | usually owned | … sensors and drives sit behind a fieldbus |
| Wireshark | Listens only; reveals what announces itself via DCP and LLDP | partly | free | … as a cross-check on the active scan, never as the main tool |
| OTbase Discovery (Langner) | Actively queries in several vendors' protocols (PROFINET, PROFIBUS, EtherNet/IP, EtherCAT and more) and writes one shared inventory – one tool instead of four exports, and runs mobile from a USB stick | yes | licence | … acceptance tests are regular and the scan is to become a process step |
| Network management systems in continuous operation | Monitor a network permanently; the inventory falls out as a by-product of running the network | yes | licence | … the subject is your own plant, not the acceptance of a machine you are shipping |
| Claroty, Nozomi, Defender for IoT, Tenable OT, Dragos | Largely passive and continuous; permanent monitoring with anomaly detection and SOC integration | partly | licence model differs by vendor | … you are the operator and want continuous monitoring |
Two assignments cover most cases in practice:
- One control platform, single acceptance: the vendor's discovery tool for coverage (PRONETA at Siemens), the engineering system's online view for the as-configured versus actual comparison, fieldbus diagnostics for everything behind the head module, Wireshark as a cross-check. Cost: the appointment.
- Several deliveries per year, several vendor worlds in one plant: a discovery tool such as OTbase, fixed as a step in the acceptance procedure. The licence pays off against the hours otherwise spent merging exports.
One warning belongs here: IT scanners such as Nmap and vulnerability scanners in their default configuration are as a rule unsuitable for plant networks. Older controllers and field devices answer aggressive port probing with a standstill in the worst case. That is exactly what the familiar line "active scanning is dangerous in OT" warns about. It does not apply to PRONETA or an engineering system's online view: those ask in the protocols of automation, the way any engineering station on the network does. What matters is whether a tool speaks the devices' language; active versus passive is the wrong dividing line.
Format tools are the least of your worries
Converting a device list to CycloneDX is a solved problem: there are official libraries for it, and tools such as the CycloneDX CLI or sbom-utility check at the end whether the file holds up formally. It gets difficult one step earlier: the formats expect CPE or PURL as the identifier, and for industrial components these often simply do not exist. The realistic identifier is manufacturer plus article number plus version – exactly how industrial advisories name their affected products. A clean list in CSV is worth more than a formally correct CycloneDX file whose version numbers are guesses.
Merging and matching remain open
All the tools named produce lists. Two steps remain open after that, and none of them takes those on.
The merging. The sources almost never spell the same device the same way: the scan reports what the device claims about itself over its protocol, the ERP carries purchasing's order description, the project the MLFB. Spellings, spaces and option suffixes diverge systematically. Matching that up by hand, plant after plant, costs more time than the scan and the export together. Turning several exports into one device inventory per plant is exactly the step Werkspilot takes over.
The matching against advisories. Creating the SBOM is itself a CRA obligation (Annex I Part II No. 1). The list alone is not the end of it – it is the basis for ongoing vulnerability management. For that, new supplier advisories have to run continuously against this inventory. The result is usually the all-clear that your own plants are not affected; it gets needed when the end customer asks or a report is due. The machine-readable format for it is a VEX statement.
The fastest way to make this concrete is on a real plant. Export whatever your system gives you – a CAx export from TIA Portal, the equivalent from TwinCAT or Studio 5000, the parts list from EPLAN or the bill of materials from the ERP. We normalise the devices and match them against open vulnerabilities. No finished SBOM and no particular format required.
Questions from practice
Is one single tool enough for the whole capture?
No. What no capture tool solves: the assignment to order and supplier (that comes from the ERP), non-networked components (no scanner sees those) and the ongoing match against supplier advisories (which only starts after the capture). For the capture itself, OTbase comes closest, because it merges engineering data and discovery into one inventory – even that replaces no source, it saves reconciliation work.
What about Syft, Trivy and the other SBOM generators?
They are right for your own software – the self-built IPC image, your own application. There, a build exists and with it a genuine, deep SBOM. For purchased industrial components they do not work: what sits inside the firmware of someone else's PLC, only its manufacturer knows.
How often does the scan need repeating?
Not by calendar but by event. The as-delivered state is captured at acceptance; after that it changes with a retrofit, a component replacement or a firmware update during a service call. Every touchpoint of your own with the plant is an opportunity to bring the record up to date. A permanently current field inventory across all delivered plants, by contrast, is a fiction – the plant stands at the operator's site, frequently without remote access.
Werkspilot monitors supplier advisories automatically and matches them against the field base of plant builders and integrators. This article reflects Werkspilot's assessment and does not constitute legal advice. Products and brands named belong to their respective manufacturers; there is no business relationship with the vendors named.