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