Yes. A real time operating system is code you ship, it has its own version and its own advisories, and customers will ask about it. List the kernel, its configuration, and every bundled library as separate components with exact versions, not as a single line called "RTOS".
Why the RTOS is easy to miss
Application teams think of the RTOS as the platform, not a dependency. It often arrives inside a vendor SDK, copied into a source tree, with local patches. Nothing in a package manager records it. If nobody writes it down, the SBOM shows your application libraries and silently skips the code that schedules your tasks and runs your network stack.
That gap matters because an advisory against the kernel or a bundled TCP stack is exactly the sort of thing a buyer will ask about after reading the news.
What to list
CycloneDX 1.6 has an operating-system component type, defined as a software operating system without regard to deployment model, and a firmware type for low level control software. For a small RTOS image that is linked into one binary with your application, either label can be defended. Pick one and use it consistently.
Then list the pieces inside:
- The kernel, with the version string from the source you built, not the version you intended to use.
- Bundled middleware such as a network stack, file system or TLS library, each as its own library component.
- Board support code and HAL libraries from the chip supplier.
- Local patches, noted in the component description or a property, so a reader knows the code is not stock upstream.
Steps
- Find the real version. Search the source tree for a version macro or header, and compare it with the vendor SDK release notes.
- Find the bundled extras. Look in the third party or libraries directory of the SDK.
- Check for forks. If the code was modified, say so, and record the upstream version it was based on.
- Add the entries to the SBOM, or to the input your generator reads.
- Re-check on every SDK update. SDK drops often bump bundled libraries silently.
When you do not know
Some vendor SDKs ship stripped headers or renamed code. Record what you can prove, mark the rest as unknown, and ask the supplier for a component list. Questions to put to them are short: which open source components are inside, at what versions, and how will you tell us about fixes.
Common objections
"The RTOS vendor handles security." They may, but you still need to know which version you ship, because only you can say whether a fix has reached a released image.
"The scanner does not find it." That is a reason to add it by hand, not to omit it.
Try it yourself
Open the dependency inventory demo and see how an inventory separates direct from bundled entries. Picture your SDK folder as rows in that list.
Click through it at your own pace, or open it full screen.
Safeguard generates SBOMs and scans dependencies from repositories. Components copied into a source tree may need a manual entry, so review the output against your SDK before you share it.
Quick check
Is the RTOS a dependency or a platform?
For SBOM purposes it is shipped code. List it with its version and its bundled libraries.
What if my RTOS is patched locally?
List the upstream version it was based on and note that it is modified.
Sources
Last reviewed: 19 October 2026.