I have been involved with the NERC
Supply Chain Working Group (SCWG) since early 2019. Starting in 2019, the group
developed a set of eight white papers on various aspects of supply chain cybersecurity
risk management. Each was developed by a group of SCWG members. The white papers,
and links to recordings of webinars about them, can be found here. It’s been three
years (!) since we developed those white papers, and because – in the
understatement of the year – there have been a number of new developments in
the field of supply chain security in those three years, the SCWG decided we
would update the papers this year.
One of the papers is “Risk
Considerations for Open Source Software”. Development of that paper was led by
George Masters of Schweitzer Engineering Laboratories. I participated in that
group, and I learned a huge amount from George about a subject about which I at
the time knew next to nothing.[i]
Two weeks ago, George convened the
first meeting of the group that is going to revise this paper. In discussing
changes we’d like to make to the paper, we decided we needed to address risks
due to open source components in other software, not just risks due to use of
open source software directly. Of course, the key tool needed to mitigate risks
due to software components (both open source and proprietary) is SBOMs. George
asked me to write a short summary of the risk due to open source components,
and how it can be addressed in part by using SBOMs. Here is what I prepared
(although I’m sure it will change by the time the paper is published):
Risks due to open source software components
The average software product today includes over 135
components[1];
some products include thousands of components. About 90% of those components
are open source[2].
In other words, the greatest part of the code in almost any modern software product
consists of open source components.
Of course, this also means that the greatest part of the
risk in any modern software product is due to its open source components. Open
source vulnerabilities like Apache Struts (source of the Equifax data breach),
Heartbleed and Log4j have caused massive headaches for IT staff worldwide, as
well as led to big financial and other losses.
Software users can sometimes download and patch these
vulnerabilities directly (as in the case of Log4j), but more often they have to
rely on the supplier to develop a patch themselves. In either case, the key to
mitigating the risk is knowing “the software in your software” – i.e. the
components included in the software your organization runs. An up-to-date “software
bill of materials” (SBOM)[3]
from your software supplier contains a list of those components.
Having an SBOM for a software product will enable a user
organization to track vulnerabilities in the product’s components (both open
source and proprietary), then coordinate with the supplier about mitigating the
risk posed by those vulnerabilities. In most cases, the mitigation will simply
be applying a patch provided by the supplier, although in some cases other mitigation
measures will be required.
There is much to discuss about SBOMs, and at the current
time the field is rapidly evolving. As of early 2022, the best information on
SBOMs is available at https://www.ntia.doc.gov/SBOM.
However, it is certain that much more up-to-date information will be available by
the time you read this. As there is currently no central clearing house for
SBOM information, you can email tom@tomalrich.com
for an up-to-date list of SBOM information sources.
I didn’t want to include my email
address in this document, but – since it will be close to a year before this
document is published, and because the documents on the NTIA website won’t be
updated any more, I really didn’t want people to try to figure out what’s going
on with SBOMs in 2023 by going to the NTIA site. I’m sure there will be lots of
new information in another year, but I can’t point to any site where people
will be able to find that information. There’s a business opportunity for
somebody!
Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they necessarily shared by CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. 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.
[2] Ibid
No comments:
Post a Comment