Why You Need a Software Bill of Materials (SBOM)
Why is a Software Bill of Materials (SBOM) necessary? Hear from two open source experts why generating a Software Bill of Materials is an essential first step for proactive software lifecycle management and can help you prioritize vulnerability patching and remediation.
This video is from the webinar, “How to Ace OSS Lifecycle Management: Upgrades, Patches, and LTS” that took place on July 20, 2023. It was moderated by Javier Perez, Chief OSS Evangelist and Senior Director of Product Management at Perforce Software, and featured speakers Tim Carroll, Director of Product Development for OpenLogic, and Matthew Weier O’Phinney, Senior Product Manager for Zend.
To watch the full webinar, click here: https://ter.li/l2yf7l
- -
About OpenLogic by Perforce:
OpenLogic offers end-to-end enterprise support for organizations using open source software in their infrastructure. With support for over 400 open source packages, guaranteed SLAs, and direct access to highly experienced Enterprise Architects, OpenLogic customers benefit from 24x7 ticket-based technical support, professional services, and training.
Follow OpenLogic on LinkedIn, Twitter, and don’t forget to subscribe to our YouTube channel for more videos on all things open source!
- -
Transcript (lightly edited for clarity):
Tim: [SBOMs] are step one. It's probably the most critical piece to establishing that proactive lifecycle so that you can keep up with the latest versions of software. You've got to have that foundational piece where you've discovered all of your inventory of software and have attributes against those so that you can do prioritization around remediation of any issues. I mean, I think you guys have all mentioned some tools and things like that that help with that. Javier, you've written a blog recently that talks a little bit about Syft and Grype and some other open source stuff that works in this space, that helps you do some of that inventory. But there's still going to be some manual effort.
I think this is an early enough stage in the adoption of SBOMs that a lot of companies that haven't been doing this manually are really struggling to put some of this stuff together. So, even if you have some of this security scanners that are going out and discovering threats, knowing how that impacts your applications is really difficult to discern if you don't have that first piece, which is the software bill of materials or the inventory of assets. Now, putting those two pieces together really get you to that next level of maturity where you can prioritize whether or not you are going to patch certain systems on immediately or if you have time to wait and see whether those patches have other side effects or be able to test them more thoroughly with your application.
So, having that inventory of your assets, being able to categorize them as, "Hey, we've got this in development, we've got this in tests, we've got this in production. This is actually deployed to externally facing customers versus internally facing customers," things like that become more and more critical as you mature your CI/CD process and try to stay ahead of all these different versions and the software that is rapidly changing and completely integrated all the time.
Matthew: You said something really interesting there too, about understanding how you're actually consuming the given software, because in some cases, the CVEs that come out, you might not be utilizing even the functionality that the CVE is addressing. So, a really good example, PHP 8 had an issue with its SOAP extension recently, and it's specifically around the HTTP digest authentication with the SOAP extension. If you're not using SOAP, it doesn't apply to you. If you're not using HTTP digest with SOAP, it doesn't apply to you. So, it's understanding all those different levels, but having that list first is obviously, that is the biggest priority you can have. From there then understanding how you're consuming the software.
Javier: Absolutely, yeah.
Tim: They’re going to be situations where perhaps it's in an isolated environment where the software is actually vulnerable to that, but perhaps it's a remotely exploitable defect, but you have the entire system behind a firewall that buys you time. You don't want to not patch it, but you can weigh the risk of whether or not you want to do that immediately or not.