SBOM Data Normalization in Medical Devices: 8 Takeaways From MITRE's New White Paper
The MITRE Corporation says stakeholders should work together to normalize how software bill of materials are implemented in a newly published white paper.
This breakdown is available for paid subscribers. Only paid subscribers get regular full access to our breakdowns and other analyses. If you’re not already a paid subscriber, you can upgrade here.
Software Bills of Materials (SBOMs) are essentially lists that outline the components of software and the relationships between them. They have become crucial for enhancing software security and managing risks in the software supply chain.
SBOMs allow for proactive measures to mitigate risks during development and enable prompt responses to emerging risks in deployed devices. The FDA has long acknowledged the significance of SBOMs in addressing software vulnerabilities in medical devices and in ensuring transparency for users.
The Consolidated Appropriations Act of 2023 amended the Food, Drug, and Cosmetic Act to mandate SBOMs as part of premarket submissions for cyber devices, as specified in Section 524B(b)(3).
MITRE is out with a new white paper produced on behalf of the FDA directed to medical-device-sector stakeholders discussing data normalization challenges and recommended mitigations for producing SBOMs, ingesting SBOMs at scale, and related issues.
We’ve broken it down and distilled the key points below.
1. SBOM implementation faces complex technical and process challenges
The paper frames SBOMs as "key building blocks in software security and software supply chain risk management," enabling both proactive and reactive risk management measures.
The fundamental challenges arise from both non-technical and technical content-creation hurdles.
On the non-technical side, organizations struggle with developing processes for obtaining SBOMs from third-party components (both commercial and open source), managing SBOMs over the complete software lifecycle, and selecting appropriate tools for generating and exchanging SBOMs.
The technical challenges are more complex, including interoperability issues between different SBOM standards, handling missing information, dealing with imprecise definitions of SBOM elements, managing multiple formats for SBOM elements, and difficulties with ingesting and parsing data.
The paper emphasizes that scaling SBOM generation requires automation, which in turn demands sophisticated data ingestion capabilities from various sources including build systems, SBOM-generation tools, and component vendor SBOMs.
2. Immature standards and varying adoption levels are creating implementation barriers
The paper provides a detailed examination of maturity challenges in the SBOM ecosystem.
While traditional BOMs have a long history in industrial supply chain management, software BOMs represent a relatively new frontier. The standards landscape includes multiple machine-readable data formats (SPDX, CycloneDX, and SWID) and various tools for SBOM management.
Organizations are at vastly different maturity levels — some are just beginning pilot processes while others are implementing second or third-generation approaches. Even within single organizations, different product lines may operate at different maturity levels. This disparity extends to third-party suppliers, creating additional complexities when integrating SBOMs from multiple sources.
The paper notes that standards themselves contribute to the problem — while SPDX and CycloneDX specify elements that can appear in SBOMs, and the NTIA Framing Document identifies baseline attributes, the content and formats for these attributes are not fully specified or described, leading to inconsistent implementations.
3. Data normalization requires clearing multiple technical hurdles
The paper presents an extensive analysis of specific technical challenges affecting SBOM implementation.
Content and format issues include:
Case sensitivity variations that affect automated processing
Inconsistent use of abbreviations (e.g., "Win2K" vs. "Windows 2000")
Varying word separators (spaces, hyphens, camel case)
Punctuation inconsistencies
Handling of non-Latin characters
Varying representations of trademark/copyright symbols
Directory separator differences across systems
Acronym usage variations
The paper details specific challenges with component names, supplier names, and versions. For component names, the existence of different standards (CPE and PURL) means the same product might have multiple representations.
Supplier names face challenges with organizational suffixes, legal names versus common names, and handling of mergers and acquisitions.
Version information presents particular complexity with multiple numbering schemes, date-based versions, code names, and the handling of wildcards versus specific versions.
4. Solutions must span the technical, policy and process domains
The paper outlines a comprehensive framework of solutions operating at multiple levels. Here’s the top line in each area.
Technical mitigations:
Implementation of canonical names and representations
Development of mapping systems for actual names to canonical forms
Use of automated mechanisms for identifying aliases
Implementation of consistent identifier schemes
Development of parsers and scripts for handling specific normalization tasks
Policy and process improvements:
Establishment of centralized services and repositories
Development of a "Central Alias Database" (CAD)
Implementation of consistent naming conventions for proprietary software
Integration with internal sources of canonical names
Including specific SBOM requirements in supplier contracts
5. Industry must collaborate to solve common SBOM challenges
The case is made that individual medical device manufacturers should not tackle SBOM challenges in isolation. Instead, the industry needs to work collectively to address common problems, particularly around data normalization and software identification.
One key recommendation is the establishment of industry-led organizations that could maintain shared repositories for identifier schemes, addressing a critical gap in current CPE coverage. This is particularly important because, as the paper notes, CPEs are currently only provided by NIST when vulnerabilities are discovered in components, leaving many public components without known vulnerabilities, and private, custom in-house components without standardized identifiers.
The paper specifically references the Health-ISAC and CyBeats initiative as an example of productive industry collaboration, where they've created an SBOM repository available to Health-ISAC members. Such repositories could potentially produce CPEs and other software identifiers from their databases, providing a centralized resource for manufacturers. The paper also suggests adopting a federated approach similar to the CVE Numbering Authorities, where software component suppliers could publish identifiers upon release, with an organization (either industry-led or government) consolidating these identifiers into a federated search portal.
To improve tooling and interoperability, the paper recommends conducting industry-wide tool "bake-offs" or competitions, similar to approaches taken by DARPA for natural language processing and NIST for text retrieval technology. These events would allow different tools to generate SBOMs for the same products, enabling comparison and analysis of outputs, interoperability, and potential normalization issues. These could be conducted by individual MDMs or, preferably, by organizations like the CISA SBOM Community or membership organizations such as Health-ISAC and HSCC Cybersecurity Working Group.
6. Implementation requires a structured, methodical approach
Successful SBOM implementation requires a systematic approach starting early in the product development lifecycle. Rather than waiting until the end of development, organizations should begin SBOM production during the early stages. While this may necessitate modifications as components change during development, it provides more time to identify and address normalization issues and ensures a more complete and accurate final SBOM.