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