LicenseHound

← All articles · 6 min read · 2026-05

What is an SBOM, and why are customers asking?

SBOM stands for Software Bill of Materials. It's a structured list of every third-party component your software ships with. If a customer or regulator just asked for one, here's the short version of what they want and why.

The simple definition

An SBOM is to software what an ingredient list is to food. For each third-party library or component that ends up in your product, an SBOM records:

• Name — e.g. express
• Version — e.g. 4.18.2
• License — e.g. MIT
• Source — usually the package registry URL or a content hash
• Optionally: dependencies of this component, supplier, copyright, known vulnerabilities

For a typical Node app you'd have 200–500 entries. For a Python app with ML dependencies, easily over 1000. Most of them are transitive — libraries your libraries depend on.

Why this is suddenly everywhere

Three things happened in roughly that order:

1. 2020 — SolarWinds. Attackers compromised a build pipeline at SolarWinds and pushed malicious updates to ~18,000 customers, including US federal agencies. The lesson governments took: we need to know what's in the software we run.
2. May 2021 — US EO 14028. President Biden's executive order on cybersecurity required federal software suppliers to provide SBOMs. NIST, CISA, and OMB followed up with concrete guidance.
3. 2024 — EU CRA. The Cyber Resilience Act formalised SBOM requirements for "products with digital elements" sold in the EU. Compliance ramps up through 2026–2027.

The trickle-down: large customers (banks, government contractors, healthcare) now ask their vendors for SBOMs as part of standard procurement. Vendors ask their vendors. The ask reaches small B2B SaaS companies via their first enterprise customer or first procurement gate.

What an SBOM file actually looks like

Two formats matter. Most tools and customers accept either.

SPDX (ISO/IEC 5962)

The older, more rigorous format. Produced by the Linux Foundation. JSON, YAML, RDF, or tag-value formats. Excerpt:

{
  "spdxVersion": "SPDX-2.3",
  "name": "myapp",
  "packages": [
    {
      "name": "express",
      "versionInfo": "4.18.2",
      "licenseDeclared": "MIT",
      "downloadLocation": "https://registry.npmjs.org/express/-/express-4.18.2.tgz"
    }
  ]
}

CycloneDX (OWASP)

Newer, slightly richer for vulnerability data. JSON or XML. Excerpt:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "licenses": [{"license": {"id": "MIT"}}],
      "purl": "pkg:npm/express@4.18.2"
    }
  ]
}

If a customer doesn't specify, send CycloneDX JSON — it's slightly more common in current procurement workflows, and any tooling that reads SBOMs handles it.

What's not in an SBOM

An SBOM is descriptive, not analytical. It doesn't say "this is a problem." It just says "this is what's there." The customer's review process is what turns the SBOM into a yes/no decision:

• Their security team checks each component against vulnerability databases.
• Their legal team checks each license against their internal policy.
• Their procurement team rolls both into a vendor-risk score.

This is why answering the SBOM ask is not the end of the conversation. Expect follow-up questions on specific entries — usually copyleft licenses or recently-disclosed CVEs.

Producing an SBOM honestly

The challenge isn't generating the file — there are dozens of free tools that emit SPDX or CycloneDX. The challenge is making sure the file accurately reflects what's actually in your product.

Two ways to get this wrong:

1. Underreporting. The tool reads package.json instead of package-lock.json and misses transitive deps. The SBOM lists 8 packages when there are 240. Customer's security team notices, things go sideways.
2. Misclassifying licenses. The tool can't parse a dual-licensed package's expression and confidently picks one license. The customer accepts based on the wrong info; problem surfaces later during their audit.

Both happen routinely with the most common free tools (licensee, pip-licenses) because they were designed for "show me roughly what's in here," not "answer a customer's procurement ask."

LicenseHound is built for the second job. Read the playbook for the practical end-to-end of responding to an SBOM request.