Skip to content

SBOM — Software Bill of Materials

Statement

ClaimGuard does not yet publish a Software Bill of Materials. SBOM publication is a roadmap item, not a current control. Today the authoritative dependency picture is reconstructable from the in-tree manifests (package.json, package-lock.json, the per-tool requirements.txt files) plus the .snyk policy file — which is enough for our internal use and Snyk's SCA pipeline, but not the machine-readable single artifact a downstream consumer would prefer.

This page is the placeholder so a prospect or auditor can see SBOM is named and scoped rather than overlooked.

Implementation

Today's reconstructable inventory

While there is no published SBOM, every dependency is reconstructable from in-tree files:

  • npm: root package.json + package-lock.json, plus server/package.json + server/package-lock.json.
  • PyPI: the per-tool requirements.txt under tools/master_tool/, tools/c2pa/, tools/secondary_ai_detector/, tools/ai_detect_baseline/, tools/layover/, tools/dtect_image-0.1.0/, tools/provenance/.
  • Pin floors and accepted-risk deferrals: docs/security/README.md ("Dependency pins") and the root .snyk file.

These files together are not an SBOM in the CycloneDX or SPDX sense, but they contain the same information.

What an SBOM would add

  • A machine-readable artifact per release (CycloneDX JSON or SPDX JSON) so downstream consumers and security tooling can ingest the dependency tree without parsing seven different language manifests.
  • A versioned record independent of the working tree, so even after dependency drift the dependency state of a given release can be reconstructed.
  • A signed artifact so consumers can verify it has not been tampered with.

Why we have not shipped one yet

  • The dependency picture is small and stable enough that the in-tree manifests are operationally sufficient.
  • We are not yet publishing release artifacts (we run from main on the production VM), so "the SBOM for release X" is a category that doesn't exist in our pipeline yet.
  • A CycloneDX SBOM step in CI is the right time to add this — that CI plumbing is the same plumbing that gates Snyk, which is also a roadmap item.

Status

planned — target: alongside continuous SCA in CI.

Roadmap

  • CycloneDX generation as a CI step on every main build: cyclonedx-bom for npm, cyclonedx-py for the Python tools. Aggregate into a single artifact per build.
  • Publication of the artifact as a build artifact accessible from the trust portal once CI is wired.
  • Signing of the SBOM artifact (e.g., Sigstore / cosign) so downstream consumers can verify.
  • Per-release tagging once we adopt a release-tag model rather than "ship from main."
  • Annual SBOM-vs-.snyk consistency check as part of the deferral renewal sweep.

Not in scope right now

  • VEX (Vulnerability Exploitability eXchange) statements — generating a VEX document per release that says "CVE-X is unexploitable in our deployment" is the natural follow-on, but it's only a fit for organizations that already publish SBOMs routinely. Re-evaluate after SBOM publication is steady-state.