Yes, but not by scanning the crane yourself. Most crane controllers run vendor firmware you cannot read, so the practical route is to require an SBOM from the supplier, keep it per firmware version, and match it to advisories. Where none exists, binary analysis can fill gaps with lower confidence.
Why does a crane need an SBOM?
A modern container crane is a machine with controllers, drives, sensors, remote diagnostics and often a link to terminal systems. Each has firmware, and firmware contains third party components. When a new library flaw is published, the operator needs to know which machines contain it.
That is the question an SBOM answers. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components, and notes that a VEX document can state whether a product is affected by a known vulnerability (CISA).
What is different from a normal application?
You do not control the build. A web application team can generate an SBOM in CI. A terminal operator buys the crane, and the manufacturer builds the firmware. So your lever is procurement and contract, not tooling.
Updates are rare and risky. Patching a controller can mean downtime and re-validation. An SBOM tells you what is affected, but the fix may be a compensating control such as segmentation until a maintenance window.
Hardware matters too. CycloneDX covers hardware bills of materials alongside software, and is published as ECMA-424 (CycloneDX).
Which standards help?
The ISA/IEC 62443 series addresses security for industrial automation and control systems. It splits responsibility across asset owners, integrators, product suppliers and service suppliers. For a crane, that tells you who should hold the component list: the product supplier produces it, and the asset owner asks for it (ISA).
We did not verify specific IEC 62443 clause numbers on supplier SBOM duties, so check the parts you cite before writing them into a tender.
What if the supplier has no SBOM?
Ask anyway, and record the answer. If the answer is no, you have a choices list:
- Request the component list in whatever form the supplier can provide, and convert it.
- Use binary analysis tools on firmware images the supplier permits you to examine. These identify libraries by signatures and strings. Expect false negatives and some misidentification.
- Treat unknown components as unknown risk and isolate the machine network accordingly.
Label each SBOM with how it was produced: supplier provided, derived from binary, or inferred. Confidence differs, and an auditor will want to see that.
How do you keep the data useful?
Tie each SBOM to a machine identifier, not just a product name, because two cranes of the same model can run different firmware. Record when the SBOM was received and who supplied it. Update the record whenever a maintenance visit changes firmware, so the store matches what is installed.
What to do
- Inventory crane control systems: PLCs, drives, remote access gateways and HMIs, with model and firmware version.
- Add an SBOM and vulnerability notification requirement to purchase and maintenance contracts.
- Store each SBOM by machine and firmware version in a searchable place.
- Subscribe to advisories for the vendors and match them against that store.
- Ask suppliers for VEX statements when advisories apply.
- For machines without SBOMs, document compensating controls such as network segmentation and restricted remote access.
- Rehearse a "new library flaw" drill: how long to list affected machines?
Quick check
Can we scan crane firmware ourselves?
Sometimes, if the supplier allows access to firmware images and the license permits it. Results are less reliable than a supplier SBOM.
Is an SBOM enough to secure a crane?
No. It tells you what is inside. You still need segmentation, access control, patching plans and monitoring.
Sources
Last reviewed: 18 October 2026.
