What is an SBOM, what is it not, and do you need one?

Mark Maney
Head of Customer Success
March 22, 2023
Mark Maney is an accomplished customer success leader with ties to both civil and computer engineering and has overseen the product lifecycle in product management, development, implementation, and consulting roles. Outside of work, Mark can be found golfing, tinkering, or spending time with his wife, daughter, and energetic Basenji mix.


This article will provide an introductory overview of what software bill of materials (SBOM) is, why they've risen to prominence, and how you can use them to improve your supply chain security. 


What is software bill of materials (SBOM), what is it not, and do you need one?

Software supply chain security is a developing field that focuses on protecting the development ecosystem. One critical component of your software supply chain is the third-party dependencies your project relies on. 

Using third-party code accelerates development, but it can also introduce security risks. This is because such dependencies often contain vulnerabilities that can lead to your code being exploited. These risks aren’t always acknowledged when packages are installed; developers typically view third party software as a time-saving shortcut and may be unaware of the threats that these dependencies can introduce.

Dependency exploits have facilitated some of the most impactful attack campaigns in recent history, including SolarWinds, Kaseya, and Log4j. Organizations were put at risk because these third-party packages contained exploitable vulnerabilities. Typosquatting campaigns have also been used to deliver malicious code to projects, without developers necessarily realizing it.

With third-party dependency exploits increasing in frequency and severity, establishing an effective security baseline is critical. At a minimum, this should provide detailed visibility into the third-party dependencies you're using and the vulnerabilities they contain.

What is an SBOM?

SBOM is an acronym for “software bill of materials.” The term “bill of materials," or BOM, is borrowed from the manufacturing industry where it lists the raw materials, pre-built components, and assembly processes required to build a new unit of a product. SBOMs have a similar function for the software industry.

An SBOM enumerates the assets in your software supply chain. It details all your dependencies, including their name, version, and the source they’re installed from. In addition to providing an overview of your product, this also provides an index of potential threats you face.

Without an SBOM, it's often hard to get a handle on modern software supply chains. A 2023 report from Synopsys looked at 1,700 commercial codebases and found an average of 595 open-source components in each one (up from 528 in 2022 and 445 in 2020). An overwhelming 91% of those codebases used at least one outdated component, while 88% contained components with no activity in the last 2 years.

Operational risk from open source dependencies, reported in the 2023 Open Source & Security Analysis Report by Synopsis

Discovering these vulnerabilities is challenging when there are so many dependencies to audit across different projects and package managers. An SBOM provides a cohesive, central starting point for analyzing your supply chain and its potentially weak links.

Why software supply chain security matters and the role of SBOM

Awareness of software supply chain risks has increased in recent years due to high-profile attacks where compromised supply chain components have resulted in the exposure of internal systems and end users for many companies overnight. SBOM helps bring awareness to the software supply chain components & dependencies themselves. 

The 2021 discovery of an easily exploitable flaw in the ubiquitous Java logging library Log4j caused disruption throughout the industry as development teams rushed to check if they were affected. In many cases, their own code did not leverage  Log4j, but nested dependencies did.

There have also been several cases of malicious software being published to widely used public repositories under the guise of performing legitimate activity, sometimes doing both to remain covert. In other instances, attackers have uploaded a package using a name that’s similar to popular projects, such as “umbrellaks” instead of “umbrellajs” — also known as typosquatting. In both cases, bad actors are getting creative as to how they attempt to introduce vulnerabilities in source code dependencies. 

An SBOM helps to identify the risks in these scenarios so they can be actively mitigated. SBOMs list all your dependencies, making it easier to spot when vulnerable, malicious, or low-quality packages are added. When zero-day vulnerabilities are announced, you can assess your exposure by simply searching your SBOM.

SBOMs and customers 

SBOMs aren’t strictly reserved for internal use. In much the same way that food packaging comes labeled with ingredients, SBOMs document your product's composition in a way that's useful to customers as well. Consulting an SBOM lets end users of your product better understand the risks associated with it. It also allows them to assess whether your software is compatible with their own supply chain standard.

The value of SBOMs is being recognized both inside and outside the software industry. As awareness grows, you can expect customers, clients, and users to start requesting you provide SBOMs with your product.

SBOM standards

SBOMs provide a detailed description of your software's dependency tree. They list all the packages in your software supply chain and provide essential information about each one:

  • The package’s name
  • The version(s) you're using, identified by its public tag or release number, and technical details such as its commit hash
  • Information about the vendor, such as its name and website address
  • The asset's type, such as an operating system package, programming language dependency, or direct binary download
  • Other relevant information about the asset, including the copyright and license terms that apply to its use

When generating SBOMs, you should use one of the industry standards to ensure the output is interoperable with established tools. There are currently two prominent ones: SPDX and CycloneDX:

  • SPDX: Maintained by the Linux Foundation and developed since 2010, it can encapsulate information about packages, files, and specific snippets inside files.
  • CycloneDX: Originally focused on vulnerability management and license compliance, CycloneDX is an OWASP Foundation project. It catalogs software supply chains in terms of components such as first- and third-party packages, dependencies, and services including external APIs.

Both standards can be expressed in several different formats such as JSON, YAML, and XML. They differ mainly in how they distinguish types of assets within the supply chain. CycloneDX retains a stronger emphasis on security and compliance, whereas SPDX is purpose-designed to document supply chains.

Using SBOM tools to distribute SBOMs

