CycloneDX 1.6 defines device, firmware, operating-system and device-driver as component types, alongside library and application. For an embedded product, use device for the physical part, firmware or operating-system for the software that runs on it, and library for the open source code compiled into that software.
What the specification says
The CycloneDX 1.6 JSON schema lists these component types: application, framework, library, container, platform, operating-system, device, device-driver, firmware, file, machine-learning-model, data and cryptographic-asset.
Two definitions matter for embedded teams. A device is "a hardware device such as a processor or chip-set". The schema adds that a hardware device containing firmware should include one component for the physical hardware and another of type firmware or operating-system describing the software running on it. Firmware is defined as "a special type of software that provides low-level control over a device's hardware".
A quick mapping
| What you are describing | Suggested type |
|---|---|
| A microcontroller, radio module or sensor board | device |
| The image that runs on that part, with no general purpose OS | firmware |
| An embedded Linux or RTOS image | operating-system |
| A kernel module or peripheral driver you ship | device-driver |
| An open source library linked into the image | library |
| A TLS stack or similar with framework-like features | library, or framework if it behaves like one |
The schema says that if a component has key features of a framework it should be a framework, and that library is the recommended choice when you are unsure.
Steps to apply it
- List the physical parts you ship or integrate. Add one device component per part.
- For each part that runs code, add a second component of type firmware or operating-system, with the version your release process assigns.
- Add the libraries compiled into that code as library components.
- Record the relationships so a reader can see which firmware runs on which device and which libraries sit inside it.
- Keep versions exact. A type label does not help a vulnerability matcher if the version is blank.
Mistakes to avoid
Labelling a whole product as one application hides the layers that get vulnerabilities at different speeds. A chip vendor library inside a bootloader will be patched on a different clock than your own application code.
Another mistake is using the device type for software. The schema reserves it for hardware.
You also do not need to be perfect on day one. If you only know a component is "some firmware from a module supplier", record that, mark what you do not know honestly, and improve the entry when the supplier answers.
Try it yourself
Open the dependency inventory demo and look at how components are grouped and versioned. Then think about which of your own layers would map to device, firmware and library entries.
Click through it at your own pace, or open it full screen.
Safeguard generates SBOMs and scans dependencies from your repositories, and you can try a free scan. Layer labelling for physical devices is something your team decides and records.
Quick check
Is firmware a library?
No. CycloneDX gives firmware its own type. Use library for reusable code that is compiled or linked into something else.
Do I need both a device and a firmware component?
The schema says a hardware device containing firmware should have a component for the hardware and another for the software running on it.
Sources
Last reviewed: 19 October 2026.
