Using SBOMs to Govern Firmware, BIOS, and Embedded Controller Dependencies in Federal Build Pipelines

Most federal SBOM discussions start at the application layer. Teams inventory packages, track dependencies, generate CycloneDX or SPDX documents, and feed those records into vulnerability management workflows. That work matters. But it leaves a significant gap at the bottom of the stack, where the software that initializes hardware, manages out-of-band access, and controls execution environments operates largely outside the reach of standard SBOM tooling.

Firmware is software. BIOS and UEFI images are software. Baseboard management controller code, embedded controller firmware, device microcode, option ROMs, and vendor-supplied hardware management agents are all software. They run before the operating system loads, they persist across reimaging cycles, and they can introduce vulnerabilities or supply chain risks that no application-layer SBOM will ever surface. In federal and defense environments, where hardware procurement spans years and vendor transparency varies widely, these layers represent a real and underaddressed build-time trust problem.

The challenge is not simply one of tooling. It is one of scope definition, data collection, representation, and governance. Teams that have mature application SBOM practices often have no equivalent process for the firmware and embedded software running on the servers, workstations, and network appliances that constitute their build environments, development enclaves, and production infrastructure. When a vulnerability surfaces in a BMC firmware version or a UEFI component, there is frequently no inventory to query, no baseline to compare against, and no clear owner responsible for the update.

This article addresses that gap directly. It assumes familiarity with core SBOM concepts and federal policy context. The focus here is on the practical boundary between application SBOMs and firmware inventories, how to collect and represent firmware artifacts, how to integrate those records into federal build and release workflows, and how to use them for risk decisions when vendor evidence is incomplete or opaque.

Defining the Boundary: Firmware Inventories vs. Application SBOMs vs. Hardware BOMs

Before any governance workflow can be designed, teams need to agree on what belongs in each inventory type. The distinctions matter operationally, not just taxonomically, because they determine who owns the data, what tooling can collect it, how it integrates into existing workflows, and what risk decisions it supports.

A hardware bill of materials describes physical components: processors, memory modules, network interface cards, storage controllers, and the like. It is primarily a procurement and asset management artifact. An application SBOM describes the software components that compose a deployed application or service, including libraries, packages, and their transitive dependencies. A firmware inventory sits between these two. It describes the software embedded in or tightly coupled to hardware components, including BIOS and UEFI images, BMC firmware, embedded controller code, device microcode, option ROMs, and vendor management agents that ship with hardware platforms.

The firmware layer is distinct from application software in several important ways. Firmware often ships as opaque binary images with limited component-level disclosure. It is hardware-specific, meaning a given firmware version applies only to a particular hardware model or revision. Updates require hardware-specific tooling and carry risk of bricking a device if applied incorrectly. Rollback is not always possible. And firmware persists across operating system reinstallation, which means a compromised or vulnerable firmware component survives the remediation actions that would address an application-layer vulnerability.

These characteristics mean that firmware inventories require their own collection methods, their own representation fields, and their own governance workflows. Treating firmware as a subset of an application SBOM produces incomplete records. Treating it as a subset of a hardware BOM loses the software-specific metadata needed for vulnerability correlation and update tracking.

Inventory Type	Primary Artifacts	Typical Owner	Update Mechanism	Rollback Feasibility
Hardware BOM	Physical components, part numbers, revisions	Procurement / Asset Management	Hardware replacement	Not applicable
Firmware Inventory	BIOS/UEFI images, BMC firmware, microcode, option ROMs, management agents	Infrastructure / Platform Engineering	Vendor-specific tooling, out-of-band management	Limited, hardware-dependent
Application SBOM	Packages, libraries, transitive dependencies	Development / DevSecOps	Package managers, CI/CD pipelines	Generally feasible

What to Inventory: Firmware Artifacts in Federal Build Environments

Federal build environments, development enclaves, and CI/CD infrastructure are not just software platforms. They run on physical or virtualized hardware that carries its own embedded software stack. Every server in a build farm, every network appliance in a development enclave, and every workstation used by platform engineers has firmware components that affect the integrity and trustworthiness of what gets built on top of them.

Server and Workstation Firmware

