Sunday, February 6, 2022

A concise statement about open source component risk


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.



[i] I led the development of two of the other papers, and we’re revising those as well. See this post.

No comments:

Post a Comment