A Software Bill of Materials (SBOM) lists every component in your software. By 2026 it’s standard for enterprise vendor onboarding. This post is how to generate, store, and use one.

What’s in an SBOM

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "fastapi",
      "version": "0.115.0",
      "purl": "pkg:pypi/[email protected]",
      "licenses": [{ "license": { "id": "MIT" } }]
    },
    ...
  ]
}

Every dependency, transitive or direct, with version, license, and a Package URL (purl).

Generation

# Source code-based SBOM
syft -o cyclonedx-json . > sbom.cdx.json

# Container image SBOM
syft -o cyclonedx-json my-image:1.4.0 > image-sbom.cdx.json

# From package manager
pip-audit --format=cyclonedx-json > sbom.cdx.json
cargo cyclonedx
npm sbom --sbom-format=cyclonedx

syft (Anchore) is the swiss army knife. Works on source, containers, archives.

Vulnerability scanning

An SBOM by itself isn’t useful. Scan it:

grype sbom:./sbom.cdx.json --fail-on high

Outputs every CVE per component. CI fails on high severity.

- run: syft -o cyclonedx-json . > sbom.cdx.json
- run: grype sbom:./sbom.cdx.json --fail-on high
- uses: actions/upload-artifact@v4
  with: { name: sbom, path: sbom.cdx.json }

Storing SBOMs

Per-release. Persisted somewhere customers / auditors can access.

  • Dependency-Track (OWASP): self-hosted, tracks SBOMs over time, alerts on new CVEs.
  • GitHub Dependency Graph + Dependabot: free for public repos.
  • Snyk / Sonatype / JFrog Xray: commercial, polished.

Attestations

Pair the SBOM with a signature (Sigstore ):

cosign attest --predicate sbom.cdx.json --type cyclonedx my-image:1.4.0

Now the SBOM is cryptographically tied to the image. Customers verify both.

Vendor security questionnaires

Common asks in 2026:

  • Provide SBOM for the latest release.
  • Demonstrate vuln scanning in CI.
  • Sign images.
  • SLA for patching critical CVEs.

Having the pipeline in place answers all of these. See Software Supply Chain Security .

Continuous monitoring

A new CVE is announced. You want to know which of your shipped versions are affected.

  • Dependency-Track subscribes to NVD; flags affected projects.
  • GitHub Security Advisories: auto-alerts on Dependabot-tracked deps.
  • Custom CI: re-scan SBOMs nightly with grype using a fresh CVE database.

License compliance

The SBOM lists licenses. Some are incompatible with your distribution model:

  • AGPL pulled in transitively → all your code may need to be AGPL.
  • LGPL with static linking → may require modifications to be redistributable.
  • Proprietary licenses → audit.

Tools (FOSSA, Black Duck, license-checker) flag risky licenses. Cheap to add to CI.

What I’d ship today

For a 2026 product:

  1. syft in CI generates SBOM per build.
  2. grype --fail-on high blocks bad PRs.
  3. Dependency-Track stores and monitors SBOMs.
  4. Cosign attestation ties SBOM to image.
  5. License check flags risky licenses.
  6. Customer-facing endpoint: GET /security/sbom/v1.4.0 returns the latest SBOM.

A week of work. Pays back at the first vendor security review.

Read this next

If you want my SBOM + attestation CI workflow, it’s at rajpoot.dev .

Building something AI-, backend-, or data-heavy and want a second pair of eyes? I do consulting and freelance work — see my projects and ways to reach me at rajpoot.dev .