Safeguard
Supply Chain•

Does the RTOS belong in a firmware SBOM?

Yes. The RTOS kernel and its bundled libraries are shipped code with their own advisories. Here is how to list them, with versions, in a firmware SBOM.

Safeguard Security Team
4 min read

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

  1. Find the real version. Search the source tree for a version macro or header, and compare it with the vendor SDK release notes.
  2. Find the bundled extras. Look in the third party or libraries directory of the SDK.
  3. Check for forks. If the code was modified, say so, and record the upstream version it was based on.
  4. Add the entries to the SBOM, or to the input your generator reads.
  5. 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.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.