Breaking Down SBOM Myths vs Facts

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.