Software Bill of Materials for Medical Devices: Contents and Incident Use

A modern medical device is a computer with a clinical function, and most of its software is written by somebody else. A software bill of materials is the list of those somebody elses: the components, libraries and open source projects that a device depends on, recorded so that a question about one of them can be answered.

Why the List Exists

When a widely used software library turns out to contain a serious vulnerability, every organisation running that library has a problem. The organisations that can identify their exposure in hours behave very differently from those that need weeks to work out which devices are affected.

For a hospital, that difference is measured in clinical availability. A device that might be vulnerable may need to be taken out of service, isolated or closely watched, and the decision depends on whether the component is present at all.

The bill of materials is what makes that question answerable without waiting for a manufacturer to reconstruct it under pressure. It is a form of documentation, and its value is realised at the worst possible moment.

What Belongs Inside

A useful bill of materials describes each component well enough that a stranger could act on it. Minimum expectations have converged around a small set of fields, and a document missing them tends to fail precisely when it is needed.

The dependency field deserves emphasis. A device manufacturer may declare the libraries it uses directly and overlook the ones those libraries pull in, which are frequently the component with the known vulnerability.

Formats and Machine Readability

A spreadsheet can hold a list, but it cannot be compared automatically against a feed of new vulnerabilities. That is why the field has settled on structured formats, with SPDX and CycloneDX the two most widely used in healthcare procurement.

The format matters less than the consistency. What a receiving organisation needs is a document that can be parsed, versioned and matched, rather than a PDF attached to a sales pack.

It also needs a version history. A bill of materials describes a specific software release, so a device that receives an update needs a new document, and the organisation needs to know which document applies to the version actually installed.

Reading One During an Incident

The practical use case is narrow and urgent. A vulnerability is published in a component, and the service needs to know whether any device in the estate contains it.

• Identify the component and the affected version range from the advisory.
• Search the bills of materials for that component, including nested dependencies.
• Confirm the installed software version on the device, since the document may describe a different release.
• Establish clinical exposure: which units are in use, on which patients and with what alternatives.
• Ask the manufacturer for a patch, a mitigation or a statement of non applicability, and record the answer.
• Decide on interim controls such as network isolation, and record why they were chosen.

Steps three and four are where most of the time is spent, and neither is a software question. The first is an inventory question, and the second is a clinical one.

What a Bill of Materials Is Not

It is not a vulnerability report. It says which components are present, not which of them are exploitable in this device, in this configuration, on this network. Presence is the beginning of an assessment, not the conclusion.

It is also not a guarantee of completeness. A manufacturer can omit a component, describe a release that is no longer installed or supply a document that has not been updated since the last patch. Trusting it without verification is a category of risk in itself.

And it is not a substitute for the security work that surrounds it. Network segmentation, patching discipline and monitoring are what limit the consequences of a component becoming vulnerable, as described in network segmentation for medical IT.

Using It in Procurement

The most effective moment to ask for a bill of materials is before the purchase. A requirement in the tender, with a defined format and an obligation to update it with each release, costs nothing at that stage and saves an unquantifiable amount later.

Contracts should also cover the response obligation: notification of a vulnerability affecting a supplied component, a timeline for a fix or mitigation, and support for the device after the manufacturer stops producing updates.

Where a supplier cannot provide a document at all, that is itself useful information. It tells you how the supplier is likely to behave when a component fails, and it belongs in the risk assessment for the purchase.

Where It Fits in Hospital Practice

For a technology management service, the bill of materials belongs in the asset record alongside the installed software version. Keeping them together means the question about a component can be answered from the same place as the question about a device.

It also belongs in the conversation with the security team, who maintain their own view of what is on the network. A shared vocabulary between engineering and security is what makes vulnerability management practical rather than theoretical.

A Document That Earns Its Place

A bill of materials is unexciting until the day it is essential, and on that day it is worth more than most of the documentation a hospital holds. The organisations that treat it as a living record, updated with every release and stored with the asset, are the ones that can answer the question while the answer still helps.

The rest discover that they own a device whose software they cannot describe, at the moment when describing it is the only thing that matters.