What Is a Software Bill of Materials?

Understanding SBOMs and their role in M&A due diligence and license compliance.

Definition

A Software Bill of Materials (SBOM) is a comprehensive, machine-readable inventory of all software components, libraries, and dependencies that make up an application. An SBOM typically includes each component's name, version number, supplier, and license type. The concept is analogous to a bill of materials in manufacturing, where every part in a physical product is documented for quality control, compliance, and supply chain management.

Origins and Regulatory Context

The SBOM concept gained significant regulatory momentum in 2021 when the United States issued Executive Order 14028, "Improving the Nation's Cybersecurity." This order directed the National Institute of Standards and Technology (NIST) to publish guidelines for SBOM creation and mandated that software vendors selling to the federal government provide SBOMs for their products. The executive order recognized that understanding the components inside software is a prerequisite for managing supply chain security risk.

Two widely adopted SBOM formats have emerged: SPDX (Software Package Data Exchange), maintained by the Linux Foundation, and CycloneDX, maintained by OWASP. Both formats provide structured, machine-readable schemas for documenting software components, their relationships, and their licenses. Organizations producing SBOMs typically output their inventories in one of these formats for interoperability.

How SBOMs Relate to M&A Due Diligence

In the context of M&A transactions, the SBOM serves as the foundation for third-party dependency disclosure. Buyers and their advisors need to know exactly which external software components are embedded in the target's product, what licenses govern those components, and whether any licensing conflicts could complicate the IP transfer. A complete SBOM answers these questions and enables the buyer's legal and technical teams to assess risk efficiently.

Many sellers do not maintain a current SBOM as part of their regular engineering practices. When a due diligence request arrives, the seller must then scramble to produce one under tight deal timelines. This is the specific problem DependencyDesk solves: it generates an SBOM-like dependency and license report across an entire GitHub organization in minutes, giving sellers a complete inventory they can share with buyers immediately.

What an SBOM Includes

According to NTIA (National Telecommunications and Information Administration) minimum elements, an SBOM should include the component name, version string, supplier name, unique identifier, dependency relationship (direct vs. transitive), and the timestamp of when the SBOM was generated. In practice, license type is also a critical field, especially for M&A and compliance use cases.

DependencyDesk reports include the dependency name, version number, license type, and the specific repository that uses each dependency. While DependencyDesk does not output in SPDX or CycloneDX format, its CSV and HTML reports contain the information that buyers need for the dependency disclosure portion of due diligence.

SBOMs and License Compliance

One of the most valuable applications of an SBOM is license compliance verification. By inventorying every component and its license, organizations can identify potential conflicts between open source license obligations and their proprietary software distribution model. Permissive licenses like MIT and Apache 2.0 generally pose minimal risk, while copyleft licenses like GPL and AGPL require careful analysis to determine whether the usage triggers the copyleft obligation.

For a detailed discussion of open source license risk in M&A, see Open Source License Compliance for Mergers & Acquisitions.

How DependencyDesk Generates SBOM-Like Reports

DependencyDesk connects to a GitHub organization via a secure, read-only GitHub App and analyzes dependency manifest files across all selected repositories. It supports JavaScript (package.json), PHP (composer.json), Ruby (Gemfile), and Python (requirements.txt, Pipfile, pyproject.toml). The resulting report lists every third-party dependency with its version and license, organized by repository. Reports are exportable as CSV for inclusion in data rooms and due diligence packages.

The analysis completes in minutes, costs $30/month, and requires no enterprise engagement. Sellers can produce their dependency inventory immediately when a buyer requests it, rather than spending days or weeks compiling the information manually.