- Webinar will help attendees know their SBOM basics.
- Particular reference to SBOMs’ criticality in medical devices.
- What is an SBOM, and more.
Coauthor, a software tool helping developers design and create compliant software for medical devices, is about to release the latest webinar in its ongoing device cybersecurity webinar series, focusing on SBOMs.
Developed by Hindsight Software, the webinar is titled “Software Supply Chain: Know Your SBOMs from Your SOUP.” It aims to provide insights into the management of software supply chain risks and explains the role of software bills of materials (SBOMs), with specific reference to medical device security.
The webinar will contrast SBOMs with SOUP (software of unknown provenance), highlighting the differences for a better understanding of security, provenance, and licensing in software development processes.
The session goes live on 20th March 2025 at 12:30pm GMT, and should benefit professionals including software developers, regulatory affairs specialists, and medical device manufacturers.
A range of topics are to be discussed by expert presenters:
- What is an SBOM,
- Practical, easy to follow methods for creating an SBOM,
- The necessary components of an SBOM,
- How software meets industry regulations and standards,
- How SBOMs are used to help identify and manage security weaknesses in SOUP components,
- How risks in the software supply chains can affect medical devices in the long run.
The 30-minute webinar comes at an important time, when regulatory bodies are increasingly requiring the use of SBOMs to reduce risks, improve transparency in software components, and help track any security vulnerabilities that may arise after software is released.
The requirement for SBOMs have become more important in the medical device supply chain due to the growing cybersecurity challenges stemming from software flaws.
What is an SBOM?
SBOMs can be thought of as a list of component parts like might be drawn-up to assemble a physical object comprising of many parts. It’s a formal record of the elements that make up a ‘finished’ piece of code. (Software is rarely ever considered finished or perfect.)
Developers often use existing components in projects. Doing so saves inordinate amounts of time otherwise spent to achieve what could be termed ‘standard features’ – the ability to draw text or images on a screen, for example, or get input from a keyboard. In software development, these are called libraries and frameworks, among other terms.
In many cases, code written by developers depend on the inclusion of libraries etc. for their application to run, so the collective term for the required components are sometimes referred to as dependencies.
Due to the ongoing nature of software development, it’s common for software to be versioned, in that bug-fixes and feature additions are added over time and so software, and each of its dependencies are published under version numbers.
An SBOM, in part, is a record of the component parts of an application, all its used frameworks, libraries, and/or dependencies, and the version number of each. If a potential security flaw is found in one component by the original developer or anyone examining (or using) the source code, it is superseded once renewed by a new version of the code, and given the next number in a sequence. Organisations running a piece of software, therefore, need a record of version numbers in the SBOM so they can apply patches to the affected component(s), typically involving updating to new version(s) of either the entire application, or the dependency where the issue was discovered.
Additionally, software is normally published under specific licence terms, which can limit how the code is used, or stipulate what happens to any changes made to the code. It’s important, therefore, for the SBOM to also record the different licences under which each component is released. For example, under some licences, changed code can require re-publishing by those that made the changes, in order for the software user to remain compliant.
