Are SBOMs a “roadmap for the attacker”?

As with any other new idea, there have been lots of objections on the idea that software bills of materials are needed to help secure our software supply chains. The most popular objection (especially on the supplier side) has been something to the effect of “If we provide SBOMs to our users, they’ll inevitably fall in the hands of the bad guys. This will give them a roadmap to attack our software products.”

At first hand, this argument seems to have a lot of plausibility. After all, if the bad guys know all of the components in a piece of software (or at least some of them), they’ll be able to go to the National Vulnerability Database and find each vulnerability that applies to one of those components. They’ll then be able to craft a targeted attack on one or all of those vulnerabilities, and with some luck be able to penetrate the software product itself. At that point, they’ll usually be able to move around and wreak havoc not only within the system they’ve penetrated, but on other systems on the network to which the original system is attached.  

However, this argument is invalid, plain and simple. Here’s why: The bad guys already have SBOMs. While there are advantages to getting an SBOM from the supplier (including that it will usually be more complete), a reasonably knowledgeable user can fairly easily generate their own SBOM, if they have access to the installation files for the software. Since at least some attackers are more than reasonably knowledgeable about software (including the approximately 1,000 developers that Microsoft estimates developed the amazing SUNSPOT malware that planted SUNBURST in at least seven SolarWinds Orion builds), it’s inevitable that when an attack is being planned, one of the first things the attackers will do is somehow get their hands on the installation files for software packages on the system they’re attacking, then build an SBOM for each of those software packages.

In fact, in the March 24 informational webinar for the energy sector on SBOMs, there was a good discussion of this question during the Q&A session at the end. In that discussion, Bruce Lowenthal, Oracle’s Senior Director of Product Security (and an active participant in the NTIA effort), pointed out that they normally generate SBOMs for their products in the same way: by analyzing the installation files (rather than automatically creating SBOMs as part of the software during their build process, as is done by a number of other developers). Thus, analyzing installation files isn’t just an alternative way to develop SBOMs; it happens to be Oracle’s preferred method.

So you can be fairly sure that when the bad guys come knocking on your door (rather than just indiscriminately scanning for vulnerabilities everywhere), they’ll already have the SBOMs they need, and they’ll have already identified any CVEs listed in the NVD for any of the components listed in those SBOMs. How are you going to defend your network against these bad guys?

You’re right, you’ll need an SBOM to defend yourself. So, far from providing a “roadmap for the attacker”, when a supplier gives you an SBOM they’re providing “armor for the defender”. Attend the NTIA webinar at noon ET on Monday April 12 (or watch the recording if you can’t makes the webinar itself) to learn more.

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.