SBOMs, Beyond the Horizon

In my last blog post I discussed some of the difficulties encountered with operationalizing SBOMs.? In this post I’ll discuss where I think SBOMs will go and the need behind this forecasted progress.

The Future

Where do SBOMs go from here? Professionally, I feel SBOMs are on the cusp of greatness. The current state of SBOM adoption is just a couple years outside of being a household name in cybersecurity parlance. If I gaze into my crystal ball, here’s what I see… or at the very least hope for:

• Wider participation from vendors: On behalf of my clients, I’ve interacted with countless software and hardware vendors and listened to a half dozen or so memorable SBOM/vendor interactions regaled over happy hour while at some security conferences. Where we seem to be now is 50/50 with some vendors already on top of tracking the 3rd party software libraries used in their products and others giving a blank stare. Don’t get me wrong, we’ve come a long way, even those vendors that don’t know anything about SBOMs are open to the idea of it. This is in contrast to years past when getting an SBOM involved negotiating an NDA that rivaled passing a United Nations resolution.

Why? Greater vendor participation will result in greater access to quality SBOMs. Having vendors merely aware of their own dependencies fosters better development practices. I just got off a call with a vendor on behalf of a client who swore up and down that they didn’t utilize Zlib in their software. Our SBOM analysis was illuminating vulnerabilities for Zlib after we performed static analysis on their software. Well, it turns out they sort of were. While they weren’t directly using Zlib in their software they were using InstallShield to bundle their software which did have Zlib. This finding helped the vendor patch and fix the vulnerability in their product.

• Wider adoption of VEX documents: SBOMs have a FUD (Fear, Uncertainty, and Doubt) problem. I think VEX will solve that. SBOMs typically have a lot of red flags when analyzing for vulnerabilities because the main data lookup is ALL the vulnerabilities from NIST NVD which is bursting at the seams with findings from every nook and cranny of thousands of libraries found in the ethereal plane of GitHub. A VEX document allows for those vulnerabilities to be ‘attested’ to. In other words, dismissed based on evidence that a device is not affected, or if it is, mitigation steps.

Why? Consumers of SBOM data need a way to cut through the noise. A single open-source software component can have dozens or even hundreds of vulnerabilities associated with it. Just because there are vulnerabilities associated with the software component doesn’t mean the parent product is vulnerable. VEX provides a way to ‘dismiss’ vulnerabilities as unaffected in a machine-readable format.

• Tools to handle and maintain the SBOMs: I’ve mentioned Dependency-Track a couple of times in my previous blog post and it’s a tool that has my admiration. For an open-source tool, its user interface and ‘useability’ is well polished. The downside of this tool is that it comes with a bag of ‘quirks’ and it chokes over some of the nuances found when collecting SBOMs from different sources. Shocking, I know, an open-source tool with character. The alternative are the paid tools, which at this point are becoming fairly commodified. If paid tools exist to handle SBOMs why is this an item on my forecasted list? The answer is the industry is a minefield of SBOM products that vary in quality and useability. Even the best ones are probably 90% the way there and are continually making changes to their product. Look, while I believe Fortress is one of the best out there I’ll be the first to tell you we are still making refinements and improvements to our product that NEED to happen and aren’t just wants.

Why? If SBOMs are going to be used in the absence of a regulatory body shouting ‘thou shalt’, the experience can’t be painful. Additionally, for SBOMs to be useful, they need to be consumable in a concise and organized way. Most tools are already there, but they are all undergoing a final polish to capture all the use cases organizations have for SBOMs

In summary, I believe SBOMs are here already. They’ve been here and the technologies to support SBOMs have improved dramatically over the past 5-10 years. This doesn’t mean we at Fortress are done and prepared to coast. I still find SBOMs can be operationally prohibitive at times for organizations and I’m looking into the future to resolve these speed bumps when it comes to adoption. In the very near future, I believe SBOMs will become routine across industries (energy, healthcare, banking, automotive, etc.) even in the absence of regulatory requirements for them.