Embedded systems are where SBOM gaps hurt the most. A vulnerable library in a web application gets patched in a sprint cycle. A vulnerable library in a medical device, an industrial controller, or a smart lock might persist for a decade.
The embedded world runs on long lifecycles, infrequent updates, and firmware that's often assembled from a mix of open-source components, vendor BSPs, and proprietary code with poor documentation. If there was ever a domain that needed rigorous software inventory, this is it.
Why Embedded SBOMs Are Critical
Lifecycles Measured in Decades
An embedded device deployed in 2023 might still be in the field in 2035. The OpenSSL version baked into its firmware will accumulate CVEs over that entire period. Without an SBOM, nobody -- not the manufacturer, not the operator, not the regulator -- can assess the risk.
Patching Is Expensive or Impossible
Updating firmware on deployed devices ranges from inconvenient (OTA update to a consumer gadget) to prohibitively expensive (physical access to industrial equipment) to impossible (devices without update mechanisms). When you can't easily patch, you need to know exactly what you shipped.
Regulatory Pressure Is Real
The EU Cyber Resilience Act will require manufacturers of products with digital elements to maintain and provide SBOMs. The FDA already requires SBOM submissions for medical device premarket approvals. The US Executive Order 14028 affects embedded systems sold to federal agencies.
Complex Build Systems
Embedded firmware is typically built using specialized systems like Yocto/OpenEmbedded, Buildroot, or vendor-specific SDKs. These systems cross-compile hundreds of packages from source, apply custom patches, and link them into a firmware image. Standard application-level SBOM tools don't understand this process.
SBOM Generation for Yocto/OpenEmbedded
Yocto is the most widely used embedded Linux build system, and it has the best SBOM support in the embedded world.
Native SPDX Support
Since Yocto 3.4 (Honister), the build system includes native SPDX SBOM generation:
# In local.conf, enable SPDX generation
INHERIT += "create-spdx"
# Build your image
bitbake core-image-minimal
# SBOMs are generated per-package and per-image in:
# tmp/deploy/spdx/
This produces SPDX documents for every package and a comprehensive image-level SBOM that includes:
- Every recipe built and included in the image
- Source URLs and versions
- License information (Yocto is meticulous about license tracking)
- Build configuration details
- Relationships between packages
CycloneDX for Yocto
If you need CycloneDX format, convert from SPDX or use community tools:
# Convert SPDX to CycloneDX
pip install spdx-tools cyclonedx-bom
# Use conversion utilities to transform between formats
Capturing Patch Information
Yocto recipes often apply patches to upstream source code. A good embedded SBOM should capture these patches because they affect the actual code running on the device:
SRC_URI = "https://example.com/foo-1.2.3.tar.gz \
file://fix-buffer-overflow.patch \
file://disable-telemetry.patch"
The Yocto SPDX class captures patch information in the SBOM, which is valuable for understanding exactly how the deployed code differs from upstream.
SBOM Generation for Buildroot
Buildroot has built-in SBOM support through its legal-info infrastructure:
# Generate legal and package information
make legal-info
# Output in output/legal-info/
# Includes: manifest.csv with package names, versions, licenses, and URLs
The manifest.csv isn't a standard SBOM format, but it contains the data you need. Tools exist to convert it:
# Convert Buildroot manifest to CycloneDX
# Several community tools handle this conversion
python buildroot2cdx.py output/legal-info/manifest.csv > sbom.json
For more complete SBOMs, some teams augment Buildroot's output with Syft scans of the final filesystem:
# After building the root filesystem
syft dir:output/target -o cyclonedx-json > sbom.json
Binary Analysis for Firmware
When you don't have access to the build system -- common when working with vendor-provided firmware blobs -- binary analysis is your fallback.
Using Syft on Firmware Filesystems
If you can extract the firmware filesystem (using tools like binwalk), Syft can scan it:
# Extract firmware filesystem
binwalk -e firmware.bin
# Scan the extracted filesystem
syft dir:./_firmware.bin.extracted/squashfs-root -o cyclonedx-json > sbom.json
FACT (Firmware Analysis and Comparison Tool)
FACT is an open-source firmware analysis framework that includes SBOM-relevant capabilities:
- Identifies known software components via binary signatures
- Extracts version strings from binaries
- Detects known cryptographic implementations
- Identifies hardcoded credentials and keys
Limitations of Binary Analysis
Binary analysis will always be less accurate than build-system integration. It can miss:
- Statically-linked libraries that don't expose version strings
- Custom-compiled components with stripped debug information
- Proprietary components that binary databases don't recognize
Build-time SBOM generation is always preferable. Binary analysis is a fallback for auditing third-party firmware.
The Vendor BSP Problem
Board Support Packages (BSPs) from silicon vendors are a particular pain point. A BSP might include:
- A Linux kernel with vendor-specific patches
- Proprietary GPU drivers as binary blobs
- Vendor-modified versions of U-Boot, GStreamer, or other open-source components
- Precompiled libraries with no source or version documentation
Most BSP vendors in 2023 do not provide SBOMs. This is slowly changing under regulatory pressure, but today you'll likely need to:
- Audit the BSP contents manually
- Cross-reference binary files against known package databases
- Document known components and their versions
- Request SBOM information from the vendor (put it in the procurement contract)
Tracking Firmware Variants
Embedded products often ship multiple firmware variants:
- Different hardware revisions with different BSPs
- Regional variants with different feature sets
- OEM variants branded for different customers
- Debug vs. release builds with different component inclusion
Each variant needs its own SBOM. Your tracking system should map device model + hardware revision + firmware version to a specific SBOM.
Medical Device SBOMs
The FDA's premarket cybersecurity guidance (2023) explicitly requires SBOMs for medical devices. Key requirements:
- Commercial, open-source, and off-the-shelf software components must be listed
- Component versions must be specific (not ranges)
- Known vulnerabilities must be documented with risk assessments
- The SBOM must be maintained throughout the device lifecycle
For medical device manufacturers, the SBOM isn't just a security tool -- it's a regulatory deliverable that affects market approval.
Industrial and Automotive SBOMs
UNECE WP.29 (automotive cybersecurity regulation) requires software inventory management throughout the vehicle lifecycle. IEC 62443 (industrial automation security) increasingly references SBOM concepts.
These regulated industries need SBOMs that:
- Persist for the full product lifecycle (10-30 years)
- Track field-deployed versions precisely
- Support vulnerability assessment against current CVE data
- Survive corporate acquisitions and organizational changes
How Safeguard.sh Helps
Safeguard provides the long-term SBOM management that embedded systems demand. Upload firmware SBOMs generated from Yocto, Buildroot, or binary analysis, and the platform maintains continuous vulnerability monitoring for the entire device lifecycle. When a new CVE affects a library version you shipped in firmware three years ago, Safeguard flags it immediately. Track multiple firmware variants, hardware revisions, and field-deployed versions in a single dashboard. The platform retains SBOM history for the full product lifecycle -- because embedded devices don't retire on sprint boundaries.