Your firmware SBOM meets every NTIA minimum element — why can't it tell a hospital whether the device is exploitable?

## The direction of the claim An SBOM answers **what is inside this artifact**. That is the whole of it. Every failure in this area comes from asking it a different question and reading its silence as an answer. A hospital biomedical-engineering team receives an infusion-pump firmware release with an SBOM that satisfies all seven minimum elements — the real-time operating system, the statically linked crypto library, every third-party module, each with supplier, name, version, identifier and relationship, plus the document's author and timestamp. An advisory then lands against the crypto library at a version in the range the SBOM lists. The team asks the vendor: is the pump exploitable? The SBOM cannot answer, and no amount of field conformance will change that. ## What the inventory does not contain **Reachability.** The vulnerable function may not be compiled into this build at all — static linking commonly pulls in only referenced objects — or it may be present and never called on any path the firmware executes. Reachability is a property of *code*: is the vulnerable routine actually invoked? An inventory entry records presence, not invocation. **Exploitability.** Even reachable code may be unreachable to an *attacker*. Exploitability is a property of the deployed system: can someone in some position — on the hospital network, at the pump's physical interface, in a compromised upstream — actually drive input into that path? The pump may parse only signed configuration over a link the vulnerable parser never sees. Reachability and exploitability are different questions and interviewers listen for candidates who keep them apart. **Mitigation and configuration.** A compiled-in hardening measure, a disabled feature flag, an inaccessible interface — all change the answer, none appear in the seven fields. **Severity and risk.** There is no severity, score or priority field in the minimum elements. Rating the consequence is downstream analysis; the SBOM is the input to it. **Origin and endorsement.** The SBOM says nothing about how the artifact was built or who vouches for it. Those claims live in different documents with different owners, and conflating them is the canonical wrong answer in this domain: what is inside, how it came to be, and who stands behind it are three separate assertions. **Completeness of the picture.** The inventory reflects what the generator could see. If the vendor's build compiled a third-party source tree in directly and the generator never saw a manifest for it, the affected code can be *in the firmware and absent from the SBOM* — which is why the guidance requires declaring known unknowns. Absence from an SBOM is not evidence of absence from the build. ## What actually answers the hospital's question Two artifacts, not one. 1. **The inventory** — accurate, per build, deep enough to include transitive components, with its gaps declared. Without it nobody can even generate the candidate list. 2. **A per-flaw exploitability statement** — the vendor's assertion, for this specific advisory and this specific product build, of whether it is affected, with a justification when it is not. This is the artifact that closes the loop, and it must be re-issued as new advisories appear against components that were already listed. The division of labour matters: the inventory is generated mechanically from the build and is stable until the build changes; the exploitability statement is analysis performed per flaw and changes constantly while the build stays fixed. Trying to fold the second into the first produces an SBOM that is stale the moment it is signed off. ## The senior judgment being tested When a customer sends you a wall of advisory hits derived from your own SBOM, the wrong reactions are to argue the SBOM was too detailed, or to treat every match as an incident. The right posture is: yes, that is the inventory working as designed; here is our analysis per flaw; here is the justification where we assess it as not affecting this build; here is our commitment on turnaround for the next one. In a safety-critical setting the answer also has to survive a regulator reading it, which means the justification is written down and attributable rather than delivered on a call. And there is a second-order point worth making: a device whose SBOM produces hundreds of unanswerable matches is telling you something about the *product*, not only about the paperwork. Statically linked, rarely rebuilt components with no update path convert every future advisory into a manual investigation. Fixing that is an engineering decision about rebuild cadence and component choice, not a documentation decision.