Software Bill of Materials (SBOMs)

In the dynamic landscape of software development, the past decade has witnessed two transformative shifts that have redefined the industry’s trajectory. The first is the widespread adoption of open-source software components, providing developers with a vast repository of pre-built modules to streamline their work. The second is the embrace of DevOps principles, automating and accelerating the software build and delivery process. Together, these shifts promised unprecedented efficiency and speed. However, they also introduced a labyrinth of complexity, with software compositions becoming increasingly intricate and opaque. 

This complexity, coupled with the relentless pace of modern development cycles, created a pressing need for a solution that could offer clarity amidst the chaos. This is the backdrop against which the Software Bill of Materials (SBOM) emerged. This guide delves into the who, what, why, and how of SBOMs. Whether you’re a developer, a security professional, or simply someone keen on understanding the backbone of modern software security, this guide offers insights that will equip you with the knowledge to navigate all of the gory details of SBOMs.

Explore how Google leveraged 100M+ SBOMs to protect their software supply chain.

Register Now

What is a Software Bill of Materials (SBOM)?

A software bill of materials (SBOM) is a structured list of software components, modules, and libraries that are included in an application. Similar to the nutrition labels on the back of the foods that you buy, SBOMs are a list of ingredients that the software is composed of. We normally think of SBOMs as an artifact of the software development process. As a developer is building an application using different open-source components they are also creating a list of ingredients, an SBOM is the digital artifact of this list.

To fully extend the metaphor, creating a modern software application is analogous to crafting a gourmet dish. When you savor a dish at a restaurant, what you experience is the final, delicious result. Behind that dish, however, is a complex blend of ingredients sourced from various producers, each contributing to the dish’s unique flavor profile. Just as a dish might have tomatoes from Italy, spices from India, olive oil from Spain, and fresh herbs from a local garden, a software application is concocted from individual software components (i.e., software dependencies). These components, like ingredients in a dish, are meticulously combined to create the final product. Similarly, while you interact with a seamless software interface, behind the scenes, it’s an intricate assembly of diverse open source software components working in harmony.

Benefits of SBOMs

SBOMs are one of the most powerful security tools that you can use. Large-scale software supply chain attacks that affected SolarWinds, Codecov, and Log4j highlight the need for organizations to understand the software components—and the associated risk—of the software they create or use.

• Identify security vulnerabilities and risks in software: SBOMs provide a detailed inventory of all components in a software application, including third-party and open-source dependencies, enabling organizations to identify vulnerabilities quickly. This helps expose and mitigate critical risks in the software supply chain and supports faster incident response.
• Comply with standards: Regulations such as the U.S. Executive Order on Improving the Nation’s Cybersecurity, require SBOMs for secure software delivery. Cybersecurity frameworks such as NIST 800-53 and FedRAMP also encourage the use of SBOMs.
• Visibility and support for DevSecOps: Ultimately, SBOMs are a source of truth. They integrate seamlessly with CI/CD pipelines to automate vulnerability scanning and compliance checks and support collaboration by acting as a shared source of truth across development, operations, and security teams.
• Analyze trends: Beyond identifying risks, SBOMs enable you to spot trends in how software changes over time, potentially introducing new risks or threats.
• Cost savings: SBOMs support cost-saving in a variety of ways. They foster faster identification of vulnerabilities to minimize risk and reduce the cost of prolonged system downtime. They reduce development time and cost by exposing and remediating issues earlier in the cycle. And they provide visibility into components to prevent unintentional use of unsupported or outdated software.
  

Knowing what’s in software is the first step to securing it. Increasingly organizations are developing and using cloud-native software that runs in containers. Consider the complexity of these containerized applications that have hundreds—sometimes thousands—of components from commercial vendors, partners, custom-built software, and open source software (OSS). Each of these pieces is a potential source of risk and vulnerabilities.

Generating SBOMs enables you to create a trackable inventory of these components. Yet, despite the importance of SBOMs for container security practices, only 36% of the respondents to the Anchore 2022 Software Supply Chain Report produce an SBOM for the containerized apps they build, and only 27% require an SBOM from their software suppliers.

