SBOM For Firmware and Embedded Software in DevSecOps

Software Bill of Materials (SBOM) plays a growing role in embedded security. For firmware and connected devices, it gives you visibility into components that often go unchecked. In this blog, you'll explore the challenges of firmware SBOMs in development, security and operations (DevSecOps) and how to approach them with confidence.

Key Takeaways

• Firmware and embedded SBOMs are harder to create than traditional software inventories because teams often lack access to source code and rely on undocumented third-party components within tightly coupled hardware environments.
• DevSecOps teams need both build-time SBOMs and binary analysis SBOMs to close visibility gaps across legacy devices, vendor firmware, and multi-toolchain ecosystems.
• Build-time SBOMs deliver high precision and rich licensing metadata, but they assume control over the build environment and cannot cover external or post-deployment firmware.
• Binary-based SBOM generation enables supply-chain verification, field device inspection, and incident response when source artifacts are unavailable.
• Integrating SBOMs into CI/CD security gates helps block unsafe firmware builds, flag policy violations, and maintain audit readiness for standards such as CRA, NIS2, SPDX, and CycloneDX.
• Automation, including automated vulnerability management workflows, is essential to keep SBOM data aligned with rapid firmware release cycles and to ensure newly disclosed CVEs are continuously linked to embedded components.

The Most Common Challenges With Firmware SBOMs In DevSecOps

Firmware is different from typical software. You don't always have access to the source code, and components are often undocumented. This makes creating a reliable SBOM for firmware more difficult than it sounds in a typical SBOM DevSecOps context.

You also face fragmentation across toolchains, formats, and hardware types. Unlike cloud-native applications, embedded systems rely on tightly coupled dependencies. These are harder to track and may not follow standard DevSecOps practices.

Firmware is also frequently compiled by third parties. This adds complexity when verifying components, licences, or known vulnerabilities. Without visibility, firmware becomes a black box in your DevSecOps pipeline.

Two Paths To Firmware SBOM -- And Why Teams Need Both

There are two practical ways to generate an SBOM for firmware: from the build process or from the binary. Each method uncovers different pieces of the puzzle, depending on whether you have access to source code or only compiled firmware. Using both together gives you stronger coverage, better accuracy, and a more complete view of your product's security.

SBOM From The Build Process

SBOMs can be generated as part of the build, during software compilation. This method provides accurate component-level information from the source. It's ideal when you have control over the firmware codebase.

Benefits of build-time SBOMs include:

• High precision in component identification
• Rich metadata for licensing, versions, and sources
• Easy integration into CI/CD workflows

You get transparency during development and can automate security gates. But this method assumes you own or manage the firmware's build environment. If you don't, it leaves a significant visibility gap.

SBOM from Binary/Firmware analysis

Binary analysis allows you to generate an SBOM by reverse engineering the compiled firmware. This technique is essential when source code is unavailable. It lets you inspect third-party firmware or legacy products.

You can extract libraries, identify hardcoded dependencies, and scan for outdated components. While less precise than build-time SBOMs, it fills critical gaps in visibility. This is especially useful for compliance teams and PSIRTs managing supply chain risk.

Key use cases for binary SBOMs include:

• Verifying third-party firmware from vendors
• Analysing field devices during incident response
• Supporting post-release audits or investigations

The accuracy of binary SBOMs depends on the tooling. You need strong firmware extraction, decompilation, and pattern matching. Combining both methods gives you a more complete view.

How Does Firmware SBOM Fit Into a DevSecOps Flow?

Firmware SBOMs can be integrated across your DevSecOps lifecycle. They provide security teams with visibility from design through deployment. This helps reduce risk and improve product resilience.

In development, SBOMs support secure coding and vulnerability checks. During CI/CD, they can be used to block unsafe builds or flag policy violations. After release, they help PSIRTs manage incidents and respond to new CVEs.

Key integration points for firmware SBOMs include:

• Design phase: Identify approved components early
• Build phase: Generate SBOMs automatically from code or binaries
• Testing phase: Use SBOMs to perform security and licence checks
• Deployment: Archive SBOMs for compliance and traceability
• Post-release: Monitor for newly disclosed CVEs and risks

Integrating SBOMs with automated vulnerability management workflows helps you catch issues early. This ensures vulnerabilities linked to firmware components don't go unnoticed between releases. Automation reduces human error and improves response times.

Concrete Benefits of Firmware SBOMs in DevSecOps

SBOMs create value across teams, not just security. They simplify collaboration between engineering, compliance, and product stakeholders. Everyone sees what's inside the firmware and what needs attention.

Benefits include:

• Improved vulnerability detection: Teams can respond faster when new CVEs emerge.
• Streamlined audits: SBOMs make it easier to prove compliance with NIS2, CRA, and other regulations.
• Reduced incident response time: Knowing what's in your firmware speeds up triage and fixes.

They also improve accountability. Adopting SBOM DevSecOps practices helps bridge gaps between development, security, and compliance. With clear component data, you can assign owners, define risk thresholds, and enforce governance. This is where using a SBOM management tool becomes critical.

Requirements for SBOM Tools for Firmware/Embedded in DevSecOps

To support firmware in DevSecOps, your SBOM tools need specialised features. Generic solutions often fail to detect embedded components or understand non-standard packaging. You need tools built for low-level analysis.

Look for tools that can:

• Analyse raw binaries and extract component data
• Support industry SBOM formats like SPDX or CycloneDX
• Integrate with CI/CD and ticketing tools like Jenkins and Jira
• Detect hardcoded secrets, outdated libraries, and config issues

Scalability and automation also matter. Manual processes can't keep up with fast firmware release cycles. That's where automated vulnerability management becomes a necessity, not a luxury.

You also want integration with a CVE scanner that supports firmware-specific threats. Traditional scanners often miss risks buried in binaries. Tools that combine SBOM generation with CVE analysis offer deeper protection.

Conclusion

SBOMs are a cornerstone of secure firmware development. They help teams understand what goes into a device and how those components change over time. For DevSecOps teams working with embedded systems, firmware SBOMs close visibility gaps that would otherwise go unnoticed.

Creating them isn't always easy. But using both build-based and binary methods gives you the flexibility you need. With the right tools and strategy, firmware SBOMs become a powerful asset in your security and compliance workflows.

Frequently Asked Questions About SBOMs in DevSecOps (FAQ)

How does an SBOM differ from a dependency scan?

A dependency scan checks known libraries in source code or packages. An SBOM is a full inventory of components, including their versions, origins, and licences. It's broader and includes binary-level data, which makes it more effective for firmware.

Which SBOM standards are relevant for DevSecOps?

The most widely used standards are SPDX and CycloneDX. Both are supported by open-source tools and can be integrated into pipelines. CycloneDX is often preferred for embedded use due to its support for hardware metadata.

How often should an SBOM be updated?

An SBOM should be updated with every firmware change. This includes patches, version bumps, or dependency updates. Treating it like source code ensures accuracy and audit readiness.

Is SBOM management mandatory for CRA or NIS2?

Yes, both the CRA and NIS2 require visibility into software components. SBOMs help you meet these regulatory expectations. They also improve your ability to respond to post-deployment vulnerabilities.

How does ONEKEY automate SBOM creation?

ONEKEY supports SBOM generation through both build-time and binary analysis. It automates extraction, formatting, and vulnerability linking. This allows teams to generate accurate SBOMs for embedded firmware without slowing down development.