Software Transparency and SBOMs
Download the Full Velentium Medical Guide to Software Transparency and SBOMs
This guide introduces Software Bill of Materials (SBOM) concepts, standards, terminology, and practical guidance for medical device manufacturers (MDMs). It explains what an SBOM is, what information it contains, why it matters, and how it supports modern regulatory expectations including the FDA’s Premarket and Postmarket Cybersecurity Guidance.
An SBOM is a structured inventory of the software components that make up a product. SBOMs provide transparency into a device’s software supply chain, enabling manufacturers to manage cybersecurity risks, understand component maintenance obligations, and respond quickly when new vulnerabilities are disclosed.
An SBOM is for software what a nutrition label is for food; it is not a recipe but instead a list of ingredients used to create a product. Each ingredient is a software component, often developed by different suppliers. These components each have versions, update histories, support statuses, and sometimes vulnerabilities. The SBOM records all components used to create the device, similar to how a nutrition label lists all ingredients in packaged food. In everyday terms, an SBOM answers: “What software is inside this medical device?” This information is essential because manufacturers cannot secure or maintain what they do not know they rely on. There are two types of SBOMs:
Human-Readable SBOMs are easy to read and understand, usually in a table format. See Section 5.0 for an example of a human-readable SBOM table ready for regulatory submission and external sharing.
Machine-Readable SBOMs are actionable and automatable, meaning a machine can process them due to their standardized format and structure. See Section 11.0 for an example of a machine-readable SBOM in CycloneDX SBOM format as a JSON data structure.
Direct and Transitive Dependencies
SBOMs boil down to lists of software components that developers include within their software items. These third-party software components are known as dependencies. Most software depends not only on components a developer explicitly includes, known as direct dependencies, but also on the dependencies those components bring into the project, referred to as transitive dependencies. Dependency relationships are important to document in SBOMs and communicate for full transparency into the software we develop and use.
Figure 1. Dependency graph of the Example Medical Device Firmware (see SBOM shown in Table 1 below), demonstrating the relationship between the Primary Component, its Direct Dependencies, and their Transitive Dependencies
Human-Readable SBOM Example
The below table provides an example of a human-readable SBOM for the firmware of a fake medical device. This kind of table is typically included in an SBOM Support Report for FDA eSTAR submissions. A simple example of a machine-readable version of the same SBOM is included towards then end of this blog.
Table 1. Example of human-readable SBOM table for the ACME Example Device Firmware as the primary component
Machine-Readable SBOM Example
An example of a machine-readable SBOM in CycloneDX format as a JSON data structure is provided below for a fake medical device system (with only direct dependencies shown for simplicity). Each section of the SBOM is color-coded with notes to the right summarizing the purpose of the sections.
