BIPI
BIPI

SBOMs That Get Used vs. SBOMs That Sit in Storage.

Compliance

Most companies generate SBOMs to satisfy a customer questionnaire. The SBOM gets uploaded to a portal nobody reads. The teams getting actual security value have a different workflow.

By Arjun Raghavan, Security & Systems Lead, BIPI · March 22, 2026 · 6 min read

#sbom#supply-chain#vulnerability-management#compliance

Software Bills of Materials moved from idea to mandate over the last three years. EO 14028, NIS2, and large-enterprise procurement now expect SBOMs from vendors. Most companies responded by generating one and uploading it to a customer portal. The SBOM is now compliance art. It does no security work.

The companies actually getting value from SBOMs treat them as operational data, not compliance artefacts. The shift is small in tooling and large in discipline.

What an SBOM is for, operationally

Three real questions an SBOM answers when it is wired into the right workflow:

  1. When a CVE drops, which of our products contain the vulnerable component? (Without an SBOM, this is hours of grep across repos. With one, it is a query.)
  2. When a customer asks 'do you ship X library?', which is now a frequent question after high-profile incidents (xz, log4j, polyfill, npm worm waves), the answer is one query away.
  3. When we audit a third-party component for licensing, security, or maintenance health, we know exactly which products and versions ship it, and what would break if we removed it.

The integration that matters

Generating an SBOM is the easy part. Syft, Trivy, Snyk, Anchore all produce reasonable SPDX or CycloneDX output. The integration that delivers value is:

  • Generate SBOM at every build, attach to the artefact (signed, ideally).
  • Push SBOM to a central store keyed by (product, version).
  • When a CVE is published, query the store: which (product, version) tuples include the vulnerable component? Generate remediation tickets automatically.
  • When a customer requests vulnerability disclosure, pull from the same store.
  • When dependencies are about to be updated or removed, query the store for impact: which products ship this version, what versions are downstream consumers using?
An SBOM that is not tied to your CVE alerting and your customer disclosure flow is a file. The value is in the workflow integration, not the file itself.

Granularity matters

An SBOM that lists 'react ^18.0.0' is less useful than one that lists 'react 18.2.0' with the exact resolved version, transitive dependencies, file hashes, and source provenance. The compliance bar is the former. The operational bar is the latter.

Tools matter here: Syft and Trivy produce highly detailed SBOMs from container images. npm shrinkwrap and pnpm lockfile data feed accurate version data for Node. Bundler, Maven, Cargo equivalents exist. Skim-level SBOMs from manifest files alone are not enough.

Signed SBOMs and attestations

An unsigned SBOM is a hint. A cryptographically attested SBOM (via in-toto, SLSA, Sigstore) is evidence. The attestation chain says: the SBOM was generated from the same source that produced the build, signed by a build pipeline that was itself attested. For sensitive supply chain claims, attestation is the difference between 'we say' and 'here is verifiable proof.'

Most enterprise customers do not yet require attestation. By 2027 they likely will. Building the pipeline now is cheaper than retrofitting it under deadline pressure.

The customer-facing flow

When the next high-profile vulnerability drops (and there will be one), customers will email asking 'do you ship the affected library?' The companies that answer in two hours win trust. The companies that answer in two weeks lose deals. The two-hour answer is only possible if the SBOM is wired into a query interface that someone can use without re-running the build pipeline.

Closing

SBOM mandates created a generation pattern that satisfies compliance and delivers nothing else. The operational pattern is the same generation step plus the integration: store, query, alert, disclose. The cost difference between the two is small. The security value difference is enormous.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.