For servers and workstations, the primary firmware artifacts to inventory include the BIOS or UEFI image, the BMC firmware, and any embedded controller firmware for storage controllers, network interface cards, and GPU or accelerator cards where applicable. UEFI images in particular can contain multiple drivers and modules that are not visible at the surface level. Tools that extract UEFI images and enumerate their internal modules provide substantially more useful inventory data than simply recording the BIOS version string reported by the operating system.

BMC firmware deserves separate treatment. The BMC operates independently of the host operating system, provides out-of-band management access, and has its own network interface. A vulnerable BMC can be exploited even when the host system is powered off. BMC firmware versions should be tracked per device, correlated against vendor advisories, and included in configuration baselines with the same rigor applied to operating system patch levels.

Network Appliances and Embedded Platform Services

Network appliances used in development enclaves, including switches, routers, firewalls, and load balancers, carry firmware that is often updated infrequently and tracked inconsistently. These devices may also run vendor-supplied management agents or embedded operating systems that are not covered by standard patch management workflows. Device microcode, option ROMs used during PXE boot sequences, and vendor management agents installed on hypervisor hosts are additional firmware-adjacent components that belong in a complete inventory.

In CI/CD environments specifically, the hardware running build agents, artifact repositories, and pipeline controllers introduces firmware dependencies that affect the reproducibility and integrity of every build that runs on that infrastructure. If a build agent server is running a compromised or outdated BMC firmware version, the integrity of builds produced on that server is questionable regardless of how well the application SBOM is managed.

Collection Methods and SBOM Representation for Firmware Components

Collecting firmware inventory data requires different approaches depending on the component type. Unlike application packages, firmware components are not enumerated by a package manager. They require a combination of out-of-band query interfaces, vendor-supplied tooling, image extraction utilities, and platform management APIs.

For BIOS and UEFI images, the most reliable collection approach combines the version string reported through the operating system’s firmware interface with image-level extraction where possible. Extracting and parsing a UEFI image reveals internal modules, drivers, and their individual version metadata, which is not visible through the OS-reported BIOS version alone. This distinction matters when correlating against vulnerability databases, because a CVE may affect a specific UEFI module rather than the entire image version.

BMC firmware versions can typically be queried through the Intelligent Platform Management Interface or through vendor-specific out-of-band management interfaces. Automating this query across a fleet of servers and recording the results in a structured format is straightforward in principle but requires access to out-of-band management networks that are often segmented from standard IT management infrastructure. Teams need to account for this network access requirement when designing collection workflows.

For SBOM representation, both CycloneDX and SPDX can accommodate firmware components, but doing so effectively requires populating fields that are often left empty in application SBOMs. Critical fields for firmware components include the component type designation, cryptographic hash of the firmware image, signing certificate metadata, hardware applicability constraints such as the specific model and revision the firmware applies to, build provenance information where available from the vendor, and update dependency relationships where a firmware update requires a prior version or a specific hardware revision as a prerequisite.

Secure boot and measured-boot evidence provides a complementary data source. Secure boot status and the contents of platform configuration registers recorded during a measured boot sequence can confirm that the firmware that actually executed matches the expected baseline. This is corroborating evidence for the inventory record, not a substitute for it. A system can pass secure boot validation while running a firmware version that is known to be vulnerable, if the signing chain is valid but the vulnerability is not addressed by a signature revocation.

The relationship between a Software Bill of Materials (SBOM) and firmware inventory records is one of scope extension rather than replacement. The firmware inventory feeds into the broader SBOM governance framework, but it requires its own collection pipeline, its own representation conventions, and its own validation workflows. Teams that try to force firmware data into their existing application SBOM tooling without adapting those tools for firmware-specific fields end up with incomplete records that provide false confidence.

Handling Vendor Evidence Gaps and Opaque Components

Vendor transparency for firmware components varies considerably. Some hardware vendors publish detailed firmware release notes, component-level changelogs, signing certificate information, and build provenance data. Others publish a version string, a brief description, and a binary image with no further disclosure. Federal teams need documented processes for both scenarios, because the absence of vendor evidence does not eliminate the need for governance.

