Breaking Down SBOM Myths vs Facts 

As the healthcare industry undergoes a complete re-examination of its cybersecurity processes, protocols and the regulatory landscape in general, SBOMs have been earmarked as a way to ensure the safety and security of software supply chains.

In a previous blog post, we answered some of the most frequently asked questions about SBOMs. We looked at: 

                      • What is a Software Bill of Materials (SBOM)? 
                      • What is in a Software Bill of Materials?
                      • Who uses SBOMs?
                      • Who should have an SBOM?
                      • What are the benefits of using SBOMs?
                        • Is it mandatory for manufacturers to produce an SBOM? 

In this blog post, we will look at some of the common myths regarding SBOMs, looking at the claims and sharing the truth about them.  

Myth 1 – The transparency offered through using SBOMs will make it easier for hackers to attack.

Being transparent with an SBOM isn’t going to create a roadmap for attackers as it does not divulge the configuration of the software. Instead, it creates a roadmap for an organization and its customers to be able to respond to threats quickly.  
It is said however that attackers working with a criminal organization can leverage information contained in an SBOM. However, they are more than capable of scanning for vulnerabilities at scale without an SBOM so the point is irrelevant.  

On the flip side, the defensive benefits far outweigh this common concern about creating a “roadmap for an attacker”. If you were to forgo using an SBOM because you thought that it provides an attacker with an advantage, what you are actually doing is eliminating whatever advantage you had for protecting against such an attack. It would be like destroying your defensive playbook for fear that it could be used against you. In reality, it is just making you more vulnerable.  

SBOMs seek to level the playing field for defenders by providing additional transparency – at an enterprise scale – with standard, machine-readable decision support. All information is dual-edged, but insufficient software transparency affords attackers a clear advantage.  

                      • Attackers don’t need SBOMs. Mass, indiscriminate attacks like WannaCry serve to remind us that foreknowledge is not a prerequisite to cause harm. 
                      • Attackers and their tools can more easily identify software components. Conversely, it is often quite challenging, disruptive, inefficient, and even unlawful for defenders to determine the same. 
                      • Attackers of any single product can already find human-readable target components – licensing requirements have been increasingly requiring disclosure for decades.  

Myth 2 – An SBOM alone provides no useful or actionable information.

An SBOM is not a security tool in itself. However, for those who produce software, it improves the ability to identify individual components and better locate vulnerabilities.  During an active attack, an SBOM allows a medical device manufacturer or enterprise to answer key questions such as “does my device contain any of the components that are at risk”, “am I affected?” or “where am I affected?”. This can be done in a matter of minutes or hours instead of days or possibly even weeks as might be the case without an SBOM. 

In this way, an SBOM speeds up the entire vulnerability scanning process, making it an incredibly useful defensive tool. A 2021 study titled ‘Building resilient medical technology supply chains with a software bill of materials’ describes how the 2017 WannaCry attack took advantage of a slow and cumbersome vulnerability scanning process.    

“Vulnerabilities in common third-party components can—and have—greatly impacted delivery of patient care. For instance, the WannaCry attack in May 2017 infected 200,000 computers in hospital systems across 150 countries. These exploits leveraged a vulnerability in several versions of Microsoft Windows for which a patch had been issued in March 2017, two months prior to the attack. In the absence of a published software bill of materials (SBOM), builders such as medical device manufacturers and operators such as healthcare delivery organizations (HDOs) likely would have had to manually inventory systems to detect the vulnerable software versions. These resource-intensive processes can contribute to delays in patch validation, patch installation, and consequently, inoculation of systems.”  

Myth 3 – An SBOM increases exposure to licensing violations 

Licensing obligations are completely independent of SBOMs.  

License obligations occur whenever licensed software is present. SBOMs merely provide an inventory of software that may otherwise be hidden. In this way, SBOMs make potential license violations more visible. These violations should be dealt with regardless of whether or not they are listed on an SBOM. The awareness gained by creating an SBOM allows manufacturers to address unknown licensing commitments that may be lurking in your programs and that otherwise have been left unresolved.  

Myth 4 – An SBOM needs to be made public.

An SBOM does not need to be made public. In section 4 of Joe Biden’s Executive Order this much is confirmed by stating that medical manufacturers can publish SBOMs publicly or send them directly to a purchaser. 

“(vii)   providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;” 

The act of generating an SBOM is separate from sharing it. An SBOM does not need to be made available to the public. You may need to provide an SBOM to a customer, but this can be done directly, avoiding the exposure of a public website. 

Myth 5 – SBOMs are not scalable.

Modern best practices in software development require solutions to be assembled a piece at a time. Adding an SBOM component to that process and building it into a DevOps continuous integration and continuous delivery pipeline isn’t a lot of additional work. And if it’s large, that’s not necessarily a bad thing. SBOMs are designed to be machine-readable so the size of an SBOM doesn’t really matter.  

Scalability is key to the success of an SBOM. Developers are already under pressure to finalize software, on time and under budget. The requirement for SBOMs wouldn’t have been prioritized unless it was already known to be automated and scalable.  

Myth 6 – SBOMs expose business secrets.

A worry for some organizations is that in sharing an SBOM they are given away their trade secrets. This is simply not the case. 

Firstly, to go back to our much used ‘SBOM as a list of ingredients’ analogy, there is a big difference between sharing a list of ingredients and sharing a recipe. Every food business that markets a food product shares a list of ingredients. In doing so they are not giving away trade secrets.  

Secondly, it would be difficult for an SBOM to expose intellectual property or leak trade secrets.  Items listed within an SBOM include libraries, drivers, firmware, licenses, and operating systems. Code is not included in an SBOM, just component references. Your proprietary source code remains yours to share or to keep confidential at your discretion. In addition to this the IP of third-party open-source components belongs to their respective authors or copyright holders. They are governed by a host of license agreements that indicate how they can be used and altered. 

If you are still unsure just remember that SBOMs do not need to be made public, as previously discussed in Myth 4.  

SelectEvidence and SBOMs 

SelectEvidenceTM is an expert cybersecurity risk assessment platform that guides medical device manufacturers through the process of identifying applicable vulnerabilities and identifying the right security controls to mitigate those risks. It provides device manufacturers with an intelligent, automated, and traceable approach to cybersecurity assessments. SelectEvidenceTM does this by continually monitoring SBOMs across all connected medical devices.

The simple and automated ingestion of each SBOM makes it easier and faster to start monitoring and managing risk. SelectEvidenceTM scans over 200K vulnerabilities in real time, harnessing automation for 24/7 peace of mind. The solution provides specific and actionable mitigations for every vulnerability found. 

Learn more about SelectEvidence® and download a free information sheet on our Solutions page