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. 


You need to be a member of Energy Central to access some features and content. Please or register to continue.


Can Software Bill of Materials (SBoM) Ensure Cybersecurity?

image credit: Photo 188715333 ©

  • Aug 27, 2020 11:19 am GMT

A Bill of Materials (BoM) serves a useful purpose in hardware. In addition to listing components, it also provides a useful system to track the final product through the manufacturing supply chain and coordinate with component vendors. 

A different function is currently being discussed for the Software Bill of Materials (SBoM), however. In an age of vulnerable applications and Industrial Control Systems (ICS), can an SBoM help in cybersecurity? 

The case for an SBoM in cybersecurity is a strong one. 

Modern software is a product of two competing strands of thought - open-source and proprietary. As their names suggest, the former emphasizes sharing and collaboration while the latter is focused on intellectual property and profits. While they are diametrically opposite in their conception of the software ecosystem, both approaches work well with each other and proprietary systems often borrow and reuse open-source software libraries in their code. In fact, the average percentage of open source codebases in proprietary applications reportedly increased from 36% in 2017 to 54% in 2018.  

The increased melding of these two styles of software development means that vulnerabilities of source code are also transferred along with their functionalities, making it easier for hackers to target multiple systems at the same time by exploiting security defects in a single component. SBoMs can help cybersecurity analysts simplify the process of identifying and patching the software vulnerability and replicate their efforts at scale. 

The Problem with SBoMs

But the devil, as always, lies in the details. The levels of details in this case, to be precise. SBoMs can be at the license level (such as those for operating systems or application software), module levels (such as those that replicate a functionality or feature from a given application), patch levels (such as those that replicate security patches for a software vulnerability), and backport levels (such as those that replicate custom patches developed by an individual customer). 

As one moves down these levels, the granularity of information and code multiplies. License level detail does not provide much information to identify problems with an application because it refers to potentially millions of lines of code in an operating system or application. For example, simply listing that a security vulnerability lies in a particular version of Linux or MacOS or Windows could put an entire organization, which runs these operating systems, at risk. Drilling down across levels increases the amount of work and time required. For ICS systems, especially, the task might prove particularly arduous given the level of detail required and lead to long service disruptions as professionals grapple with complex systems.      

The complexity of software distribution models further complicates SBoM use. For example, client/server models (in which the clients only run instances of software that resides on an application) and the cloud model (in which the actual application resides on the app cloud but offline processing may be possible in some cases) both make it difficult to identify vulnerabilities at the customer level. 

SBoMs also do not solve the vulnerability tracking problem. In the wrong hands, an SBoM could prove to be a useful roadmap to identify an exploitable piece of software and bring down multiple systems across industries and countries. SBoMs can be useful for air happed computers, which are physically isolated from the rest of the network. But such systems are exceptions rather than the norm in a connected world.  

Of course, this does not mean that SBoMs are useless. Indeed, increased digitization of industries has made cybersecurity of ICS systems such a pervasive threat that SBoMs are being considered by regulatory agencies across sixteen critical infrastructure sectors to streamline the process of identifying component vulnerabilities. For example, the Food and Drug Administration introduced the concept of Cybersecurity Bill of Materials (CBoM) in its Premarket Cybersecurity Guidance last year.  Cross-checking the CBoM against the National Vulnerability Database will provide ready and expedited means to identify and stop malicious code. But getting the level of detail included in this database is paramount.

Rakesh  Sharma's picture

Thank Rakesh 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.


Matt Chester's picture
Matt Chester on Aug 27, 2020 12:44 pm GMT

Anyone interested in this topic should checkout the replay of our recent PowerSession on the topic:

We also have a follow-up Q&A, open discussion hour planned that will cover these topics TODAY for those who want to ask questions of experts on the topic:

Richard Brooks's picture
Richard Brooks on Aug 27, 2020 4:13 pm GMT

Rakesh, thanks for your analysis and insights. The short answer to your question "Can Software Bill of Materials (SBoM) Ensure Cybersecurity? " is NO. But an SBoM is an important input to a comprehensive software supply chain risk assessment to help a party determine the "trustworthiness" of a software object, before any attempt to install. I hope you will join us for today's Q&A session:


Larry Farmer's picture
Larry Farmer on Aug 29, 2020 1:48 pm GMT

This area does need more awareness and there does need to be greater responsibility placed on vendors. This trend in leveraging existing software to build larger, more capable applications is not going away. In fact, it is a conscious objective of the software industry and is considered a long sought "holy grail". 

Using software which has been around, effectively, since the dawn of the internet is not a liability. It actually contributes to stability and standardization. The longevity of such software also ensures the code is free of bugs. In leveraging open source software, we also gain the additional benefits of having thousands of eyes on the code, thousands of testers and extremely quick fixes to an identified vulnerabilities. 

One of the biggest challenges of building apps of smaller apps is coordinating versions of the smaller apps. Manys times, larger apps in your production environment rely on different versions of the smaller apps. This is a challenging and chaotic environment and particularly frustrating for security professionals who are trying very hard to close vulnerabilities. This is also challenging for application vendors. Improving this situation requires purchasers to be aware of these challenges and to, in turn, challenge the vendors during the procurement process. If and when vendors see this demand from the marketplace, they will make a concerted effort to improve the situation.

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 »