This expert guide covers best practices for healthcare SBOMs, including general guidelines and specific tips for IT and medical devices. Learn to optimize SBOM formats and types, and download a free cheat sheet for quick reference.
Best practices for healthcare SBOMs
The best practices for healthcare SBOMs include mapping your software system, using automation, and defining your scope. It's also important to focus only on relevant security risks. These steps go beyond the basics and help make SBOMs more useful for different applications.
An SBOM (software bill of materials) is a structured digital inventory of all software components — including code, libraries, and third-party dependencies — used within a system. Ideally, SBOMs are machine-readable. In healthcare, an SBOM improves cybersecurity by increasing transparency in the software supply chain and helping identify vulnerabilities across components.
General SBOM best practices apply to anyone creating, managing, or distributing SBOMs in healthcare, including those for medical devices and other healthcare software. They go beyond basic rules to build secure, efficient SBOMs that support many use cases across healthcare. By adopting these practices, organizations can move beyond viewing SBOMs as a compliance task and integrate them into an ongoing process that strengthens security across an increasingly connected healthcare software environment.
Here’s a list of key SBOM best practices for healthcare:
- Build an architectural diagram with dependency mapping
Doug Shaw, owner of DShaw Consulting LLC, recommends starting with an architectural diagram — a visual map of software components and their interactions — as the foundation of a comprehensive SBOM. With over 30 years of experience in life sciences, Shaw specializes in technology compliance strategies that help organizations meet regulatory requirements, maintain operational efficiency, and achieve business goals.
Shaw says these diagrams help teams understand dependencies, data flows, and security risks, but they require the right expertise.
“Creating an architectural diagram isn’t straightforward,” he explains. “It requires input from subject matter experts from different teams, including software engineers, cloud service providers, and security professionals. Organizations need to identify and bring together the right experts to ensure that the architecture diagrams accurately represent the system’s architecture, including integrations with third-party systems and networks. Once teams establish this architectural view, they can extract the relevant SBOM elements and perform a risk assessment.”
Here’s how to implement this best practice:
-
- Involve key experts early
Bring in software engineers, cloud service providers, and security professionals at the start of the process.
-
- Map software dependencies
Collaborate to build an architectural diagram that maps software dependencies and potential security risks.
-
- Create a complete inventory
Include commercial, open-source, and custom code to ensure a complete and accurate SBOM.
- Consider external systems in your SBOM boundaries
An SBOM isn’t just about listing software components — it also needs to account for external systems that interact with your product.
"One of the most important parts of an SBOM is knowing what you control and what you don’t," says Shaw. “The FDA requires an SBOM for the device itself, but you need to separate parts you fully understand — your 'white box' components — from third-party or off-the-shelf ('black box') components that you can’t see as clearly. Both need cybersecurity risk checks, but the approach is different. For your own code and hardware, you can find and fix issues directly. For third-party software or cloud services, you have to rely on vendor documents, security certifications, and contracts since you don’t have full access."
Shaw adds, "Even if an external system isn’t part of your main product, its connection to it can create security risks, so it needs to be considered in threat modeling. For example, business software like customer databases, APIs, financial systems, or supply chain platforms could introduce vulnerabilities. You also need to look deeper into how the software works — what tools and frameworks handle data processing, storage, and movement? What third-party components are involved? Understanding these connections is key to managing cybersecurity risks."
Here’s how to implement this best practice:
-
- Focus on security-critical software
Identify software that directly impacts security and exclude tools that don’t contribute to device function or risk.
-
- Evaluate external connections
Assess external connections and dependencies to determine if they introduce vulnerabilities.
- Include FDA-recommended fields
Alongside the minimum fields that the FDA requires in an SBOM, the National Telecommunications and Information Administration (NTIA) recommends including additional data to make the SBOM more useful for different use cases.
In its 2021 document “The Minimum Elements for an SBOM,” the NTIA strongly recommends including the following data fields whenever possible:
- Component hash: A unique identifier to track software components against vulnerability databases
-
- Lifecycle phase: Information about the software’s development, deployment, and maintenance stage
-
- License information: License data to help users understand whether they can use the software in another application without any legal risk
-
- Component relationships: A map of dependencies between software elements
- Use unique identifiers for each software component
When listing software components in an SBOM, it's crucial to avoid ambiguity. Many software packages have similar names or versions, which can cause confusion when tracking vulnerabilities or dependencies.
To implement this best practice, experts recommend using:
- CPE (Common Platform Enumeration) to track vulnerabilities
-
- PURL (Package URLs) to identify software packages accurately
- Automate SBOM updates throughout development
"Keeping SBOMs up to date is an often overlooked but essential best practice in healthcare tech," says Micah Spieler, Chief Product Officer at Strike Graph. "Many organizations may create an SBOM at launch but fail to maintain it over time. “This practice is risky because new vulnerabilities emerge in third-party software components regularly. If you’re not actively maintaining and monitoring an SBOM, you’re leaving your software open to potential risks.”
Automating SBOM updates ensures that healthcare providers (HCPs) and other users always have the latest security and software information without needing to manually check for updates. Since medical and cyber devices frequently receive security patches, software fixes, and performance improvements, keeping SBOMs updated is critical for maintaining security and compliance.
To implement this best practice:
-
- Use automated tools to update SBOMs in real time
Organizations should invest in SBOM management tools that continuously track software components and update the SBOM whenever changes occur. These tools detect and log modifications — such as software patches, new dependencies, or security updates — so the SBOM remains accurate throughout the device lifecycle.
-
- Deliver updates through a secure communication system
Use a trusted communication channel, like a publish/subscribe system, to push SBOM updates to all connected devices and users.
-
- Ensure accurate versioning
Make sure you include specific version information for all components.
- Track vulnerability data separately for better security mapping
The NTIA’s 2021 document titled “The Minimum Elements for an SBOM” explains that not all vulnerabilities pose a security threat. “Some vendor data suggests that a relatively small percentage of vulnerable components have a security impact in the environment where that software is deployed. In the SBOM context, focusing on upstream, vulnerable components that don’t have an impact on the downstream software will waste time and resources, without offering immediate security benefits.”
In other words, organizations need to distinguish between exploitable and non-exploitable vulnerabilities so they can focus on vulnerabilities that require action.
To implement this best practice:
- Integrate Vulnerability Exploitability eXchange (VEX) into SBOM processes
A VEX is a process that assesses whether a vulnerability affects the software. It helps organizations distinguish whether they need to include a vulnerability in the SBOM.
- Link CVEs (Common vulnerabilities and exposures) to affected components
CVEs are well-known vulnerabilities that experts track in public databases. Linking CVEs to SBOM components makes it easier to assess whether a known vulnerability affects a specific system.
- Use automated vulnerability scanning
“SBOMs should be checked against vulnerability databases on a scheduled basis,” says Spieler. “The industry needs to move toward proactive risk management rather than treating SBOMs as one-time checkboxes."
- Address third-party software risks through vendor management
Shaw explains that managing third-party software in SBOMs can be challenging but is essential to creating an accurate SBOM.
“Many cloud providers or SaaS vendors understandably will not disclose every component in their software stack due to intellectual property concerns," he explains. "When organizations can't get full SBOM visibility, they need other ways to reduce risks from third-party networks and systems. They can assess vendors by reviewing cybersecurity practices through audits, questionnaires, and certifications. Understanding these connections is key to managing cybersecurity risks.”
Spieler also emphasizes the importance of properly screening third-party vendors. “The biggest security risks often come from vulnerabilities in third-party software components,” he says. “You might not have written those vulnerabilities, but they may exist within the packages you use.”
To implement this best practice:
-
- Ensure your third-party vendors implement robust security practices
Conduct security audits, send cybersecurity questionnaires, and partner with third-party vendors who have relevant compliance certifications that demonstrate their commitment to strong cybersecurity.
- Document your process
Document the steps and rationale you use to mitigate risks with third-party vendors. These steps will help you demonstrate how you ensure strong software security when full SBOM transparency isn’t possible.
- Use digital signatures to ensure SBOM integrity and authenticity
In its document “The Minimum Elements for an SBOM,” the NTIA strongly recommends that organizations supply digital signatures to give SBOM consumers peace of mind that another party did not tamper with the SBOM.
- Classify SBOMs as sensitive or confidential information
Organizations should classify SBOMs as sensitive and enforce strict security policies to prevent unauthorized access, says Aude Chetwynd, owner of Technical and Professional Services LLC. Chetwynd has over 20 years of experience in the medical device industry, with extensive experience in implementing software development to help companies comply with regulations from agencies such as the FDA.
“The purpose of an SBOM is to provide visibility into the software so organizations can manage security risks and make informed decisions about their software supply chain,” she says. “However, if an SBOM falls into the wrong hands, this transparency could give attackers a roadmap to exploit vulnerabilities. Keeping SBOMs internal and avoiding public distribution prevents unnecessary risks.”
To implement this best practice:
- Share SBOMs only with trusted partners.
-
- Formally classify your SBOM as sensitive or classified.
- Use machine-readable formats whenever possible
The FDA strongly recommends that organizations produce SBOMs in machine-readable formats like SPDX and CycloneDX. These formats are ideal because certain software can automatically read and analyze the SBOM.
Generally, the FDA expects organizations to treat these formats as the standard for creating and sharing SBOMs. However, the FDA allows organizations to submit spreadsheet-based SBOMs when it’s more practical.
"Machine-readable SBOMs are often ideal, but they might not be practical for small start-up companies,” Chetwynd says. “If a company develops a single device, investing in automation tools isn’t always a priority. Many early-stage products don’t have complex software, so a spreadsheet-based SBOM might work fine. If an SBOM only contains 15 rows, a dedicated tool isn’t worth the investment.”
To implement this best practice:
- Use machine-readable formats
If possible, create your SBOM in a machine-readable format like SPDX or Cyclone. DX. Smaller companies can start with spreadsheet-based SBOMs before investing in automation.
Best practices for medical device SBOMs
The best practices for medical device SBOMs start with change management for FDA-regulated devices. Also, you should track software lifecycles and rank security risks based on their patient impact. These steps protect critical devices, such as pacemakers and hospital equipment.
Medical device manufacturers must submit a software bill of materials (SBOM) as part of the FDA approval process. Because these devices have longer lifespans and stricter safety requirements than other healthcare software, their SBOMs must meet the FDA’s regulatory standards. To simplify compliance, manufacturers can structure SBOMs to align with the FDA eSTAR format, which provides a standardized template for submitting regulatory information.
In addition to an SBOM, the FDA requires manufacturers to adopt a Secure Product Development Framework (SPDF) to identify and reduce vulnerabilities throughout the product’s lifecycle. Together, SBOMs and SPDFs improve software transparency and security, ensuring devices remain protected against emerging threats.
Beyond these regulatory requirements, following best practices for medical device SBOMs helps manufacturers strengthen security, manage risks, and maintain compliance more efficiently.
Example of a medical device SBOM
Here’s a summary of key best practices for medical device SBOMs:
- Follow stricter change management for FDA-regulated devices
It’s important to update any SBOM, but FDA-regulated devices should receive additional scrutiny. Organizations should implement and follow strict change management processes for these SBOMs. Any change in software or updates must be properly documented. Otherwise, a security update could make a device non-compliant with the FDA or introduce new risks.
To implement this best practice:
- Keep detailed records of software updates, patches, and fixes.
-
- Save each SBOM version to show how it’s changed over time.
- Use FDA-compliant methods for medical devices (like those outlined in ISO 13485, the international standard for medical device quality management systems).
- Track component lifecycles
Medical device hardware lasts much longer than most software, which means operating systems, software libraries, and other dependencies may become outdated before the device reaches the end of its usable life. If a critical software component reaches end-of-life (EOL), it may stop receiving security updates, leaving the device vulnerable to cyberattacks. Without lifecycle tracking, devices may continue using outdated components without security patches, creating serious cybersecurity risks.
To implement this best practice:
-
- Include EOL dates for each software component in the SBOM metadata.
- Use SBOM automation tools that pull lifecycle status from vendor databases and update the SBOM when a component reaches EOL.
- Prioritize risks based on the device’s safety classification
Medical devices carry varying levels of risk based on their intended use and potential impact on patients. A cybersecurity vulnerability in a life-critical device, such as a pacemaker, poses a significantly greater risk than in a lower-risk device, like a smartwatch.
“The depth and rigor of cybersecurity documentation like SBOMs, testing, and both pre- and post-market security efforts should match the device’s risk level,” explains Shaw. “High-risk devices need thorough assessments, while lower-risk devices don’t need the same level of scrutiny. This approach ensures that you’re addressing critical threats without directing resources where it’s not needed.”
To implement this best practice:
-
- Document the device’s safety classifications in the SBOM metadata.
- Use VEX (Vulnerability Exploitability eXchange) data within the SBOM to show whether a vulnerability is exploitable in the specific device.
- Clarify the scope of your medical device SBOM
While the NTIA’s definition of an SBOM allows for a broad interpretation of “software system” that may include hardware components — such as embedded systems or microcode — the primary focus of SBOM best practices remains squarely on software.
Firmware, as a type of software, should always be included. True hardware elements (such as Wi-Fi modules or processors) are not excluded by NTIA’s framing but are generally not required by current regulatory guidance, including from the FDA.
In fact, the FDA’s 2023 final cybersecurity guidance defines the SBOM as a software inventory and does not include physical hardware components in its scope. As a result, while documenting hardware may be useful for broader risk assessments, it falls outside the scope of what regulators and most industry stakeholders currently expect from an SBOM.
Best practices for healthcare IT SBOMs
Healthcare IT SBOMs should list APIs, track data flow, and document cloud services. These steps keep software safe, protect patient data, and help healthcare systems work together. They also help organizations manage risks as healthcare software becomes more connected.
Unlike medical devices, healthcare IT systems focus on software infrastructure, data flow, and interoperability rather than physical hardware. These considerations ensure that healthcare software remains reliable and secure in increasingly connected healthcare environments.
Here’s a list of specific best practices for healthcare IT SBOMs:
- Integrate API documentation with SBOMs
Healthcare IT relies on APIs (Application Programming Interfaces) to connect various software components, ranging from Electronic Health Record (EHR) systems to patient management tools. Including APIs in SBOMs helps track dependencies between software components. In any case, APIs handle sensitive patient data so tracking them is critical for ensuring patient security and privacy.
To implement this best practice:
-
- List API dependencies in the SBOMs, including versions.
- Document security protocols that each API uses.
- Track the API update history.
- Map data flow between software components
Unlike standalone applications, healthcare IT systems involve multiple software components that exchange data across networks.
To implement this best practice:
- Include data flow mapping in your SBOM to show how information moves between components.
- Track any dependencies that affect data security, such as middleware.
- Document cloud service dependencies in SBOMs
Many healthcare IT systems rely on cloud-based services for data storage, analytics, and telehealth platforms. SBOMs should document cloud service dependencies to ensure security and compliance with healthcare data regulations.
To implement this best practice:
- List cloud service providers (e.g., Azure, Google).
- Track which software components are hosted in the cloud.
- Include interoperability standards
Healthcare IT systems must comply with industry standards to ensure seamless data exchange between platforms. FHIR (Fast Healthcare Interoperability Resources), HL7, and DICOM are examples of critical standards for healthcare software.
Here’s how to include this information in an SBOM:
-
- Document supported interoperability standards for each component.
-
- Track compatibility updates when a new standard takes effect.
Downloadable cheat sheet on medical SBOM best practices
Stay on top of key SBOM best practices for medical devices and healthcare IT. Download our free medical industry SBOM best practices cheat sheet for clear, actionable guidance to improve security, manage risks, and optimize your SBOM.
Application Security Management and the New SBOM with Idan Plotnik
Justin Beals, founder and CEO of Strike Graph, speaks with Idan Poltnik, co-founder and CEO of Apiiro, about application security management and SBOMs.
Best practices for different types of healthcare SBOMs
There are three types of healthcare SBOMs: Minimum, Comprehensive, and Machine-Readable. While they share some best practices, each has its own guidelines tailored to its specific purpose. Differences include what data to include, how to organize metadata, and how to map software components for security and compliance.
The three types of SBOMs serve different needs in healthcare. Here’s how they compare:
- Minimum SBOMs list only the most essential software details for basic compliance and for startup teams with limited resources, who may want to minimize the costs of SBOMs. They help companies meet basic requirements
- Comprehensive SBOMs include full metadata and detailed security analysis and vulnerability mapping. They include detailed security insights.
- Machine-readable SBOMs use formats like CycloneDX and SWID, so automated security tools can read them.
Each type has a specific purpose, so it’s important to follow best practices to make sure the SBOM meets its goal.
Here are the best practices for each type of SBOM:
- Minimum SBOMs
- Best for: Startups that are still developing their devices, legacy systems, initial compliance efforts
-
- Best practices:
- List key software details (prioritize accuracy over completeness).
- Prioritize highest-risk components.
- Document manual verification steps to track software.
- Comprehensive SBOMs
- Best for: Critical systems, high-security applications, regulatory documentation
- Best practices:
- Include rich metadata, like software licenses and sources.
- Document configuration details that affect security.
- Map components to threat models to track risks.
-
- Best for: Integration with security tools, automated vulnerability scanning, supply chain risk management
- Best practices:
- Use a common format (e.g., SPDX, Cyclone DX, SWID).
- Test SBOM data with security tools to make sure it works.
- Use consistent names for software components to avoid errors.
Best practices for SPDX and CycloneDX align with their main purposes: SPDX for license tracking and CycloneDX for security. SWID, while not a full SBOM format, complements them by tracking installed software. Each format has unique best practices for specific use cases.
Machine-readable SBOMs use data formats and standards to organize SBOM information in a way that machines can automatically process. It saves organizations manual effort because the security tool can automatically check for problems, track updates, and manage licenses.
There are two main machine-readable formats: Cyclone DX and SPDX. For specific use cases, organizations also use another form, SWID, alongside Cyclone DX or SPDX. Each SBOM format has unique strengths and best practices. Reviewing medical device SBOM examples in different formats helps users compare their structures, understand the differences, and identify key use cases.
Here’s a comparison of machine-readable SBOM formats:
- SPDX (Software Package Data Exchange):
Primary use case: Compliance
SPDX is best for tracking software licenses and understanding software’s open-source and proprietary components. It’s best for communicating and understanding legal rules.
Best practices:
- Use relationship fields to show how software parts connect.
- Follow SPDX license expression syntax.
- Include copyright and attribution details.
- Cyclone DX:
Primary use case: Security
CycloneDX is a leading choice for cybersecurity and vulnerability management. It includes detailed security attributes that help organizations identify risks in software. CycloneDX supports various SBOM extensions, including the Cryptography Bill of Materials (CBOM). A CBOM functions like an SBOM, but instead of tracking software components, it provides a detailed inventory of cryptographic elements such as algorithms, keys, and certificates within a software system.
Best practices:
- Use dependency graphs to show how software parts rely on each other.
- Document software supply chain details to track where components come from
- Include cryptographic hashes.
- Use the Cyclone DX “services” feature to track APIS that interact with the software.
- SWID (Software Identification Tags):
Primary use case: Inventory
SWID is not a full SBOM format, so it cannot represent an entire SBOM on its own. However, organizations use SWID tags in conjunction with SPDX or CycloneDX to track installed software and updates. SWID tracks what’s installed on a system, while SPDX and CycloneDX track what’s included in the SBOM before deployment.
Best practices:
- Use entity roles to show who created, updated, or removed software components.
- Link SWID tags to patch management systems.
The easiest way to generate and manage healthcare SBOMs for compliance
Strike Graph’s compliance software simplifies SBOM management. Automated tools scan for vulnerabilities, flag issues, and give you a clear view of your software supply chain. The system also provides actionable insights to help update SBOMs, stay compliant, and take a proactive approach to security.
SBOMs are the future of healthcare cybersecurity. Managing and updating them begins with a robust compliance framework, such as Strike Graph. The system helps companies align with industry security standards, manage cybersecurity for medical devices and healthcare IT, and prepare for FDA approval.
Strike Graph automatically retrieves the latest SBOM from your pipeline, runs vulnerability scans, and flags critical risks. Compliance managers gain clear visibility into software components and receive guidance on resolving security threats. While your pipeline generates the SBOM file, the system analyzes it against known vulnerabilities and provides actionable insights. See Strike Graph's SBOM manager in action today by booking a demo.
Strike Graph’s automated evidence collection consolidates compliance data into a single platform, allowing you to reuse the same evidence — including an SBOM — to meet multiple healthcare compliance standards, including FDA and HIPAA.
For any medical device or healthcare IT company seeking to scale its security alongside its operations, Strike Graph is a powerful solution.