<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=705633339897683&amp;ev=PageView&amp;noscript=1">

Recap: Why this CISO thinks SBOMs aren’t the silver bullet

Caitlin Bixby
by Caitlin Bixby
on November 22, 2022

Don't miss the latest from Tidelift

On November 15th, Tidelift CEO and co-founder, Donald Fischer, hosted Andy Ellis, former Chief Information Security Officer at Akamai turned startup advisor and investor, to chat about a buzzworthy and constantly evolving topic: software bills of materials (SBOMs).

watch now

In the last year, SBOMs have been touted as a primary element of a good software security strategy. With the White House issuing the cybersecurity executive order 14028 last year and the U.S. government’s Office of Management and Budget (OMB) releasing memorandum M-22-18 a few months ago, both specifying the requirement of SBOMs, it’s no wonder they’ve become a hot issue.

To kick the chat off, Donald jumped right to the heart of the discussion, “Aside from the government told us to do it [...] what's the so what here with SBOMs?”

Andy: “If you are responsible for application maintenance, that you install software, then you are the target market for an SBOM. If you need to know what is in the software that you just installed, so that you know if you need to reinstall it because that software is out of date, that is the single thing that SBOMs are the perfect solution for. They aren’t the silver bullet for that problem, they’re like the platinum bullet.”

“Pick your favorite vulnerability. Say: What software do I need to do something about [this]? Where do I need to go talk to my vendors to get something new? Or do I need to build new software myself out of my build system? That is what an SBOM is perfect for: telling you, the person who installed the software, what you need to do with it.” 

tl;dr They’re the silver bullet—if you can very carefully and very narrowly define the problem space.

However, the issue lies in what happens after you’ve created the SBOMs. What’s next? 

Donald summed up the issue of relying solely on SBOMs perfectly, “It almost seems like sometimes the convenient, catchy acronym SBOM is acting as a proxy for a broader set of software supply chain issues.”

Throughout the fireside chat, Donald and Andy covered talking points such as:

  • The SBOM food ingredient list analogy (and its inevitable grotesqueness).

  • Bridging the gap between enterprise users and the open source maintainers ensuring their packages adhere to government and industry standards.

  • The CISO perspective on vulnerability management and SBOMs.

Prior to closing out the chat with an audience Q&A, Andy wanted to emphasize that we need to make sure that people who are building and installing software are getting the SBOMs right for their software before they start fetching SBOMs for their SaaS provider, or other requests outside of their own system.

It’s important to focus on knowing what SBOMs are good at and figure out how we’re going to pull open source maintainers in to actually improve software health and security as well. At the end of the day, we can’t have a conversation about enterprise software that doesn’t include the open source maintainers. And we need to make sure that our ask from maintainers is clean and clear. 

To hear Donald and Andy’s perspective on these topics and to see if questions you may be having were answered during the Q&A, use this link to watch the webinar now.

Why this CISO thinks SBOMs aren’t the silver bullet