SBOMs use-cases

An organization can use SBOMs for many purposes. The data inside an SBOM has internal uses such as

• Compliance review
• Security assessments
• License compliance
• Quality assurance

Additionally, you can share an SBOM externally for compliance and customer audits. Within the security and development role, SBOMs serve a similar purpose as a bill of materials in other industries. For example, automotive manufacturers must track the tens of thousands of parts coming from a wide range of suppliers when manufacturing a modern car. All it takes is one faulty part to ruin the final product.

Cloud-native software faces similar challenges. Modern applications use significant amounts of open source software that depends on other open source software components which in turn incorporate further open source components. They also include internally developed code, commercial software, and custom software developed by partners. 

Combining components and code from such a wide range of sources introduces additional risks and potential for vulnerabilities at each step in the software development lifecycle. As a result, SBOMs become a critical foundation for getting a full picture of the “ingredients” in any software application over the course of the development lifecycle.

Collecting SBOMs from software suppliers and generating SBOMs throughout the process to track component inventory changes and identify security issues is an integral first step to ensuring the overall security of your applications.

Security and development teams can either request SBOMs from their software suppliers or generate an SBOM themselves. Having the ability to generate SBOMs internally is currently the more optimal approach. This way teams can produce multiple SBOMs throughout the development process to track component changes and search for vulnerabilities as new issues become known in software.

SBOM Formats & Standards

SBOMs can be generated in a few formats or schemas that standardize the organization of the file’s contents. The most common formats are…

1. CycloneDX
2. SPDX (Software Product Data Exchange)

SWID was previously listed as a third standard, and was typically used by the U.S. federal government. It launched in 2009 and has now largely lost traction.

Learn more about SBOM formats and standards, including a full comparison of Cyclone DX and SPDX.

A deeper dive into SBOM security benefits

There are many SBOM security benefits for your organization. Any effective solution to securing your software supply chain is transparency. Let’s dive into what SBOM security means with regards to these ingredients and why transparency is so vital.

Transparency = Discovering what is in there 

It all starts with knowing what software is being used. You need an accurate list of “ingredients” (such as libraries, packages, and files) that are included in a piece of software. This list of “ingredients” is known as a software bill of materials. Once you have an SBOM for any piece of software you create or use, you can begin to answer critical questions about the security of our software supply chain.

It’s important to note that SBOMs themselves can also serve as input to other types of analyses. A noteworthy example of this is vulnerability scanning. Typically, vulnerability scanning is a term for discovering known security problems with a piece of software based on previously published vulnerability reports. Detecting and mitigating vulnerabilities goes a long way toward preventing security incidents.

In the case of software deployed in containers, developers can use SBOMs and vulnerability scans together to provide better transparency into container images. When performing these two types of analyses within a CI/CD pipeline, you need to realize two things:

• Each time you create a new container image (i.e. an image with a unique digest), you only need to generate an SBOM once. And that SBOM can be forever associated with that unique image. 
  
  
• Even though that unique image never changes, it’s vital to continually scan for vulnerabilities. Many people scan for vulnerabilities once an image is built, and then move on. But new vulnerabilities are discovered and published every day (literally) — so it’s vital to periodically scan any existing images you’re already consuming or distributing to identify if they are impacted by new vulnerabilities. Using an SBOM means you can quickly and confidently scan an application for new vulnerabilities.

Why SBOMs matter for software supply chain security

Today’s software is complex, which is why SBOMs have become the foundation of software supply chain security. The role of an SBOM is to provide transparency about the software components of an application, providing a foundation for vulnerability analysis and other security assessments. 

For example, organizations that have a comprehensive SBOM for every software application they buy or build can instantly identify the impact of new zero-day vulnerabilities, such as the Log4Shell vulnerability in Log4j, and discern its exact location for faster remediation. Similarly, they can evaluate the provenance and operational risk of open source components to comply with internal policies or industry standards. These are critical capabilities when it comes to maintaining and actively managing a secure software supply chain. 

