Yes. The bootloader is code you ship, it runs before everything else, and it often decides whether a firmware image is trusted. Record it as its own component with an exact version, its bundled libraries, and a note on who builds and signs it.
Why it gets left out
Teams often generate the SBOM from the application build. The bootloader lives in a separate repository, is flashed once at the factory, and is touched rarely. So it falls out of the document. Yet it is a place where a flaw can matter a great deal, because it sits at the start of the boot path.
It also tends to be older than the application. Some units in the field may carry a bootloader that was never updated, which makes an accurate record more important, not less.
What to record
| Item | Why |
|---|---|
| Bootloader name and exact version or commit | Matches advisories and tells you which units are affected |
| Bundled libraries such as crypto, compression or file system code | These carry their own CVEs |
| Build date and build configuration | Features compiled out may rule out some advisories |
| Who builds and signs it | Shows who can fix it |
| Update path | Whether it can be updated in the field at all |
CycloneDX lets you describe the firmware as a component and relate it to the device it runs on. Use a firmware or operating-system type per the schema definitions, and keep the bootloader separate from the main application image.
Steps
- Identify the bootloader stage list for your product. Many devices have a ROM stage, one or two later stages, and then the main image.
- For each stage you control, create an SBOM from its repository, or add its entries to the main document.
- For stages supplied by a chip vendor, ask for a component list and a contact for advisories.
- Record the version found on shipped units by reading it from the device, not just from your build server.
- Mark stages that cannot be updated in the field. Those are the long lived risks.
Reading the advisories
When an advisory names a bootloader flaw, ask four questions. Is the affected version in your SBOM? Is the vulnerable feature compiled in? Can an attacker reach it, for example over a physical interface? Can you ship a fix to units already deployed?
The last question is a design question, not an SBOM one, but the SBOM is what makes it answerable.
Limits
A listed bootloader does not mean a secure one. The SBOM says what is there. Verified boot, signing and rollback protection are separate controls, and you should assess them separately.
Where Safeguard fits
Safeguard produces SBOMs and scans dependencies from source repositories. If your bootloader has its own repository, you can scan it like any other, starting with a free scan. ROM code and vendor binaries need a supplier supplied list.
Quick check
Is the ROM bootloader in scope for my SBOM?
If you cannot change it, you still should record that it exists and which vendor owns it, marking what you cannot verify.
Do I need a separate SBOM per boot stage?
Not necessarily. One document with clearly separated components works, as long as each stage has its own entry and version.
Sources
Last reviewed: 19 October 2026.
