SBOMs and Attestations

I had to miss S4 last week, but I did hear a lot about it from attendees; as usual, it was very good. There was a lot of discussion of SBOMs, but I heard a couple of ideas that supposedly met with a lot of approval, which strike me as completely wrong. I’ll address the first of those in this post, and the second in another post soon.

The first disturbing thing I heard was that a lot of people supported the idea that they don’t need SBOMs to accomplish their vulnerability management goals, but just attestations. I’ve said that users don’t need SBOMs (or VEXes), but that was just by way of saying that what software users do need is the risk analysis that requires SBOMs.

In other words, you don’t need to have SBOMs, but you do need to learn about exploitable vulnerabilities due to components in your software. You will be able to learn that information yourself by receiving SBOMs and VEXes and feeding them into the proper tool, but there will also be third parties that will perform that analysis for you (and many other organizations) as a service.

However, what it seems the people at S4 were saying was, “I don’t need to track component vulnerabilities at all, in the software products my organization uses. I just need to get an attestation from the supplier that the software doesn’t have vulnerabilities. Then I can show the attestation to my regulator, compliance department, or whoever’s bugging me about how safe my software is. This will make them shut up, and I can go back to doing the other 9,999 things I have to do.”

Of course, a conscientious supplier would never give you such an attestation in the first place. Even though the supplier might honestly believe it’s completely true today, tomorrow they might find out that the product has Log4j all over the place – and has had it for years.

 I’m sure there are suppliers who will give you such an attestation. But keep in mind that:

1.      The average software product has well over 100 components. Many have thousands.

2.      Each component has probably as much chance of having a serious vulnerability as does the code written by the software developer itself. So the likelihood is that there will be many times more vulnerabilities in components in your software, than are listed in the NVD for the software itself.

3.      A 2017 study by Veracode found that “A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered.” It also found that “..only 23 percent reported testing for vulnerabilities in components at every release.”

4.      Of course, one would hope that those numbers have improved since that time, but if you think all software suppliers are now diligently patching every vulnerability in a component in their product – or even checking for component vulnerabilities…well, I think you need to think again.

This isn’t to say that the average software developer is trying to pull a fast one on you. But the fact is that we’re all busy, and we all put off things that nobody is bothering us about. If your customers don’t have SBOMs and therefore don’t know what components are in your product, your phone isn’t going to be ringing off the hook whenever a serious vulnerability is discovered in one of those components. Of course, you’ll get around to fixing those vulnerabilities, no question. Right after you get the next release out…

Meanwhile, if a customer asks for an attestation that your software is vulnerability-free, and since the NVD doesn’t currently show any vulnerabilities for it…well, you’ll be happy to sign that, because after all…you know you’ll get to those component vulnerabilities sooner or later.

So take these attestations for what they’re worth, which is not very much. If you really want to learn about the vulnerabilities lurking in components in your software, you need SBOMs to tell you (or your chosen third party service provider) what those components are. And you need VEX documents to tell you which of those component vulnerabilities are exploitable. Accept no substitutes! 

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.