The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 


Video of Josh Corman’s SBOM Proof of Concept talk

Tom Alrich's picture
Supply chain Cyber Risk management - emphasis on SBOMs and VEX documents, Tom Alrich LLC

I provide consulting services in supply chain cybersecurity risk management and am now primarily focused on software bills of materials (SBOMs) and VEX (Vulnerability Exploitability eXchange). I...

  • Member since 2018
  • 426 items added with 154,667 views
  • Jul 19, 2021


I anticipated that Josh Corman’s talk at this week’s Energy SBOM Proof of Concept meeting would be good, and I certainly wasn’t disappointed – in fact, it was great. I’m going to describe it a little here, but I’m pleased to announce that the video is available – so you don’t have to take my word on any of this. Josh’s talk starts a little after the 12-minute mark and goes on for 22 minutes (his connection went down at one point, but he came back very quickly).

The meeting was devoted to discussing use cases for SBOMs. It occurred to us in planning the meeting that one of the best ways to address this topic was to hear from the two people most responsible for the movement to make software bills of materials more than just a nice concept, but a regular practice with well-understood (but not mandated) guidelines for production and use. These two people were Dr. Allan Friedman, leader of the National Technology and Information Administration’s Software Component Transparency Initiative, and Josh, who coined the term SBOM. They both spoke at this week’s meeting on how they came to see SBOMs as an important need, and why.

Allan spoke first (and led the meeting, as he usually does). His talk was very good, and you should listen to it. However, Josh’s was exceptional. He covered two topics: The events that led him (and many others) to believe that SBOMs were needed, and SBOM use cases. The latter was based on the NTIA document whose development he led in 2019, Roles and Benefits for SBOMs across the Supply Chain, which is one of the three or four fundamental documents produced by the Initiative.

Below are some very interesting statements he made in the “history” part of his talk. They’re certainly nowhere near everything he said (he managed to get in lots of words in a short amount of time, without rushing his words. Fortunately, you can get everything he says if you’re not afraid to back up at a few points during his discussion), nor can I swear that I didn’t get a few things wrong.

  1. He remembers July 13, 2013 as the day that he woke up to the problem of software component vulnerabilities. On that day, servers running Apache Struts 2 – an open source component of many applications – were attacked through previously-unknown vulnerabilities.
  2. Josh’s reaction then was “It’s open season on open source. Who’s going to attack just one bank anymore, when they can attack lots of targets through one component?”
  3. At the time of that attack, Josh was in a high-level position at Akamai. However, he soon moved to Sonatype, an early leader in open source dependency (component) management – and now one of the leading software composition analysis tools.
  4. Probably the event that woke most of the rest of us out of our blissful ignorance of the problem of component vulnerabilities was the 2014 disclosure of the Heartbleed vulnerabilities in the OpenSSL cryptography library in 2014, which was estimated to be found in about half a million “secure” servers.
  5. Heartbleed – as far as I know – didn’t lead to any major breaches, but it required a huge effort by a huge number of organizations, just to find whether they had any vulnerable web servers - and if so, where. Why was that? OpenSSL is a component of other software, and often a component of other components, etc. Many organizations never even found all the instances of OpenSSL that they were running. For example, Josh says it took DHS six weeks to even answer the question of which federal agencies were affected by Heartbleed.
  6. Meanwhile, some financial companies knew in literally minutes or hours both whether and where they were affected. Why was this the case? Because they had kind of proto-SBOMs. Josh said the financial sector had woken up to this problem when he did – with the Apache Struts 2 attacks.
  7. After this, Josh decided to really dig into the idea of SBOMs and started reading Deming, who had stressed the importance of bills of materials for manufactured products. Having BOMs gave manufacturers the following advantages:
    1. They could have fewer, but petter parts.
    2. They could compare quality of different suppliers and buy more from the high-quality ones.
    3. They could track which parts went in which products, so that if there were a problem with a part, it could be tracked down and replaced in any product in which it had been used.
  8. Another seminal event for both Josh and awareness of component vulnerabilities was the 2015 SamSam ransomware attack on Hollywood Presbyterian Hospital. This attack exploited a vulnerability in the JBoss Java development platform (now called WildFly). The hospital had to shut down patient care for about one week.
  9. The hospital knew about SamSam, but didn’t have any idea whether it was affected by the vulnerability and if so, where. Ofcourse, this was because they had no SBOMs to provide them that information.
  10. It was this and the Wannacry attacks that caused the Food and Drug Administration, which regulates medical devices like pacemakers and infusion pumps, to put out a “Pre-market guidance” for those devices. While it didn’t require SBOMs immediately, it said they would be required in the future. This galvanized the medical community to start working on the problem of SBOMs and led to the creation of the NTIA Initiative.

But there’s a lot more. Watch the video!

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 shared by the National Technology and Information Administration’s Software Component Transparency Initiative, for which I volunteer. If you would like to comment on what you have read here, I would love to hear from you. Please email me at


Richard Brooks's picture
Richard Brooks on Jul 19, 2021

I watched Josh's talk during the Energy SBOM meeting that Tom refers to. The entire talk was informative and Josh's review of how we got here offers some inside knowledge that you won't find anywhere else. This was indeed useful and insightful information. Perhaps, the most interesting development, with regard to the Energy POC was the very brief comment of Ginger Wright from Idaho National Labs; she indicated that INL would be hosting an SBOM exchange for testing purposes in the near future. Reliable Energy Analytics (REA) looks forward to participating in these SBOM exchange tests by providing generated SBOM's in SPDX Tag/Value format and consuming SBOM's in either CycloneDX XML or SPDX Tag/Vale format in preparation for the Energy SBOM POC.

Thanks for posting Tom.

Tom Alrich's picture
Thank Tom for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member

Get Published - Build a Following

The Energy Central Power Industry Network® is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »