By Om Mahida, Director of Product at MedCrypt

SBOMs (Software Bill of Materials) have come into the spotlight in recent years, especially after the White House released the Cybersecurity Executive Order. This has also been a topic of interest for the FDA, the regulatory body for medical device cybersecurity. As more organizations adopt standard operating procedures (SOPs) to generate SBOMs on a regular basis, what do you do once you have an SBOM?

SBOM Use Cases

Two primary use cases of SBOMs are to identify vulnerabilities from component information in the SBOM as well as monitor license usage, especially of open source software. They provide value to post-market vigilance product security, research & development, and legal teams. Today, we are seeing processes and tools around SBOMs continue to evolve for these use cases. SBOMs allow us to do a better job of managing vulnerabilities in the dependencies of software.

While identifying vulnerabilities to minimize risk exposure in the next release of software is really important, how do you handle something like the Log4Shell vulnerability in the popular log4j open source library? Initial Twitter threads raised a lot of alarm bells and left security and engineering teams scrambling to see if they were impacted. How did you respond? What were the first actions you took?

Responses to Widespread Vulnerabilities

Over the past few years we have seen common patterns in how organizations respond to wide-spread vulnerabilities. In particular, as Log4Shell emerged, a pattern of three common actions taken by product security teams emerged:

1. Tried to use their existing SBOM documents and SCA tools
2. Asked who used log4j via internal communication and if the version of log4j they were using was vulnerable
3. Spent weeks if not months figuring out the above points and struggled to stay on top of new log4j vulnerabilities as they came out

‍

‍

What was shocking was the ineffective use of SBOMs. Having SBOMs and SCA tools is a good SOP. Directly communicating with the product development teams is a good SOP. Not being able to quickly have insights to who in your organization uses log4j through a quick search is a pain point. Enabling that workflow would provide insights and enable you to prioritize which product teams you should be focusing on, which would save countless days of follow up emails or Slack/Teams messages.

Another common response was trying to use static SBOMs and SCA tool outputs to assess impact. SCA tools are good for point in time reviews, most obviously when identifying issues in an outgoing release of software, but they are not effective for continuous monitoring. When new vulnerabilities for log4j continued to emerge, having continuous monitoring of SBOMs and respective vulnerabilities would have created an opportunity to decrease the burden on everyone in the organization.

Using SBOMs Effectively

As the importance of SBOMs continues to increase, it’s important to make sure your organization is recognizing their value beyond just using them as a checklist exercise. They can be extremely useful when it comes to vulnerability management and response, as well as saving your organization valuable engineering time if used effectively.

Want to talk SBOMs and medical device security? View our cybersecurity solutions and contact us any time at info@medcrypt.com to get started.