For opaque or partially disclosed firmware components, the practical approach is to document what is known, record what is unknown, and establish a risk posture for the gap. This means recording the firmware version, the hash of the binary image, the date of collection, the hardware platform it applies to, and an explicit notation that internal component disclosure is not available from the vendor. That notation is itself useful data. It tells assessors, ISSOs, and program managers that this component carries unresolved transparency risk, and it creates a documented basis for compensating controls or procurement requirements in future acquisition cycles.

Vendor attestations for firmware components are increasingly relevant in the context of federal supply chain requirements. When a vendor provides a written attestation that a firmware image was produced using secure development practices, that attestation should be captured as a linked artifact in the firmware inventory record. Attestations do not replace technical evidence, but they establish contractual accountability and create a paper trail that supports both RMF documentation and future vendor accountability discussions.

For hardware platforms where the vendor provides a firmware update service or management portal, teams should evaluate whether that service itself introduces supply chain risk. Vendor management agents that phone home for firmware updates, or that require outbound connectivity to vendor infrastructure, represent a dependency that should be documented and assessed. In air-gapped or high-security environments, these agents may need to be disabled or replaced with offline update workflows, which in turn requires maintaining a local firmware repository with validated images.

Integrating Firmware Inventories into Build and Release Governance

An inventory that no workflow consumes is an audit artifact, not an operational control. The value of a firmware inventory depends on whether it is integrated into the decisions that actually govern what gets built, approved, and deployed. For federal teams, this means connecting firmware inventory records to configuration management baselines, release gates, and RMF documentation in ways that create real accountability.

At the build stage, the firmware state of build infrastructure should be part of the build environment attestation. When a build is produced, the record of that build should include not just the application SBOM but also a reference to the firmware baseline of the hardware on which the build ran. This creates a chain of custody that allows assessors and program managers to answer a question that currently goes unanswered in most federal environments: what was the firmware state of the build infrastructure when this artifact was produced?

Release gates that currently check application SBOM completeness, vulnerability scan results, and policy compliance should be extended to include a firmware baseline check. The check does not need to be complex. At minimum, it should verify that the firmware versions running on build and test infrastructure match the approved baseline, that no known-vulnerable firmware versions are present on systems that processed the release candidate, and that any firmware updates applied since the last release were reviewed and approved through the change management process.

Rollback planning for firmware requires explicit documentation before a vulnerability response is needed. Not all firmware versions support rollback. Some hardware platforms enforce a one-way ratchet on firmware versions for security reasons. Others support rollback but require specific tooling or physical access. Teams that discover a firmware vulnerability and then learn for the first time that rollback is not supported are in a difficult position. Documenting rollback feasibility, the tooling required, and the operational risk of the rollback process for each firmware component in the inventory is work that should happen during baseline establishment, not during an incident.

For continuous monitoring, firmware inventory records should be compared against the approved baseline on a scheduled basis. Changes to firmware versions that did not go through the change management process should generate alerts. In environments where vendor management agents can apply firmware updates automatically, those agents should either be disabled or configured to require explicit approval before applying updates, and the approval workflow should be documented in the system security plan.

RMF Documentation and Assessment Considerations

From an RMF perspective, firmware inventory records support several control families, including configuration management, supply chain risk management, and system and communications protection. ISSOs and ISSMs who are building or reviewing system security plans should ensure that the plan addresses firmware as a distinct category of software component, not as an implicit subset of the operating system or application layer. Assessors who encounter a system security plan that does not address firmware configuration management have a legitimate basis for a finding, particularly for systems that process sensitive or classified information.

Vendor attestations, secure boot logs, and measured-boot records should be referenced in RMF documentation as supporting evidence for firmware integrity controls. These records do not replace the inventory, but they provide assessors with corroborating technical evidence that the firmware running on a system matches what the inventory claims.

Common Mistakes

The most common mistake is treating firmware version tracking as equivalent to firmware inventory. Recording the BIOS version string in a configuration management database is a starting point, not a complete inventory. It does not capture BMC firmware, embedded controller versions, device microcode, option ROMs, or the internal module composition of a UEFI image. Teams that believe they have a firmware inventory because they track BIOS version strings will be surprised when a vulnerability surfaces in a component they have never recorded.

