The Critical Components of a Complete SBOM

What Is an SBOM (Software Bill of Materials)? A Software Bill of Materials (SBOM) is a comprehensive inventory of the…

What Is an SBOM (Software Bill of Materials)?

A Software Bill of Materials (SBOM) is a comprehensive inventory of the components that make up a piece of software and includes all third-party software, both open source and commercial, used by that software. Beyond serving as a list of components, it assures those you supply software to that you know what’s in the software you deliver! So, to provide that assurance, what components are important to include in your SBOM?

Why Build a Software Bill of Materials?

The creation and maintenance of an SBOM is seen as a best practice in software development and cybersecurity. It is crucial for risk management and supply chain security, with uses in vulnerability management and software license compliance. For those you supply software to, SBOMs play a vital role in providing transparency and control over the software supply chain, as they rely on the SBOM to understand if any components in your software introduce these risks into their business.

As it relates to license compliance, your clients rely on the license and copyright information in your SBOM to determine if and how they can use your software – be it for a SaaS offering, embedded IoT device, or software that’s shipped and deployed in their customers’ environments. While the SBOM doesn’t provide recommendations such as “safe to use in SaaS”, your clients’ legal and compliance teams rely on the license and copyright information in your SBOM to make educated decisions on if and how they can use your software.

As it relates to security, it’s no surprise that new software vulnerabilities are discovered every day. If you ship your software to a client, its components may have no vulnerabilities today, but that can instantly change tomorrow. Including an SBOM for each version of the software you ship to clients is key to helping you (and them) be aware of newly disclosed vulnerabilities for components in a particular version of your software.

While this is by no means an exhaustive list of the license compliance and security risks SBOMs can address, we call them out to reinforce why completeness is a crucial part of assembling an SBOM. Omitting elements from your SBOM because you don’t know they’re there, or because your tools don’t support certain types of components can put your clients at risk and damage your reputation if that risk materializes. So, what components should be in a SBOM?

SBOM Elements

Let’s start with the most common reason people are interested in SBOMs – the creation of an inventory of the open source components in their codebase. An SBOM should contain two categories of open source – declared and undeclared open source.

Declared Open Source

Declared open source refers to open source that is declared in a manifest file and managed using a package manager (for example Maven for Java or NPM for Node.js). For producing an SBOM, a package manager’s knowledge of the dependencies for your open source components makes it an indispensable source of truth. Both the elements you use (direct dependencies) and their dependencies (transitive dependencies) should be present in an SBOM, as both are equally likely to introduce security and license compliance risks. Most if not all tools in the market produce SBOMs with declared open source by using a package manager as the source of truth.

Undeclared Open Source

On the flip side, undeclared open source refers to open source that makes its way into your codebase without the use of a package manager. Undeclared open source is trickier to identify and track in an SBOM, as it requires more intimate knowledge of the code (or more specialized scanning tools) to know where and how it’s used. Undeclared open source can take many forms, including:

  • An open source component forked and modified for use in a custom application.
  • Copy-pasted files or code snippets from GitHub repositories or sites like Stack Overflow.
  • A binary release of an open source component copy-pasted into the file tree.
  • Auto-generated code from generative AI solutions such as GitHub Co-Pilot.

Undeclared open source carries greater risk than declared open source because, without a package manager as the source of truth, most tools cannot identify it to conduct compliance and security checks, especially if it has been modified. Without an inventory of the undeclared open source in your codebase, a new vulnerability disclosed for those components or license obligation that forbids their modification or distribution can go unnoticed! Be it through a manually curated software catalog or via scanning tools capable of detecting undeclared open source, those undeclared elements should be in your SBOM.

Declared vs Undeclared Open Source

Commercial Software

This is a seldom talked-about area of SBOMs, but just as important. As with open source software, commercial software is subject to license obligations and may also have security vulnerabilities. Omitting commercial components from your SBOM may leave you, and your clients, unaware of potential risks that those components introduce. Including commercial components in your SBOM ensures that you, and your clients, remain compliant with the terms of commercial licenses and aware of the presence of new vulnerabilities that may be disclosed for those components.

Completeness of Your SBOM is Key

Regulatory Standards such as Executive Order 10428 in the US and the EU’s Cyber Resilience Act (CRA) are quickly driving the requirement for private industry to adopt the SBOM. It is important to note that compliance with either of these standards as they currently exist would NOT require an organization to include all the information detailed in this post. The standards as drafted today focus on the structure of an SBOM and not the completeness of the data. It may seem logical to design and build an SBOM to meet the requirements defined by the United States National Telecommunications and Information Administration (NTIA) which governs the Executive Order 10428, however, that would be a step towards repeating the mistakes of our past.

Consider what happened to many global leaders who built their application security efforts to align with the Payment Card Industry Data Security Standard (PCI DSS), which was introduced in 2004 to promote better application security practices. Instead of viewing PCI_DSS as a starting point, many organizations viewed it as the end game and built practices around the standard. This led to a false sense of security and many organizations who were “certified” PCI compliant found themselves the victim of security exploits anyway.

Current regulatory standards are a great first step to promoting better software development practices, however, they should not replace comprehensive risk management efforts.

A complete SBOM should include all the components covered above – declared open source, undeclared open source, and commercial components. By building a complete SBOM, you are not only improving risk management for yourself and anyone consuming your software, but also building trust with those that rely on your SBOM to quantify license compliance and security vulnerability risk.

Have questions or curious how FossID can help you produce a complete SBOM for your applications? Contact us!

Other Articles relevant