Every server you operate has a small computer inside it that you almost never think about, and that small computer has more privilege over the rest of the machine than your operating system does. The baseboard management controller (BMC) — usually an ASPEED or Nuvoton SoC running a vendor-customized Linux build with a web UI, an SSH daemon, an IPMI stack, and a Redfish endpoint — turns on before the host CPU, sits on a dedicated management network that is often less segmented than people assume, and continues running even when the host is powered off. Its firmware is shipped to your datacenter as a signed binary blob by an OEM (Dell, HPE, Supermicro, Lenovo) that licensed most of the code from an independent BIOS/BMC vendor (AMI, Insyde, Phoenix), who in turn assembled it from a stack of open source components, third-party drivers, and proprietary integration layers that the OEM rarely audits at the source level.
That is the supply chain you forgot you had. It is the layer that sits underneath your container scanner, underneath your endpoint agent, underneath your hypervisor's attestation, and the layer that the MegaRAC incidents — a sequence of CVEs and reported breaches affecting American Megatrends' BMC reference codebase between 2022 and 2025 — proved was not getting the same supply-chain scrutiny as the software running above it. This post is about what that gap looks like, why it exists, and what changes when you treat BMC firmware as a first-class artifact in your SBOM coverage.
What does a BMC actually do, and why does that make it interesting to attackers?
A BMC's job is to make a server manageable when nothing else on the server works, which means it has to be able to reach across every important interface on the board: it can read and write the host's memory over PCIe, control the host's power and reset lines, present virtual media to boot from, intercept the serial console, and on many platforms reflash the host's UEFI firmware without involving the host OS at all. From an attacker's perspective, a compromised BMC is the closest thing to physical access you can get remotely. You can boot an attacker-supplied OS image, you can read the host's RAM after the OS has decrypted the disk, and you can persist below the level that any EDR product can see.
The MegaRAC reports stretched across several distinct issue classes — hardcoded credentials, missing authentication on Redfish endpoints, command injection in the web UI, and the BMC&C disclosure that documented an entire attacker toolkit — and the unifying lesson was not that any individual bug was unique but that the same code, supplied by AMI under license to a long list of OEMs, was deployed in millions of servers and patched on the OEM's schedule rather than the upstream vendor's. When a single supplier sits between hundreds of OEMs and millions of operators, fixes have to traverse two integration boundaries before they reach a customer, and that latency is the supply-chain risk.
Why is BMC firmware so hard to put in an SBOM?
The honest answer is that most BMC firmware is shipped as a flat binary image without a manifest, and the OEM that signs the image is often not the party with the deepest knowledge of what is inside it. The reference codebase from AMI or Insyde pulls in the OpenBMC project as an upstream where applicable, mixes in proprietary IPMI and Redfish stacks, layers OEM-specific drivers on top, and the resulting image is built from a Yocto-style recipe that the OEM may or may not preserve in a form that survives release. By the time the image lands on your server, the chain of custody from upstream commit to flashed binary has been compressed into a version string and a checksum.
The CycloneDX and SPDX communities have been pushing firmware-specific extensions for several years now, and tools like the Binarly Transparency Platform and CHIPSEC have made it possible to extract structured component lists from firmware images even without vendor cooperation. The path forward is increasingly clear: treat the firmware image like any other artifact, run it through a firmware-aware SBOM generator at ingest, store the resulting component list alongside the SBOMs for your container images and your application dependencies, and re-evaluate it against new vulnerability data on the same cadence. The harder question is organizational — who owns BMC firmware risk inside your company, and do they have the same tooling and the same review cadence as the team that owns container images?
How should the OEM-to-operator handoff actually work?
The OEMs publish update bundles, the BIOS/BMC vendors publish advisories, and somewhere in between an operator has to decide whether a given update is urgent, safe, and compatible with the rest of the fleet. The default workflow at most organizations is calendar-driven (we patch firmware at the next maintenance window) rather than risk-driven (this CVE is exploitable on our exposed BMCs and we are rolling a fix today), and that default is a holdover from an era when BMC firmware was assumed to be unreachable from the network. That assumption no longer holds. Even when management networks are formally isolated, jump hosts and out-of-band consoles routinely create paths that an attacker can chain.
The shift that mature operators have been making is to wire BMC firmware advisories into the same risk-scoring pipeline that already handles application CVEs. When AMI publishes a fix for a Redfish authentication bypass, the advisory flows into the same triage queue as a Log4j-class issue in a container image, and the response time targets are calibrated to the actual blast radius rather than to historical norms. That requires structured data from the vendors, which is finally starting to land in the form of CSAF VEX documents and signed advisory feeds, and it requires consumers to ingest those feeds rather than waiting for an OEM to send a PDF.
What does firmware SBOM coverage look like in practice?
In practice it looks like a parallel pipeline to the one you already run for application code, with three differences worth naming. First, the inputs are binary images rather than source manifests, so you need binary analysis tools (Binarly, CHIPSEC, EFIPWN, the OpenBMC Yocto toolchain) in addition to whatever you use for package manifests. Second, the cadence is slower — firmware ships less often than libraries, so the value of a fresh scan is concentrated around each release rather than spread across the week. Third, the policy gates have to account for the fact that some firmware components are not patchable until the OEM ships a new image, which means your VEX statements need to distinguish between "we have a fix" and "we have a mitigation and are waiting on the supplier."
The benefit of doing the work is that you stop being surprised. When the next MegaRAC-class issue lands, you already know how many of your BMCs are running affected versions, you already know which of those are reachable from networks you do not fully control, and you have a remediation plan that does not depend on the OEM's PR cycle to start moving. The operators who have invested in firmware SBOM coverage describe it less as a security capability and more as a procurement and operations capability, because the same data that lights up a vulnerability also tells you which vendors are slow to patch, which platforms have unsustainable dependency stacks, and which acquisition decisions are quietly increasing your exposure.
How Safeguard Helps
Safeguard treats firmware as a first-class artifact alongside container images and application dependencies, ingesting CycloneDX and SPDX firmware SBOMs, normalizing component identifiers, and correlating them against the same vulnerability and exploitability data we use for the rest of the stack. Griffin AI can answer questions like "which of our BMCs are running an AMI MegaRAC version affected by CVE-2024-XXXXX and reachable from the corporate management VLAN" and drive a remediation plan that respects the OEM's update cadence. Our TPRM scoring includes firmware suppliers as named entities, so AMI, Insyde, and your OEMs are scored on patch latency, advisory completeness, and historical incident response rather than treated as opaque vendors. Policy gates can block a server build from going into production with a BMC running unpatched firmware or with a Redfish stack that fails attestation. If you want to see your firmware exposure on the same dashboard as the rest of your supply chain, get in touch.