A robot is not one piece of software. It is a firmware image on a motor controller, a Linux image on the compute module, a robotics framework with dozens of packages, vendor drivers, a vision model, and a cloud agent that phones home. When a CVE lands, the question "are we affected?" has to be answered across all of it.
A software bill of materials (SBOM) is the list that makes that question answerable. This post covers what to put in a robot's SBOM, using CISA's August 2025 draft of the minimum elements and the text of two EU regulations that now ask for something very close to it.
Safeguard does not control robots or vehicles. What it can do is generate and import SBOMs and scan the components listed in them. That is the software supply chain side of robot safety, and it is what this post is about.
What's affected
Every layer of a robot carries components you did not write:
- Firmware on microcontrollers, motor drives and safety controllers, often with an RTOS and a vendor SDK inside.
- The operating system image on the main computer, including the kernel, libc, OpenSSL and the package set.
- The robotics framework, for example ROS 2 packages, plus Python and C++ dependencies pulled in by those packages.
- Drivers and middleware for cameras, lidar, fieldbus and DDS.
- Machine learning models and their runtime libraries.
- Containers used for navigation, fleet agents or simulation.
An SBOM that lists only the application code misses most of the attack surface.
How to check what you need to list
Start from the CISA draft, published on 22 August 2025 and open for public comment until 3 October 2025. It adds four data fields to the 2021 baseline: Component Hash, License, Tool Name and Generation Context. The full set in the draft covers SBOM Author, Software Producer, Component Name, Component Version, Software Identifiers, Component Hash, License, Dependency Relationship, Tool Name, Timestamp, Generation Context, Coverage, Known Unknowns, Automation Support, Frequency, and Distribution and Delivery.
Two of those matter more for robots than for web apps.
Generation Context records whether the SBOM was made before build, during build or after build. A source SBOM will not see a binary blob a vendor dropped into the image. An after build SBOM of the flashed image will. For a robot you usually want both and you should say which is which.
Known Unknowns lets you say "this component is a vendor binary and we have no inside view." For a motor controller with closed firmware, that honesty is more useful than a guess.
The draft also says a Component Hash should only be included when you have the original artifact. If the SBOM Author cannot reach the original, it should not invent one.
A minimal CycloneDX entry for a firmware component looks like this. The hash is the SHA-256 of an example string, shown only to illustrate the field.
{
"type": "firmware",
"name": "motor-controller-fw",
"version": "2.4.1",
"supplier": { "name": "Example Drives Ltd" },
"hashes": [
{ "alg": "SHA-256", "content": "2717e662dba6d7e6880728cdae4ef97828f738ac735509fedc0fc9445f9ea9ee" }
]
}
To list what is on a ROS 2 workspace and its host, a few built in commands get you a first inventory:
ros2 pkg list
colcon list --names-only
rosdep install --from-paths src --ignore-src --simulate
pip freeze
dpkg-query -W -f='${Package},${Version}\n'
None of these gives hashes or relationships, so treat the output as the input to an SBOM tool, not as the SBOM itself.
What to do now
- Decide the unit. One SBOM per robot model and software release, with a separate SBOM per firmware image.
- Generate after build as well as before build, and record the Generation Context in each.
- List firmware, the OS image, framework packages, drivers, containers and models as components, with relationships showing what includes what.
- Mark vendor binaries you cannot inspect as Known Unknowns instead of leaving them out.
- Regenerate on every release and on every over the air update, and keep the previous SBOM so you can answer "what was on the machine in March?"
- Scan the SBOM against vulnerability data and keep KEV status next to each finding, so a known exploited flaw is not buried under hundreds of theoretical ones.
Why the SBOM is a legal question now
Two EU texts ask for something close to this.
The Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers in Annex I, Part II, point 1 to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products." Article 71 says the Regulation applies from 11 December 2027, with Article 14 reporting duties starting earlier, on 11 September 2026.
The Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027. Annex III, section 1.1.9 says the machinery "shall identify the software installed on it that is necessary for it to operate safely, and shall be able to provide that information at all times in an easily accessible form." That is a safety rule that reads very much like an SBOM requirement for the safety relevant software.
The CISA and partner agency guidance on AI in operational technology, published on 3 December 2025, goes the same way. It tells owners to require vendors to provide an SBOM, including for AI components embedded in their products.
A top level only list is the legal floor under the CRA. A robot maker who can only answer for the top level will still struggle when the vulnerable library is three layers down.
Try it yourself
Take one robot release and write down every layer from the list above. Mark each component as source known, binary known or unknown. Then run the same list through an SBOM generator and compare what the tool found against what you wrote.
Click through it at your own pace, or open it full screen.
If you already have a CycloneDX or SPDX file with 100 dependencies or fewer, the free Gold scan runs in your browser, the file never leaves your machine, and no login is needed.
Quick check
Why should a robot SBOM say whether it was generated before or after build?
Because they see different things. A before build SBOM comes from source and repositories and misses binary blobs added later. An after build SBOM of the flashed image sees what is actually on the machine. CISA's 2025 draft calls this field Generation Context.
Which EU rule says machinery must be able to report the software it needs to run safely?
Regulation (EU) 2023/1230, Annex III, section 1.1.9. It applies from 14 January 2027.
When should you leave a Component Hash out of an SBOM?
When you do not have access to the original component artifact. The CISA draft says the author should not include a hash in that case.
Sources
- CISA, 2025 Minimum Elements for a Software Bill of Materials (public comment draft, 22 August 2025)
- Regulation (EU) 2024/2847, Cyber Resilience Act
- Regulation (EU) 2023/1230, Machinery Regulation
- CISA and partners, Principles for the Secure Integration of Artificial Intelligence in Operational Technology (3 December 2025)
