Building a Resilient World:
The ISAGCA Blog

Welcome to the official blog of the ISA Global Cybersecurity Alliance (ISAGCA).

This blog covers topics on automation cybersecurity such as risk assessment, compliance, educational resources, and how to leverage the ISA/IEC 62443 series of standards.

The material and information contained on this website is for general information purposes only. ISAGCA blog posts may be authored by ISA staff and guest authors from the cybersecurity community. Views and opinions expressed by a guest author are solely their own, and do not necessarily represent those of ISA. Posts made by guest authors have been subject to peer review.

All Posts

Excerpt: SBoM is Crucial in Software Development

The following is an excerpt of the recently published ISS Source article, "SBoM Is Crucial In Software Development," written by Cassie Crossley, director product and systems security at Schneider Electric, and ISA Global Cybersecurity Alliance (ISAGCA) member.

The article touches on the emerging interest surrounding software bill of materials (SBoM), and how the ISA/IEC 62443 series of standards connects to SBoM, furthering industrial control system (ICS) security.

The excerpt begins below:

Software development has been around for over 70 years, yet it remains a mystery to most.

Applications can range in size from thousands to millions of lines of code. This code is made of different software components, and it is commonplace for software developers to keep lists of these components.

Like a list of ingredients, a software bill of materials (SBoM) provides a nested list of components or libraries included in the software. An IoT product, for example, could have a combined SBoM consisting of the embedded operating system and firmware (software programmed into read-only memory).

Typical end-users have little need for this list of ingredients, but businesses and organizations have a definitive need for SBoMs as a matter of transparency, operational management, and business resiliency. As highlighted with the recent Log4j vulnerabilities, the usage of third-party open source or commercial components is not generally known to the customer. When the Log4j exploits became known, IT teams and software developers around the world quickly worked to identify the vulnerabilities in their applications.

Automated Tools

A software development team usually has a build or release manager who brings all the software components together for a release. This process is often automated and includes code analysis tools which check for software vulnerabilities. These tools create lists of potential vulnerabilities for software development teams to review for remediation and mitigation. Many of these build management and code analysis tools can create SBoMs for use in a vulnerability management process.

Software with many versions will have a unique SBoM for each version. An architectural redesign in version three of an application could present an entirely different SBoM than version two of the same application. When referencing a specific SBOM, an IT team needs to confirm they have aligned the specific software SBOM to what is deployed in the business environment. However, the industry is in the infancy stage for IT infrastructure to effectively ingest SBoMs and then take quick action.

Read the rest of the article here.

Cassie Crossley
Cassie Crossley
Cassie Crossley is director product and systems security at Schneider Electric and an ISAGCA member.

Related Posts

Cybersecurity Risk is the Great Equalizer

This blog has been repurposed from the May-June 2020 edition of InTech.
Eric Cosman Aug 9, 2022 5:30:00 AM

Securing Your Operations? Don't Forget Your Hardware

A version of this blog originally appeared on Cisco
Vivek Bhargava Aug 2, 2022 5:30:00 AM

Why ICS/OT Infrastructure is Insecure

Overview  Industrial control system (ICS)/operational technology (OT) infrastructure security is differen...
Ritesh Srivastava Jul 26, 2022 5:30:00 AM