As a regular member of five different SBOM working groups, including four from CISA, I’m in a lot of SBOM-related conversations with a lot of very smart people. The participants of these groups come from large and small companies across several industries, along with folks in the vendor space like myself. It’s a really good mix of folks who are capable of understanding all of the use cases and how they impact different industry verticals from both software producers and consumers points of view.
In Tom Aldrich’s OWASP SBOM working group, the one that is not coordinated by CISA, Tom stated early in a call that he thought SBOMs weren’t going anywhere without VEX. Tom thought that Software producers didn’t want to supply their customers with a Vulnerability Exploitability eXchange (VEX) because they’d be fielding too many support requests because of false positives in the SBOM when all of the vulnerabilities are enumerated by the consumer. This isn’t the rabbit hole I want to go down today, but it did get me thinking about a conversation I had with Tom over a year ago when we were first introduced. One of the burning questions we had in common was how to get vendors to provide SBOMs.
At the time of Tom’s and my initial conversation, there was optimism about the executive order as something that would start to compel vendors to produce SBOM if they wanted to do business with the government and their deep pockets. Fast forward to today; the EO is in place and the FDA is requiring SBOMs for new medical device submissions, and yet Tom gets the feeling SBOMs are going nowhere fast, rightfully so I might add.
I’m somewhat more optimistic given what I’m seeing through the eyes of my customers, but there are definitely whole swaths of software vendors who are not sharing SBOMs and have no intention of sharing them anytime soon. Tom covers this well on his blog, along with some of the exceptions who are.
Internal Use Growing
I’m seeing government agencies that, while they aren’t mandating their vendors provide an SBOM, scan the binaries delivered to them to ‘assess risk’ prior to granting an Authority To Operate (ATO). They simply aren’t waiting for their vendors to provide an SBOM; they’re creating their own and taking them back to the vendor when they see alarming findings. They are also doing other types of scans to complete the picture and it is worth noting that, even if and when vendors supply a SBOM, they’re still going to do these scans as a verification and validation step. Anyone involved in SBOMs and the issues around simply producing a list of known vulnerable components knows that this exercise is going to create its share of false positive findings that the vendor is going to have to invest time and energy into. I’m willing to bet that as this practice grows, vendors will rethink the value of producing an SBOM along with a VEX because they will be doing it on a ticket-by-ticket basis already.
I’m seeing a similar thing play out in the private sector as well in my conversations with Third -third-party risk managers and Vendor Application Security Teams. While their immediate need is to fill in inventory gaps related to third-party software, they are also talking about shifting this activity left, into the procurement process. These shops intend to start asking for an SBOM in their security surveys, knowing that many vendors will not provide them, at least not initially. This is what I’ve been saying publicly since coming into the Binary SCA space: We as consumers have to start asking for SBOMs and signaling to the vendors that they are important to us. During the procurement phase, consumers still have leverage and use it to their advantage. A simple yes/no question: Can you provide a SBOM for your products? If yes, please attach it.
No SBOM? Now What?
Ok, so your vendor says no and doesn’t attach an SBOM. Now what? Firstly, you can negotiate a discount! The lack of an SBOM means the consumer would have to accept the unknown risk associated with these gaps in the software inventories and would need to invest resources to fill those gaps. Those efforts could possibly even be funded by the discount or at least augment existing funding. Secondly, consumers can negotiate the T’s & C’s to grant them the right to perform the types of security scans needed to help identify and mitigate potential risks in the software being purchased. And then, most importantly, these shops are using Binary SCA tools to produce SBOMs for their third-party software. The focus isn’t so much on latent vulnerabilities as much as potential future ones where the inventory will prevent another log4j-type fiasco.
It shouldn’t take long for sales teams to recognize this as a potential differentiator for their product, while at the same time, support and engineering teams are getting hammered with requests as to why component X with a nasty, known, vulnerability is in the product. Meanwhile, 80-90% of those requests will be for vulnerabilities that can’t be exploited or components that aren’t being used, which should get old fast.
Time to Apply Pressure
We’ve been waiting long enough for external pressures to compel software vendors to provide SBOMs, but it is time we apply our own pressure and use the power of the purse to send the message that SBOMs are important and we’re willing to create them without their help. Admittedly, I’m seeing this more at the government level than the private sector, but keep your eyes out for another CISA SBOM paper sharing guidance on this very topic.