A related mistake is assuming that secure boot status confirms firmware integrity. Secure boot validates that the firmware and bootloader are signed by a trusted key. It does not validate that the firmware version is current, that it is free of known vulnerabilities, or that the signing key itself has not been compromised. Secure boot is a useful control, but it is not a substitute for an inventory that tracks specific versions and correlates them against vulnerability data.

Many teams scope their firmware inventory to production systems and exclude build infrastructure, development enclaves, and CI/CD hardware. This is a significant gap. The firmware state of build infrastructure directly affects the integrity of everything built on it. A compromised or vulnerable BMC on a build server is a supply chain risk, not just an infrastructure risk.

Ownership ambiguity is a persistent problem. Firmware sits at the boundary between infrastructure teams, cybersecurity teams, and procurement. In many organizations, no single team has clear ownership of firmware inventory and update governance. Infrastructure teams may apply firmware updates without notifying the ISSO. Cybersecurity teams may not have visibility into firmware versions at all. Procurement teams may not include firmware transparency requirements in hardware acquisition contracts. Without explicit ownership assignment and documented workflows, firmware governance exists on paper but not in practice.

Finally, teams frequently fail to account for update dependencies when planning firmware updates. A firmware update for a storage controller may require a specific minimum BIOS version. A BMC firmware update may require a specific version of the vendor management agent. Applying updates without validating these dependencies can result in failed updates, device instability, or in the worst case, a bricked component. These dependencies should be documented in the firmware inventory record before an update is needed, not discovered during the update process.

Recommended Federal Approach

Start with build infrastructure, not the full enterprise asset inventory. The firmware state of servers, workstations, and network appliances used in CI/CD pipelines and development enclaves has a direct and immediate effect on build integrity. Establishing a firmware inventory for this bounded scope is achievable in a reasonable timeframe and produces immediate operational value. Expanding to broader enterprise assets can follow once the collection methods, representation formats, and governance workflows are validated.

Before collecting data, define the scope explicitly in writing. Identify which component categories are in scope, which hardware platforms are covered, and which teams own each category. Assign a named owner for firmware inventory governance. This does not need to be a new role, but it does need to be a documented responsibility with clear accountability. Without this, the inventory will be created once and then drift as hardware changes and firmware updates are applied outside the governance process.

Establish collection access before beginning the inventory sweep. Confirm that out-of-band management interfaces are reachable from the collection system, that credentials are available and documented in a privileged access management system, and that any vendor tooling required for image extraction or version query is licensed and available. Discovering access gaps during the collection effort delays the entire process and often results in incomplete coverage that is not clearly documented as incomplete.

When representing firmware components in SBOM-compatible formats, populate hardware applicability fields explicitly. A firmware record that does not specify which hardware model and revision it applies to is not useful for update planning or vulnerability correlation. Include the cryptographic hash of the firmware image, not just the version string. Hashes allow verification that the image on a system matches the expected artifact, which version strings alone cannot provide.

Integrate firmware inventory records into the change management process before the first update cycle. Define the approval workflow, the pre-update validation steps, the rollback documentation requirements, and the post-update verification procedure. Communicate this workflow to infrastructure teams before they encounter a firmware advisory that requires a response. Teams that learn about the governance workflow when they are already under pressure to apply a critical firmware patch are likely to bypass it.

For RMF integration, work with the ISSO to ensure that the system security plan addresses firmware as a distinct software category. Reference the firmware inventory, the update governance workflow, and the vendor attestation process as supporting evidence for relevant controls. If the system undergoes a continuous authorization process, include firmware baseline comparison in the continuous monitoring data feeds so that firmware drift is detected and reported on the same cadence as other configuration deviations.

In future hardware acquisition cycles, include firmware transparency requirements in procurement language. Require vendors to provide machine-readable firmware manifests, signing certificate information, and build provenance data as part of the delivery package. Require notification of firmware vulnerabilities and updates within a defined timeframe. These requirements will not be met by all vendors immediately, but establishing them in contracts creates a documented expectation and a basis for future enforcement or vendor selection decisions.