The importance of the SBOM was highlighted in the 2021 U.S. Executive Order to Improve the Nation’s Cybersecurity. The Executive Order directs federal agencies to “publish minimum SBOM standard” and define criteria regarding “providing a purchaser a software bill of materials (SBOM) directly or publish to a public website.” This Executive Order is having a ripple effect across the industry, as software suppliers that sell to the U.S. federal government will increasingly need to provide SBOMs for the software they deliver. Over time these standards will spread as companies in other industries begin to mirror the federal requirements in their own software procurement efforts.

If you’re looking for a deep dive into the world of software supply chain security, we have written a comprehensive guide to the subject.

What is an SBOM made of? What’s inside?

Each modern software application typically includes a large number of open source and commercial components coming from a wide range of sources. An SBOM is a structured list of components, modules, and libraries that are included in a given piece of software that provides the developer with visibility into that application. Think of an SBOM as a list of ingredients that evolves throughout the software development lifecycle as you add new code or components.

An example of items included in a SBOM are:

• A data format that catalogs all the software in an application, including deeply nested dependencies
• Data tracked includes details such as dependency name, version, and language ecosystem
• SBOM data files can catalog files not associated with the operating system or included dependency

Anchore Enterprise supports SPDX, CycloneDX, and Syft formats. This is a continually evolving space with new formats introduced periodically. To learn about the latest on SBOM formats see the Anchore blog here.

Who needs SBOMs?

When it comes to who needs SBOMs, they are mainly used by DevSecOps practitioners and compliance teams for audits, license monitoring, and compliance with industry-specific regulations. However, with the rise of software supply chain attacks (like the SolarWinds hack and the recent Log4Shell vulnerability in Log4j) SBOM use is now on the radar for both security and development teams alike.

Security teams

SBOMs play a critical role for security teams, especially when it comes to vulnerability scanning. It is much quicker and easier to scan a library of SBOMs than it is to scan all of your software applications, and in the event of a zero-day vulnerability, every minute counts. 

SBOMs can also be leveraged by security teams to prioritize issues for remediation based on their presence and location and to create policies specific to software component attributes such as vendor, version, or package type.

Development teams

Development teams use SBOMs to track the open source, commercial, and custom-built software components that they use across the applications they develop, manage, and operate. This assists development teams by reducing time spent on rework by helping to manage dependencies, identify security issues for remediation early, and ensure that developers are using approved code and sources.

Fueling the cross-functional use of SBOMs, is the Executive Order on Improving the Nation’s Cybersecurity, where President Biden issued an SBOM requirement that plays a prominent role in securing software supply chains. 

The current state of SBOMs

The current state of SBOMs is complex and evolving. The risks of software supply chain attacks are real, with almost two-thirds of enterprises impacted by a software supply chain attack in the last year according to the Anchore 2022 Software Supply Chain Report. 

To stem these rising threats, the Executive Order outlines new requirements for SBOMs along with other security measures for software used by federal agencies. Until now, the use of SBOMs by cybersecurity teams has been limited to the largest, most advanced organizations. However, as a consequence of these two forces, the use of SBOMs is on the cusp of a rapid transformation.

With governments and large enterprises leading the way, standardized SBOMs are poised to become a baseline requirement for all software as it moves through the supply chain. As a result, organizations that produce or consume software need the ability to generate, consume, manage, and leverage SBOMs as a foundational element of their cybersecurity efforts.

In recent years we have seen threat actors shift their focus to third-party software suppliers. Rather than attacking their targets directly, they aim to compromise software at the build level, introducing malicious code that can later be executed once that software has been deployed, giving the attacker access to new corporate networks. Now, instead of taking down one target, supply chain attacks can potentially create a ripple effect that could affect hundreds, even thousands, of unsuspecting targets. 

Open source software can also be an attack vector if it contains un-remediated vulnerabilities.
SBOMs are a critical foundation for securing against software supply chain attacks. By generating SBOMs into the development cycle, developers and security teams can identify and manage the software in their supply chains and catch these bad actors early before they reach runtime and wreak havoc. Additionally, SBOMs allow organizations to create a data trail that can provide an extended view of the supply chain history of a particular product.