Not the compiler itself, but yes to the runtime libraries it links into your image. Record the toolchain version in a separate build record, and list its C library, startup code and runtime support as components, because those bytes ship on the device.
Two different questions
People mix up two things. One is what code is in the shipped image. The other is what tools made it. An SBOM answers the first. The second belongs in a build record, sometimes called build provenance.
A compiler binary does not end up on a microcontroller. But the C library it supplies, the startup files, and compiler support routines do. A flaw in a bundled C library function is a flaw in your device.
What goes where
| Item | In the firmware SBOM? | Where else |
|---|---|---|
| Compiler and linker binaries | No | Build record |
| Compiler version and flags | No, or as a note | Build record |
| C library linked into the image | Yes | |
| Startup code and runtime support | Yes | |
| Newlib style small libraries or vendor C runtime | Yes, with exact version | |
| Code generators and configuration tools | No | Build record |
| Generated source from those tools | Yes, as part of your code |
Why the build record still matters
The version of the toolchain affects security. Compiler hardening flags, stack protection options and bug fixes differ between releases. If a compiler bug is found later, you want to know which releases were built with that version.
Record, per release: toolchain name and version, key flags, host operating system image, and the commit of the build scripts. Store it with the SBOM. A reproducible build setup makes this much easier, because the same inputs give the same outputs.
Steps
- Pin the toolchain in your build scripts, with a version and a hash of the download.
- Write a small script that prints toolchain facts into a text file at build time.
- Find the C library and runtime pieces in your link map. Add them as components with versions.
- Archive the build record with the SBOM and the image.
- Review when you upgrade the toolchain, and note the change in release notes.
A worked example
Say your device runs a small image built with a vendor supplied toolchain. The link map shows a C library, a floating point support routine set and a startup file from the vendor. The SBOM lists the C library as a library component with the version printed in its header, the support routines as part of the same entry or a second one, and the startup file as part of the board support package.
The build record, kept in a text file next to it, says which toolchain release produced the image, which optimisation and hardening flags were set, and which commit of the build scripts was used. When a customer asks whether a given release was built with stack protection, you answer from the record, not from memory.
Common mistake
Some teams list every tool in the build container as components of the product. That makes the SBOM large and noisy, and customers cannot tell which entries are on the device. Keep the product SBOM about the product.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies from repositories. The toolchain record is something your build system writes. A free scan can show how your source dependencies are reported.
Quick check
Should my SBOM list the build container?
Not as product components. Keep it in a separate build record.
Is the C library part of the SBOM?
Yes, if it is linked into the image. Check your link map for the exact library and version.
Last reviewed: 19 October 2026.
