What a Software Bill of Materials Is and Why Customers Ask for One

TL;DR — A software bill of materials (SBOM) is a machine-readable inventory of the parts inside a software product: libraries, packages, versions, and sometimes who supplied them. Customers ask for one so they can assess security exposure, respond faster to newly announced vulnerabilities, and satisfy procurement or regulatory requirements; the most common useful ask is: "Please provide an SBOM for each release, in SPDX or CycloneDX format, plus the date it was generated." Reading time: ~7 min

What it is and where it sits

An SBOM is the ingredient list for software. If your agency delivers a web app, mobile app, API, desktop tool, or internal platform, the SBOM lists the third-party components (externally maintained code you depend on) and often some first-party components (code your team produced) that were included in a specific build.

Typical fields include:

• component name
• version
• supplier or publisher
• package type (for example npm, Maven, PyPI, container image layer)
• dependency relationships (what depends on what)
• licenses
• checksums (fingerprints used to verify file integrity)

In architecture terms, an SBOM does not sit in the live request path. It is usually created during build or release in the CI/CD pipeline (automation that builds, tests, and ships code). It lives alongside release artifacts such as:

• the application package
• the container image
• release notes
• vulnerability scan results
• deployment manifests

It does not replace source code, penetration testing, or a security review. It replaces guesswork about “what’s inside this release?” Before SBOMs, teams often answered that question with a spreadsheet, package-lock file, or “we use React and Postgres” email. Those are incomplete and hard to automate.

A simple way to place it in the delivery flow:

[Developer] ---- 1. commit code ----> [CI/CD]
[CI/CD] ---- 2. build app/image ----> [Artifact Store]
[CI/CD] ---- 3. generate SBOM ----> [SBOM File]
[CI/CD] ---- 4. deploy release ----> [Production]
[Customer Sec Team] ---- 5. review ----> [SBOM File]
[Customer Sec Team] ---- 6. compare to new CVEs ----> [Risk Register]

What talks to it?

• Build tools generate it from package manifests and compiled artifacts.
• Security scanners read it to match components against CVEs (Common Vulnerabilities and Exposures, the standard public list of known security flaws).
• Procurement/compliance teams review it as part of vendor onboarding.
• Incident response teams use it when a new issue is announced, such as “Are we affected by Log4Shell?”

Where it lives:

• attached to a release in your source hosting or CI system
• stored with artifacts in your artifact repository
• handed to the customer as a JSON or XML file during delivery
• sometimes embedded in a signed attestation (a verifiable statement about how software was built)

How it actually works

Here is one realistic end-to-end example: your agency ships a customer portal as a containerized web app. The app uses Node.js packages from npm and a base container image from a public registry.

Step-by-step example

1. Developers declare dependencies The app has a package.json and lockfile such as package-lock.json. The Dockerfile starts from a base image like node:22-alpine.

2. CI builds a specific release In your CI pipeline, the code is checked out, dependencies are installed, tests run, and a container image is built.

3. An SBOM generator inspects the build inputs and outputs A tool such as Syft, Trivy, or a language-specific generator reads the package lockfile, installed modules, and container image contents. It records component names and versions, and often the dependency tree.

4. The SBOM is written in a standard format The two formats customers most often ask for are:

   • SPDX (Software Package Data Exchange, a common open SBOM standard)
   • CycloneDX (another common open SBOM standard, widely used in application security)

   The output is usually JSON because tools can parse it easily.

5. The agency ships the release and the SBOM together For example, release portal-2.8.4 may include:

   • portal-2.8.4-image.txt with the container image digest
   • portal-2.8.4-sbom.cdx.json
   • release notes
   • optionally a vulnerability report generated at the same time

6. The customer stores the SBOM in their security process Their security team imports it into a scanner or keeps it in a document repository tied to the vendor record.

7. A new vulnerability is announced later Suppose a high-severity flaw is published in a transitive dependency (a package you did not install directly, but one of your packages did). Without an SBOM, everyone starts by asking, “Do we even use that library?” With an SBOM, the customer can search the file or scanner and answer quickly.

8. The customer asks the agency for impact and remediation Because the SBOM identifies the affected component version, the agency can say:

   • affected releases: 2.8.0 through 2.8.4
   • not affected: 2.8.5 and later
   • fix: upgrade dependency X from 1.4.2 to 1.4.5

That is the practical value: faster, more defensible answers when risk questions come up.

