An SBOM for a ROS 2 robot should list the operating system packages, the ROS packages you build or install, the DDS implementation, language dependencies, container images and any vendor binaries, each with a version. The goal is to answer one question fast: which robots run the affected component?
Why robots need their own list
A robot is a small fleet of software. A typical image mixes an operating system, ROS 2 packages, a DDS middleware, Python or C++ libraries, drivers and perhaps a web dashboard. Each layer has its own update stream and its own advisories.
The SROS2 project notes that it has been tested against several DDS implementations, including Fast DDS, Cyclone DDS and Connext, and that Connext Secure requires a license. That is a reminder that the middleware choice varies between teams, so you cannot assume what another site runs.
The layers to list
- Base operating system and kernel, with package versions.
- ROS 2 distribution and every package you install, including the ones pulled in as dependencies.
- The DDS vendor library and version.
- Python and C++ libraries your own nodes use, resolved to exact versions.
- Container base images and layers, if you ship containers.
- Vendor binaries and drivers, such as camera or motor SDKs. If the vendor will not give a list, record name, version and source.
- Firmware on attached controllers, as a separate component entry.
Make it per build, not per project
Generate the SBOM from the artifact you deploy, at build time, and store it with the image or release tag. An SBOM written by hand from memory drifts within a month. Our post on SBOM generators and SCA scanners explains how the generation and the analysis steps differ.
Match it to the fleet
The list only helps if you also know which build runs on which robot. Keep a record of the deployed version per machine, and update it on each rollout. Without that mapping, an advisory still means a manual hunt.
Pick one of the common formats. Our comparison of CycloneDX and SPDX covers the tradeoffs.
Ask suppliers for theirs
For vendor supplied software, request an SBOM and check it against the basics, as in our guide on checking a supplier SBOM against the minimum elements.
Where Safeguard fits
Safeguard can generate and analyze SBOMs and scan dependencies, and its reachability analysis helps show which findings in your own code paths matter. You can try a free scan at gold.safeguard.sh/scan.
Click through it at your own pace, or open it full screen.
Common gaps
Teams often miss packages installed by hand on a robot during bring-up, libraries baked into vendor images and anything fetched at start-up. Compare the SBOM from your build with a listing taken from a running robot. Differences show you where the build and reality have drifted, and that is where unknown software hides.
Quick check
Should the SBOM include firmware on the motor controllers?
Yes, as separate component entries if you can get the version. Firmware is often the part with the longest life and the least visibility.
Sources
Last reviewed: 19 October 2026.
