The Importance of SBOMs in the Software Supply Chain

Though so much attention has been placed on secure coding to mitigate cyber threats to software, another emerging area of focus is the “software supply chain,” or the “software bill of materials” (SBOM). Why? Because software security doesn’t just depend on secure coding—the individual components of the software, or the SBOM—are equally critical.

Think of it this way: No one haphazardly chooses the ingredients used to make a meal – you select fresh vegetables, good cuts of meat, and quality seasonings before combining them in proven ways because you want a quality product that hits the spot rather than causes indigestion in the middle of the night.

In the same way as your hypothetical ingredients, well-defined software dependencies—which include those from third parties—can be a godsend providing useful functions that do not require original coding. However, ill-defined dependencies can become the trojan horse that undermines the best software development processes.

That’s why it can be helpful to have a list of all such dependencies, and as cybersecurity experts, we’re going to discuss the importance of SBOMs in this article. We’ll define what they are and their purpose, as well as how they build into the software supply chain and how you can improve yours.

What is a Software Bill of Materials?

Think of an SBOM as a software inventory—because it is, one that identifies all the components and dependencies used by your software, including the specific version(s) of each. Common examples of SBOMs include:

• Libraries;
• Frameworks;
• Modules; and
• Any other elements that compromise the final software offering.

In short, an SBOM is a detailed “ingredient list” for your software—it identifies all the parts, their provenance, and their relationships to each other, and it’s not limited to the developed pieces of code.

At a baseline, an SBOM would include at least a decent combination of the following information for each element of software:

What Does an SBOM Do?

Creating and having an SBOM can help you to manage and secure your software—some more specific, and far-reaching, benefits include:

The Elements of the Software Supply Chain

In constructing your SBOM to help with all that, you’ll need to create a process for gathering the involved data—or “ingredients”—that encapsulates the entire software supply chain, which can be quite complex, as it often involves multiple parties, including:

• Developers: Create and update software for things such as operating systems, applications, or web services.
• Third-Party Service Provider/Third-Party Vendors: Supply components like libraries, frameworks, and modules that are integrated into the software.
• Distributors/Resellers/Integrators: Package, bundle, and/or distribute software to end-users—this group can include individuals, bespoke software development companies, and infrastructure providers.
• End-Users: Those who use the software directly or build upon it.

How to Create and Incorporate a Software Bill of Materials

That probably sounds like a lot of ground to cover when creating an SBOM, and it is—your SBOM process will likely involve a combination of:

• Technical platforms;
• Predictable data formats; and
• Operational procedures.

Still, try to think of this work as merely a secure addition to your existing software development processes rather than the creation of entirely new flows—in taking this approach, the complexities of SBOM management should simply become incorporated into your routine and secure software development and maintenance.

Moreover, modeling your SBOM processes on existing approaches and methods will:

• Enable interoperability between vendors;
• Dampen variance; and
• Minimize the need for new tools.

Not only should all this make for simplified and better supply chain management, but incorporating SBOM into your software processes also gives your organization a new chance for customer outreach—you’ll be able to say, “Look at us, we’ve made updates to help keep you, your environment, and your data secure!”

So then, in getting started incorporating SBOMs into your secure development processes, focus on the following steps:

* While overlap of SBOM data can be common between products, some elements are almost always unique.

2. Keep It Current: Implement a recurring process to update the SBOM as software evolves so that you can track any new vulnerabilities that emerge as well as updates to third-party components.

3. Perform Threat Modeling: Periodically assess and classify the risks to software— including third-party components—before prioritizing and addressing corrections based on business risk or severity.

4. Maintain Communication and Transparency: Share the SBOM with relevant stakeholders to build trust and ensure they are aware of the software's components and associated risks.

Secure Software and Compliance

Though an SBOM can help maintain secure software development—among other things—you may also want to take things a bit further and comply with specific security standards for such.

Whether your customers request compliance as further evidence of your efforts to secure your software or if you’d just like to be proactive in your security, here are three options you may want to consider.

NIST SSDF and NIST CSF

The National Institute of Standards and Technology (NIST) developed both the Secure Software Development Framework (SSDF) and the Cybersecurity Framework (CSF) to provide organizations with structured approaches to managing and improving their cybersecurity posture.

More niche than the CSF, the SSDF includes fundamental, sound, and secure recommended practices based on established software development practice documents, and these practices are organized into four groups:

• Prepare the Organization (PO)
• Protect the Software (PS)
• Produce Well-Secured Software (PW)
• Respond to Vulnerabilities (RV)

Meanwhile, the CSF consists of guidance separated into five key functions to help organizations secure all critical cybersecurity infrastructure:

• Identify
• Protect
• Detect
• Respond
• Recover

(Though it wasn’t created specifically for software development and has broader appeal, in effect, the CSF maps to the SSDF in action.)

Secure Software Framework (SSF)

While adherence to either—or both—of those standards would help in securing your software development, you also have compliance with the PCI SSF as a potential option. Created by the Payment Card Industry Security Standards Council (PCI SSC), the PCI SSF recently replaced its PA-DSS standard as its benchmark for software that handles or can impact the security of cardholder data.

Made up of two different standards—the Secure Software Lifecycle Standard and the Secure Software Standard—a PCI SSF assessment would provide you with a comprehensive view of the security of your sensitive data, critical assets, development processes, your means to maintain software, and all associated communications.

Next Steps for Your Secure Software

As software continues to play a pivotal role in our lives, securing the software supply chain is of utmost importance—each link in the chain represents a potential point of vulnerability. Among the robust security measures that should be implemented by everybody involved, a Software Bill of Materials can be a powerful tool for achieving better software security.

In that an SBOM provides transparency and enables organizations to proactively manage software security, integrating one into your software supply chain can help you identify and reduce the risk of cyberattacks, mitigate data breaches, meet regulatory requirements, and create more secure software.

Compliance assessments can also help shore up your software development by evaluating your current posture and revealing gaps. To learn more about your options—including the NIST CSF, SSDF, and PCI SSF—contact us today.