New SBOM tools are emerging to automate the generation of SPDX- and CycloneDX-compatible SBOMs. Running one of these solutions in your project will generate an SBOM that you can issue to your customers:

  • Syft: Syft produces SBOMs using container images and filesystems. It will index the operating system packages and programming dependencies inside the container or folder that you scan. You can save the output in SPDX, CycloneDX, or Syft's own format, with conversions between all three supported.
  • Microsoft SBOM tool: Microsoft's open-source SBOM tool generates SBOMs in SPDX 2.2 format. It detects dependencies installed with tools including npm, NuGet, PyPI, Maven, Ruby, Rust, and Go, as well as packages inside container filesystems.
  • Arnica: Arnica is a purpose-built platform for automating software supply chain security. You can access SBOMs for each of yo ur projects directly within the Arnica interface, including details of third-party packages, vulnerabilities, and outdated versions. SBOMs are a free offering within Arnica.

After you’ve created an SBOM, you should distribute it with your other release assets. This permits you and your customers to easily discern your software's composition and security posture.

Even small revisions should include an SBOM, regardless of whether you've added or removed dependencies. This ensures there's an accurate historical artifact for each release. Ideally, your SBOM tool should perform automatic scans at a regular cadence to guarantee maximum coverage.

Internally, SBOMs can also be generated for work-in-progress feature branches. Using SBOMs for development work allows you to check whether unsafe dependencies have been added—before they get merged into your main branch. While you would not share this externally as a product overview as it includes development branches, finding and fixing zero-day vulnerabilities within your development sprint prevents exploitable code from being deployed.

Consuming SBOM

SBOMs are difficult to consume as is. The artifact you produce or receive from a vendor will be verbose JSON, XML, or other structured data. Searching the plain text can be laborious.

Fortunately, the software ecosystem is steadily building solutions that make analyzing SBOMs more convenient. Docker now has an integrated SBOM view for container images, for example, and CI/CD provider GitLab is working on a method for automatically parsing and presenting SBOMs generated within your pipelines.

You should verify SBOMs are genuine before you refer to them – a practice known as “attestation.” Each SBOM should have a verifiable signature so you can check it hasn't been tampered with. An attacker that uploads a manipulated SBOM creates a risk similar to an actual supply chain attack, as they could have edited the SBOM to conceal a malicious package.

Are software bill of materials (SBOM) mandatory? 

While customer demanded SBOMs are becoming more commonplace, SBOMs are not strictly mandatory (yet). A September 2022 memorandum from the U.S. Biden administration confirmed that SBOMs "may be required" by federal agencies that leverage third-party software. This follows up on the May 2021 executive order to “improve the nation’s cybersecurity,” which discusses supply chain security at length. The momentum seems to be toward mandatory SBOM.

Impact of recent SBOM executive orders  

As is indicated by the recent executive orders, SBOMs may be mandated in the future for security-critical settings such as government agencies.

Moreover, the executive orders suggest that agencies should "consider reciprocity" of SBOMs and produce them in a “usable format” for their intended audience, as SBOMs only add value if the recipient possesses the skills and technical resources to efficiently consume them. Although government guidance goes beyond SBOMs, it’s clear SBOM is becoming a pillar of application security.

These requirements are likely to trickle down from government to enterprise software, as was the case with FIPS, the U.S. government's Federal Information Processing Standards (FIPS). FIPS compliance is mandatory for agencies that need to adhere to the Federal Information Security Modernization Act (FISMA), but it has also been widely adopted in the broader software industry as the basis for effective security audits.

Warning: Supply chain security is much more than an SBOM

Although SBOMs provide visibility into your dependencies, they're only one part of supply chain security. In fact, it should be clear by now that the SBOM itself does not provide any security; it provides visibility and informs remediation actions that improve source code security. Your overall position is also affected by software that’s not covered by an SBOM. This includes the operating systems you use, as well as any external services such as managed database providers.

For example, an SBOM would tell you whether Log4j is directly embedded in your project, but it won't reveal whether the package exists in neighboring software on your server. Information in SBOMs can be inaccurate too, either because the SBOM itself is outdated or because it's been produced using incorrect information. For instance, package manager lockfile inconsistencies could cause an SBOM to list the wrong version of a package.

Supply chain security also links to other aspects of software hygiene. You need to consider the security concerns of the entire development lifecycle, including developer access management, CI/CD security, and leaked secrets detection, and hardcoded secret detection as a weakness in any one of these areas could allow attackers to manipulate your software supply chain.

Summary: SBOM is a key part – but only a part – of your overall software supply chain security posture

Third-party software dependencies are part of your software supply chain and can contain security threats. Because modern software often relies on hundreds or even thousands of dependencies, it's difficult for software developers and consumers to check if vulnerabilities exist.

SBOMs help to solve this problem by providing a standardized index of the components in your project. They let you uncover outdated, unused, and insecure dependencies that could be exploited to compromise your product.

Arnica allows you to generate SBOMs and identify supply chain risks for free. With Arnica, you can produce downloadable SBOM artifacts that provide clear visibility into your dependencies to serve as one aspect of your software supply chain security posture.


More from our blog

Leveraging EPSS, CVSS, and KEV for Comprehensive Risk Management & Prioritization
Leveraging EPSS, CVSS, and KEV for Comprehensive Risk Management & Prioritization
March 25, 2024
How to prioritize third-party package (SCA) vulnerabilities
How to prioritize third-party package (SCA) vulnerabilities
March 25, 2024
Why Risk Scanning Needs to be Free: Don't Just Find Risks, Fix Them
Why Risk Scanning Needs to be Free: Don't Just Find Risks, Fix Them
March 25, 2024