Wednesday, August 12, 2020

Is software bill of materials the answer to all of our problems? Part I



If you're looking for my pandemic posts, go here.

I confess I fell hard for the idea of a software bill of materials (SBoM) when I first heard of it about four years ago. If you’re not familiar with the term, you need to understand the problem that I thought it would address:

Nowadays, almost every piece of software you buy is loaded with components that are either open source or come from commercial third parties. Since so much code is available on the web for free or at a small charge, any developer who insists on reinventing the wheel for every piece of functionality they want to include in their software will probably not be in business too long. A 2017 Veracode study found that “83 percent of developers use code components to build web applications, with the average number of components per application (found to be) 73.”

Even more importantly, those components usually themselves have components, those components have components, etc. etc. Of course like any software, each of these components could have vulnerabilities that are only discovered – and maybe patched – years later. 

The recently discovered “Ripple20” vulnerabilities in the Treck TCP/IP library– which is embedded in lots of products, including some used by the power industry – is a great example of this. Guess when Treck first developed that library – 1997! It’s been embedded in just about countless products since then, and those products have been embedded in other products, etc. An article in ZDNet says:

The number of impacted products is estimated at "hundreds of millions" and includes products such as smart home devices, power grid equipment, healthcare systems, industrial gear, transportation systems, printers, routers, mobile/satellite communications equipment, data center devices, commercial aircraft devices, various enterprise solutions, and many others.

Experts now fear that all products using this library will most likely remain unpatched due to complex or untracked software supply chains.

Problems arise from the fact that the library was not only used by equipment vendors directly but also integrated into other software suites, which means that many companies aren't even aware that they're using this particular piece of code, and the name of the vulnerable library doesn't appear in their code manifests.

Moreover, even though the researchers who discovered the problems have identified 19 vulnerabilities in the library (of which four pose the highest level of risk. The CISA advisory is here. Thanks to Kevin Perry for pointing this out to me), they report they’re not even halfway through with their research! These 19 vulnerabilities have all been patched (I assume it’s 19 patches). So the owners of each of those hundreds of millions of devices just need to identify each component of each piece of software (as well as each component of each component, down to say the tenth or twentieth level) on each device that might contain the Treck library, and then apply each of the 19 (and counting) patches to each piece of software. And of course, we’re all real software techies who can easily figure out how to do all of this, right?

Other than that, this should be a pretty easy problem to fix…

And fixing the problem of vulnerabilities in software components – if it can be done – is the subject of Part II of this post. Stay tuned for the exciting conclusion, appearing soon on a blog near you!


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.

Are you hot at work – or should be – on getting ready for CIP-013-1 compliance on October 1? Here is my summary of what you need to do between now and then.


No comments:

Post a Comment