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. 


What’s cooking at the Energy SBOM Proof of Concept?

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
  • 371 items added with 120,081 views
  • Sep 20, 2021


The Energy SBOM Proof of Concept – sponsored by the Department of Energy and the National Technology and Information Administration – is entering a new education phase. Due to popular demand, we decided to provide an in-depth look at what goes into SBOMs – i.e. what are the ingredients in the software bill of materials cake, anyway?

In fact, we got so carried away with the cooking metaphor that we’re going to have a series of online “cooking classes”, at which noted SBOM “chefs” will demonstrate how they combine the elements of SBOMs and VEXes, as well as other ingredients, to produce software transparency. Truth be told, this is the ultimate goal of the NTIA software component transparency initiative, of which the energy PoC (and the contemporaneous healthcare and autos PoCs) is one part.

The first cooking class is next Wednesday, September 22 at noon ET. Julia Child being unavailable, we were quite happy to engage Steve Springett, who is co-leader of the OWASP group that develops and supports CycloneDX, one of the three major SBOM formats. Steve is also the initiator of the dependency-track “continuous component analysis platform” (which has been in operation since 2012 and has gained a wide following in its own right). In a few words, dependency track lets you upload SBOMs for the software your organization runs and track vulnerabilities found in components of that software. All for free, of course.

Here’s the webinar information (no registration is required):

Microsoft Teams meeting

Join on your computer or mobile app

Click here to join the meeting

Or call in (audio only)

+1 208-901-7635,,877158748#   United States, Boise

Phone Conference ID: 877 158 748#

Find a local number | Reset PIN

Learn More | Meeting options

At the following biweekly meeting on October 6, we’re pleased to have Kate Stewart, VP of Dependable Embedded Systems (how’s that for a title?) of the Linux Foundation. Kate has been the leader of the team that developed – and continues to enhance and support - the SPDX format, which started 11 years ago. Two weeks ago, SPDX was “recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021.” Quite an achievement!

Both Steve and Kate will do roughly the following, using a “basic” open source project from an OSS repository like GitHub:

  1. If possible, share the URL for the project with our mailing list in advance;
  2. Walk through how to build an SBOM (in CycloneDX or SPDX format, respectively) based on that project – with a lot of emphasis on explanation;
  3. Discuss basic use cases for the SBOM; and
  4. Show how the same method could be used to support a bigger and more complex project.

There will be time for Q&A. We also hope to be able to distribute some tasty samples, if we can overcome the (probably) small technical problem of decomposing them into digital bits and reassembling them into food at your computer. We have some people working on this problem as I write, and I fully expect they’ll have a solution by Wednesday. How hard can it be?

If you’d like to get a good preview of Steve and Kate, they did a great webinar on the “Roots of SBOM” recently, along with Chris Blask of Cybeats. The webinar was sponsored by Cybeats.

The PoC meetings are open to everybody, even if you’re not directly involved with the energy industry. You don’t have to sign up for the webinar, but if you’d like to be on our mailing list, drop an email to

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 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


Richard Brooks's picture
Richard Brooks on Sep 20, 2021

I'm looking forward to both Steve's CycloneDX and Kate's SPDX presentations. Both SBOM formats have the benefit of a passionate, supportive, responsive and an active community of knowledgeable supporters. You cannot go wrong by requesting that your software vendor provide their product SBOM's in either format.

Thanks for posting, Tom.

Matt Chester's picture
Matt Chester on Sep 20, 2021

You cannot go wrong by requesting that your software vendor provide their product SBOM's in either format.

I'm curious the more I hear about SBOMs from people like Tom and yourself, what's the pushback being received? Do software providers simply not want to spend the resources required to detail the SBOM? Or are they concerned it will highlight where they're cutting corners and they'd rather sweep it under the rug? 

Tom Alrich's picture
Tom Alrich on Sep 20, 2021

Good question, Matt. The fact is that most larger software suppliers are probably producing SBOMs now for all of their products - they are so helpful for risk management purposes. However, most of them are a) unsure about a lot of the procedures having to do with distributing SBOMs, and b) worried about the possibility that their support lines will be overwhelmed with wasted calls about vulnerabilities that aren't exploitable in their products, as discussed in this post.

Both of those problems are on their way to being solved, but I admit that they're not completely solved today. While a few suppliers are distributing SBOMs to customers now, most aren't. That is one of the goals of the ongoing energy proof of concept described in this post: to make suppliers comfortable with distributing SBOMs, along with making users comfortable with using SBOMs.

Richard Brooks's picture
Richard Brooks on Sep 21, 2021

Hi Matt. Thanks for the question.

The answer has been provided by two very influential organizations representing software vendors, in response to the NTIA call of comments regarding SBOM requirement of Executive Order 14028. All of the comments are available here, but the two most relevant, with regard to software vendors, are:

  • BSA | The Software Alliance   [RJB I call this one the "It's too hard" response]
    • An SBOM, if properly tailored and aligned with international standards, can provide useful information to customers, but if too prescriptive or not understood as a smaller part of a larger cybersecurity risk management program, can offer misleading information or simply not be a useful security investment.
    • Put simply, US agencies (like all organizations) are resource-constrained and therefore, must make tradeoffs. Detecting vulnerabilities through an SBOM requires mapping component identity fields to existing vulnerability databases. This mapping will not, however, explain if the component is used in a manner that would allow the vulnerability to be exploited. An SBOM is likely to cause a US agency to reprioritize its actions, in response to a vulnerability identified through an SBOM even if the software is not exploitable as used.
    • Requiring a company to publish an SBOM, especially when software is not managed by the customer, would not improve a customer’s cybersecurity risk management, and may unintentionally assist adversaries.
  • Information Technology Industry Council   [RJB I call this one the "Ignorance is Bliss" response]
    • Publicly disclosed SBOMs could subject the federal government to increased cybersecurity risk, as it could reveal how many critical systems use a particular code or IP product. This could reveal insights about sensitive market dynamics or competitive opportunities. We therefore recommend that NTIA avoid requiring public or any other type of unnecessary disclosure of SBOM data.
    • Finally, publishing first-party metadata about their in-house source code may come with additional concerns from companies about proprietary information. A vendor who has incorporated external IP into a product they provide to the government may be restricted by law or contractual obligations from disclosing it regardless of SBOM requirements. The use of open source modules is also considered proprietary information as such information can be used to reverse engineer the software. Therefore, we recommend that NTIA, and the USG more broadly, avoid mandating complete disclosure as a part of SBOM requirements.


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 »