What an SBOM does not tell you by itself

This matters for decision-making.

An SBOM tells you what components are present. It does not automatically tell you:

• whether the software is securely configured
• whether a vulnerability is actually reachable in your runtime path
• whether secrets were exposed
• whether custom code has security bugs
• whether the app is compliant with your exact policy

Think of it as inventory, not a full inspection report.

When to use it (and when not to)

If you are the customer, asking for an SBOM is most useful when you need repeatable vendor risk management, not just a one-time comfort check.

A practical customer-side rule of thumb

You should probably ask for an SBOM if any of these are true:

• the software will go into production
• the software will process sensitive data
• your internal security questionnaire asks about third-party components
• you need to react quickly to public vulnerability announcements
• your vendor management process needs evidence, not email assurances

You probably do not need to make it a big procurement issue if the software is temporary, low-risk, and isolated from important systems.

Trade-offs

SBOMs are useful, but they are not free.

The honest limitations

• Complexity: modern apps pull in hundreds or thousands of components. The SBOM can be accurate and still be hard for a non-specialist to read.
• Operational burden: if the agency generates it only once, it becomes stale. The real value comes from generating it on every release.
• False confidence: having an SBOM does not mean the app is safe; it means the inventory is visible.
• Lock-in risk: low if you ask for open formats like SPDX or CycloneDX. Higher if you only accept a proprietary scanner export.
• Money: the file itself is cheap; the process around it is where cost appears—pipeline work, storage, review, and remediation.

In practice

Below are two practical examples an agency could adapt today. Even if you never run these yourself, they show what “provide an SBOM” usually means in delivery terms.

Example 1: Generate a CycloneDX SBOM for a container image

syft packages registry.example.com/customer-portal:2.8.4 -o cyclonedx-json > portal-2.8.4-sbom.cdx.json

What it does: this generates a CycloneDX JSON SBOM from a built container image and writes it to a file named for the release. Gotcha: generate the SBOM from the exact image you ship, ideally using the immutable image digest, not just a mutable tag like latest.

A more precise version using an image digest looks like this:

syft packages registry.example.com/customer-portal@sha256:3d7c8f... -o spdx-json > portal-2.8.4-sbom.spdx.json

What it does: this generates an SPDX JSON SBOM tied to one exact image fingerprint. Gotcha: digests are safer than tags because tags can be moved to point at different content later.

Example 2: Add SBOM generation to a CI workflow

name: build-and-sbom
on:
  push:
    tags:
      - "v*"
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Build image
        run: docker build -t customer-portal:${GITHUB_REF_NAME} .

      - name: Install Syft
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Generate CycloneDX SBOM
        run: |
          syft packages customer-portal:${GITHUB_REF_NAME} -o cyclonedx-json > customer-portal-${GITHUB_REF_NAME}-sbom.cdx.json

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.ref_name }}
          path: customer-portal-${GITHUB_REF_NAME}-sbom.cdx.json

What it does: on every version tag like v2.8.4, this workflow builds the image, generates a CycloneDX SBOM, and stores it as a release artifact. Gotcha: if your build pulls private dependencies, the CI runner needs access to them or the generated SBOM may be incomplete.

What to ask your agency to deliver

If you want something practical rather than vague, send this:

{
  "request": "For each production release, please provide an SBOM in CycloneDX JSON or SPDX JSON format.",
  "include": [
    "product name",
    "release version",
    "date generated",
    "artifact identifier (image digest or package checksum)",
    "main third-party components and versions"
  ],
  "delivery": "Attach the SBOM file to the release record or shared project folder.",
  "optional": [
    "vulnerability scan generated from the same artifact",
    "signature or attestation linking the SBOM to the build"
  ]
}

What it does: this gives the agency a concrete, testable requirement instead of “please send security documentation.” Gotcha: ask for the SBOM to map to a specific release artifact; otherwise you may receive a dependency list that does not exactly match what was deployed.

⚠️ If you decide to make SBOMs a contractual requirement, do it before delivery starts. Adding it late usually means pipeline changes, release process changes, and backfilling older versions, which can delay handoff.

Further reading

• SPDX Specification
• CycloneDX Specification
• CISA: Software Bill of Materials (SBOM)
• NIST Secure Software Development Framework (SSDF)
• OWASP Software Component Verification Standard

This article was written by an AI system and published pending human review. Verify anything you intend to act on.