SBOM Management
Software Bills of Materials for medical devices: generation, monitoring, and using SBOMs as a continuous security tool, not a checkbox.
SBOMs are now mandatory for FDA cybersecurity submissions, but most teams still treat them as a one-time deliverable. These episodes show how to generate accurate SBOMs, monitor them for new vulnerabilities, link them to your threat model, and use them throughout the device lifecycle. Tooling (CycloneDX, SPDX), automation, and integration with your secure SDLC are all covered.
What an SBOM is for
A software bill of materials is a machine-readable inventory of every component in your device software: commercial libraries, open source packages, operating system elements, and off-the-shelf software, with versions, suppliers, and dependency relationships. FDA requires one in premarket submissions for cyber devices, but the regulatory obligation is the least interesting reason to maintain one.
The real value is answering a single question quickly: when a critical vulnerability is announced in a widely used library, is it in our devices, which versions, and which customers are affected? Teams without a current SBOM answer that question in weeks by reading source code. Teams with one answer it in minutes.
Generating an SBOM that holds up
Use a standard format - CycloneDX or SPDX - and generate from the build, not from a spreadsheet maintained by hand. Build-time generation catches transitive dependencies, which is where most surprises live. Firmware and embedded targets are harder: binary composition analysis is often necessary to catch statically linked components that never appear in a package manifest.
Beyond the component list, FDA expects support and end-of-support dates for each component and the level of support the supplier provides. That metadata is what turns an inventory into a risk artifact, because an unsupported component with no upstream patch path is a design decision reviewers will want justified.
From artifact to continuous control
An SBOM generated once for a submission is stale within a sprint. Mature programs regenerate on every release, store SBOMs per shipped version so they can map a CVE to a deployed population, and feed them into continuous vulnerability monitoring so new advisories are triaged automatically.
VEX - Vulnerability Exploitability eXchange - is the companion piece. Most flagged CVEs in a device SBOM are not exploitable in that device's configuration, and VEX lets you publish that assessment in a machine-readable way so hospital security teams are not chasing false positives. Connecting the SBOM to the threat model closes the loop: components carrying risk become entries in the risk file rather than a separate list nobody reads.
Hosts covering SBOM
Episodes on SBOM (9)
Need help with sbom for your medical device?
Blue Goat Cyber works with manufacturers on FDA premarket and postmarket cybersecurity. Schedule a free discovery session.
Schedule Discovery