Attendees at the recent RSA Conference were bombarded with information (many would call it “noise”) about SBOMs. Why all the brouhaha? Because many industry verticals—automotive, US government, energy, medical devices—now require an SBOM as part of their software procurements or approvals. If you’re one of those software producers that has to deliver an SBOM, or if you’re a consumer of software that is requiring SBOMs from your suppliers, then you are facing a cacophony of vendors, each singing the praises of their SBOM offering.
Let’s cut through that noise and get to a few really important takeaways that every medical device manufacturer (MDM) (and other regulated industry manufacturers) in the world should be aware of about SBOMs. These are six “must knows” regardless of whether your role is security, engineering, regulatory, quality control, or operations.
Fundamentals – Feel free to skip this if you’re an SBOM expert.
- Starting in October 2023, FDA requires all MDMs to submit SBOMs and identify all known vulnerabilities as part of their premarket approval processes, along with the submission of a postmarket plan to continuously monitor the deployed device for vulnerabilities. The reasoning behind these new requirements is straightforward: Medical devices incorporate significant amounts of software over their lifetime that may put patient safety at risk through software vulnerabilities, quality flaws or lack of maintenance. The FDA needs to assess these risks prior to approval, consumers of these devices (e.g., hospitals, other MDMs, field reps supporting the devices) need an SBOM to assess risks after market release. In short, an SBOM is required to support the software transparency needed to rapidly detect and respond to current and future software vulnerabilities and flaws. (These webinars on FDA cybersecurity requirements are good resources for more information.)
- An SBOM is a list of ingredients in a piece of software. It specifies the components used to build the software details and their dependencies. It is typically delivered by a software producer in one of three standard formats: SPDX, CycloneDX, or SWID (the first two being the more common). The National Telecommunications and Information Administration (NTIA) established a minimum number of fields for inclusion in an SBOM: supplier name, component name, version, other unique identifiers, dependency relationship, author, and timestamp. (See this primer on SBOM for more info.)
Must Knows – What many people don’t realize
- Not all SBOMs meet FDA requirements. Some organizations just list the open-source components and the minimum NTIA fields. But the FDA requires a “robust” SBOM, which includes commercial, open-source, and off-the-shelf components used in a medical device. FDA also requires other information be added to the SBOM, e.g., origin of each software component, known vulnerability information, support status, and end of support/life dates. Without all these required fields, the FDA may reject the SBOM during the preapproval process.
- Producing an SBOM is not enough to meet regulated industry requirements. An SBOM is part of a larger ecosystem that keeps track of the software’s components from initial build through the product’s end-of-life. This ecosystem—referred to as SBOM Lifecycle Management—provides visibility into the software’s risks through all its entire lifecycle. An SBOM Lifecycle Management system is essential to both producers and consumers of software for:
- The primary users of an SBOM Lifecycle Management system are Software Producers (aka Authors) and Consumers. Other major user roles include SBOM Distributor and cybersecurity professionals. (The US Cybersecurity & Infrastructure Security Agency (CISA) has produced an excellent document on SBOM Sharing Roles.) In MedTech—or any manufacturing where software is part of the product–the manufacturer is the Producer/Author of an SBOM. However, the manufacturer who is assembling a device or product from suppliers may also be the Consumer of the SBOMs produced by upstream suppliers. Other examples of Consumers include Product Security Incident Response Teams (PSIRTs), risk/compliance officers, procurement officers, hospitals, the FDA and other regulatory authorities. Distributors pass SBOMs from authors to consumers; for example, a third-party repository or vendor could serve as a distribution intermediary. SBOM distribution networks are still in the early stages of maturity.
The table below shows some of the major differences in how Software Producers and Consumers use an SBOM Lifecycle Management system.
- Managing SBOMs at scale requires automation. Gone are the days when SBOMs could be delivered in Excel formats and shared via email. All that functionality listed in Item 4 needs automation for speed and scalability. Patching this together with a kludge of manual and automated processes will be inefficient, time-consuming and hard to maintain. If you’re either a software producer or consumer in a regulated industry requiring SBOMs you should just commit now to getting an automated SBOM Lifecycle Management system. If you’re in healthcare, add MedTech expertise to your vendor selection, as the FDA poses specific requirements on SBOM management.
What to Ask Yourself – Given these takeaways, as a medical device manufacturer, ask yourself three questions:
- Do the SBOMS we are producing, or receiving from our suppliers, meet FDA’s requirements? Do they contain commercial, open-source and off-the-shelf components? And do they provide the specific information that FDA requires that goes beyond minimum NTIA fields?
- As a Software Producer, do I have fast and scalable processes for SBOM Generation, Distribution, Monitoring and Compliance tracking?
- As a Software Consumer, do I have a fast and scalable method for SBOM Ingestion, Integration, Monitoring and Notification?
As you ponder these questions, look at the Vigilant Ops SBOM Lifecycle Management platform for examples of how a group of MedTech cybersecurity experts answer them. For more information, please reach out to info@vigilant-ops.com.
Written by: Anita D’Amico, PhD is a cybersecurity expert and research psychologist, who for the past 15 years has been dedicated to improving the use and comprehension of application security information. She is President of Cotopaxi Consulting LLC, focused on accelerating the maturation and adoption of application security and supply chain security technology. In 2023, as a VP in the Synopsys Software Integrity Group, she led their software supply chain security strategy. She was the CEO of Code Dx, Inc., a leader in the AppSec Posture Management space, prior to its acquisition by Synopsys.
