Comeo at BOPP Days 2025
January 10, 2025
Comeo Brand
March 24, 2025
SBOM
Software Bill Of Materials
How we document our Software Medical Devices using SBOMs
Since the early years of manufacturing, the concept of BOM (stands for Bill-Of-Materials) has been essential to describe the components and materials needed to construct or repair a product. Software industry has derived the term SBOM (Software Bill-Of-Materials) to represent all components that compose a software.
Why is SBOM Critical?
Indeed, building a software means reusing libraries, frameworks inside the software itself, and having a detailed description of all reused components is critical for support activities:
-
Their provenance
-
Their exact versions
-
Their license information
📌 "An SBOM allows us to detect security vulnerabilities, check maintenance status, and ensure license compliance."
This detailed component description allows us to detect if a software is exposed to a security breach through the reuse of a specific vulnerable component, or it allows us to check if all components inside the software are still maintained by their supplier - be it a commercial supplier or an open-source community. And finally it allows us to check if the licenses of the components used in the software are compatible with the use of the software itself - think about open-source contaminating licenses.
This task can very quickly become cumbersome when we deal with “transitive dependencies”: a component, reused in the software, is itself reusing another component which itself reuses another one,… The SBOM should take care of this and document the complete list of dependencies, including the transitive dependencies up to the last level. Indeed you could reuse a component, itself reusing another one which becomes vulnerable, impacting your whole software. Usually modern development tools like Maven (if you do Java development) or NuGet (if you do .NET development) allows generating SBOM and other specific tools (part of Software Composition Analysis) can export SBOMs from their analysis.
Standards for SBOM: SPDX vs. CycloneDX
Two standards emerged as possible formats for SBOMs:
-
SPDX (Software Package Data eXchange - https://spdx.dev/about/overview/ ) which has been around since 2010 and originated from the Linux Foundation (originally focusing on open-source licenses compliance). SPDX is documented as a specification by ISO/IEC 5962 (https://standards.iso.org/ittf/PubliclyAvailableStandards/c081870_ISO_IEC_5962_2021(E).zip )
-
CycloneDX (https://cyclonedx.org/ ) which has started in 2017 and originated from the OWASP (Open Worldwide Application Security Project) with an initial focus more on the vulnerabilities detection. Both are backed up by standards: SPDX is documented as a specification by ISO/IEC 5962. CycloneDX is documented as a specification by ECMA-424 (https://ecma-international.org/publications-and-standards/standards/ecma-424/ ).
📌 "When selecting SBOM tools, consider supporting both standards for maximum flexibility. Several tools support both and allow to generate one format based on the other."
Expanding SBOM Beyond Software Components
While SBOM started with only the documentation of the components used inside the software, it then evolved to the documentation of external components needed by your software. Say for example that your software is hosted on a specific operating system, a container engine, uses a database or a middleware,… Those are not “internal” components of your software but those are still dependencies (external in this case) which also need to be listed in your software documentation (for the same obvious reasons: cyber security - is your software using a vulnerable version of a database management system for example, maintenance and license compliancy).
Furthermore, if you software can be installed on multiple platforms (for example your software may be installed on Windows Server or on Linux, can use SQL Server or PostgreSQL), then you cannot limit yourself to a single dependent set of external components.
CycloneDX addresses this problem by defining OBOM (Operational BOM) which can be linked to an SBOM and which defines an installation instance (for example linking your application SBOM to an OBOM that documents PostgreSQL 14.12 and Ubuntu 24.04 LTS). More and more cloud platforms are being used to host software, including software medical devices.
📌 "Cloud and AI are next in line: SaaSBOM (Software-as-a-Service BOM) and MLBOM (Machine Learning BOM) are emerging extensions."
SBOM and Medical Device Compliance
IEC 62304:2006 – Medical device software – Software life-cycle processes defines the concept of SOUP (Software Of Unknown Provenance) as
“…software that has not been developed for the purpose of being incorporated in a medical device…”
This matches perfectly the concept of libraries and frameworks as well as the concept of external dependencies. For example, Spring Boot has not been developed for the purpose of being integrated in a medical device, however I’m using it as an application framework for my Java based medical device. The standard requires that SOUPs are identified (provenance, version,…) and that their published anomaly lists are reviewed in order to avoid a hazardous situation.
This is exactly why the concept of SBOM emerged. First you need to know (identify) that your software is using, for example as a transitive dependency, Spring Security 5.3.0 which allows you to analyse the list of known vulnerabilities and discover that it is affected by a medium cryptographic weakness (see example at https://nvd.nist.gov/vuln/detail/CVE-2020-5408 ). It is also clear that SOUPs must be validated during the manufacturing (development) of the software medical device but SOUPs must be constantly analyzed also after putting the software on the market as a post-market activity (new vulnerabilities can be discovered months or years after releasing the software, in such case, the software must be patched with a release of the SOUP fixing the vulnerability.
📌 "Post-market monitoring is just as important as pre-market validation. Vulnerabilities can surface months or years later, as seen with Log4J."
SBOMs for Healthcare Providers
Until now, we described the use of SBOM in the context of the software manufacturer only. But the Medical Device Cybersecurity Working Group part of IMDRF published in 2023 the IMDRF/CYBER WG/N73FINAL:2023 document on “Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity”. This document sets the importance of using SBOMs not only at the manufacturer side but also at the healthcare provider (using the software medical device for patient care) side.
When the software manufacturer distributes, along with its software itself, the SBOM of the software, the healthcare provider can:
-
Monitor vulnerabilities in real-time (not just when the manufacturer issues an alert)
-
link an OBOM describing the exact deployment configuration of the software (operating system, database,…) and monitor vulnerabilities of the complete installed system in their own environment
📌 "With SBOMs, healthcare providers gain control over cybersecurity risks, reducing the window of exposure to threats."
How Comeo Uses SBOMs
At Comeo, we have integrated SBOMs into our software development lifecycle for many years:
✅ Automated SBOM generation for every release
✅ Use of commercial and open-source SBOM tools
✅ Continuous monitoring & alerting for vulnerabilities
✅ Active compliance with evolving standards (CycloneDX, SPDX, IMDRF, MDCG guidelines)
SBOMs are more than just documentation—they are a fundamental pillar of secure, compliant, and resilient software.
As software continues to evolve, tracking dependencies and vulnerabilities proactively is not optional—it’s essential.
