Enterprise software procurement has historically evaluated security through questionnaires: does the vendor have a security program, do they conduct penetration testing, do they have SOC 2 certification? These questions are valuable but indirect. They measure security process maturity, not actual software security posture.
SBOMs change this. A software bill of materials is direct evidence: here are the components in the software you’re buying. Here are the CVEs associated with those components. Here is the evidence that the vendor is actively managing the vulnerability posture of their software.
Enterprises that require SBOMs from software vendors are no longer relying on the vendor’s self-assessment of their security. They’re evaluating the artifact directly.
Why Vendor SBOM Quality Varies Dramatically?
The regulatory push toward SBOMs has produced a compliance response that varies from genuinely useful to essentially meaningless. Vendors who generate SBOMs to satisfy a contract requirement without integrating SBOM generation into their development process produce SBOMs that are:
- Stale (generated once, not updated with software releases)
- Incomplete (missing transitive dependencies or OS-level components)
- Inaccurate (generated from incorrect tooling or incomplete package scanning)
- Unverifiable (no attestation or signing to confirm authenticity)
An SBOM that’s six months old doesn’t tell you the current vulnerability posture. An SBOM that’s missing transitive dependencies may show an apparently clean component list while hiding significant CVE exposure. Understanding how to evaluate SBOM quality is necessary before using SBOM data to make procurement decisions.
A low-quality SBOM is worse than no SBOM in one specific way: it provides false confidence that you have visibility into the software you’re buying.
What to Require in Vendor SBOM Contracts?
Currency and update cadence
Secure software supply chain requirements for vendor SBOMs should specify update frequency: an SBOM must be delivered with every software release, not on a periodic schedule. Software that updates monthly needs monthly SBOMs. A quarterly SBOM cadence for monthly-release software leaves three months of potential vulnerability accumulation undocumented.
Contract language should specify: SBOM must be provided within [N] business days of each software release, in [format], covering all components in the release artifact including transitive dependencies and OS-level packages.
Completeness requirements
Vendor SBOMs that cover application-layer dependencies but not OS-layer packages in containerized software are missing a significant portion of the component inventory. Contract requirements should specify scope: the SBOM must cover all components in the delivered artifact, including base image components, language runtime components, and all direct and transitive dependencies.
Format and verifiability
Container image security SBOM requirements should specify a machine-readable format (CycloneDX or SPDX) and signing requirements: the SBOM must be signed by the vendor’s key and the signature verifiable by the purchaser. An unsigned SBOM can be modified without detection; signing creates accountability.
CVE response obligations
An SBOM requirement without CVE response obligations is an inventory without accountability. Contracts should specify: when a CVE is disclosed that affects a component in the delivered software’s SBOM, the vendor must provide a vulnerability status within [N] days, and a remediated update within [N] days for critical CVEs.
Evaluating SBOM Quality During Procurement
Request an SBOM for a current release as part of the evaluation, not a sample document. A generic SBOM template tells you the vendor knows the format. An SBOM for the actual product you’re evaluating tells you they generate SBOMs in practice.
Compare the SBOM component count against expectations from independent scanning. Run the vendor’s product artifact through an independent scanner (Trivy, Grype, or Syft) and compare the component count against the vendor-provided SBOM. Significant discrepancies—particularly an SBOM with fewer components than independent scanning finds—indicate incomplete generation.
Check SBOM generation date and format. SBOMs generated in standard formats with documented timestamps are easier to evaluate and validate. An SBOM that lacks a generation timestamp may be stale. SBOMs in proprietary formats are more difficult to integrate with your vulnerability management tooling.
Ask for the SBOM generation methodology. A vendor who can explain their SBOM generation process—what tools they use, at which pipeline stage the SBOM is generated, how they validate completeness—demonstrates operational maturity. A vendor who provides SBOMs without being able to explain how they’re generated has likely implemented a compliance checkbox, not an operational practice.
Red Flags That Indicate Low-Effort Compliance
SBOM covers fewer packages than independent scanning finds. This indicates incomplete generation—possibly only scanning declared dependencies without crawling transitive ones or OS packages.
SBOM has no generation timestamp or is dated to a time significantly before the current release. Stale SBOMs don’t reflect current software state.
SBOM is provided in a proprietary format that requires vendor tooling to consume. Lock-in to vendor tooling for SBOM processing limits your ability to integrate SBOM data into your vulnerability management workflows.
Vendor cannot explain their SBOM generation process. If the vendor’s security team doesn’t know how the SBOM was generated, the SBOM is a document rather than an operational artifact.
SBOM doesn’t cover containerized components. For containerized software, OS-layer packages represent significant CVE exposure. An SBOM that covers only application-layer dependencies is incomplete.
Frequently Asked Questions
Who typically generates an SBOM?
SBOMs are typically generated by software vendors as part of their build pipeline, using tools like Syft, Trivy, or cdxgen that scan the built artifact to enumerate all components. In mature DevSecOps programs, SBOM generation is automated as a CI/CD step that runs on every release. Enterprises can also generate their own SBOMs from vendor-provided artifacts to independently verify completeness.
What should be included in an SBOM?
A complete SBOM should include all direct and transitive dependencies, OS-level packages (for containerized software), component names, versions, licenses, and supplier information. For containerized applications, coverage must extend to base image components—not just application-layer packages. The SBOM should also include a generation timestamp, the format used (CycloneDX or SPDX), and ideally a cryptographic signature proving it hasn’t been tampered with.
What is an SBOM in software development?
An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all components that make up a software artifact. In software development, it serves as the transparency record for what third-party and open source code is included in a product, enabling vulnerability tracking, license compliance auditing, and supply chain risk assessment by both developers and the organizations that procure their software.
What are red flags that indicate a low-quality vendor SBOM?
Key red flags include fewer components than independent scanning tools detect, missing generation timestamps or dates significantly predating the current release, coverage that excludes OS-layer packages in containerized software, and vendors who cannot explain their SBOM generation process. An SBOM in a proprietary format that requires vendor tooling to read is also a warning sign, as it limits integration with standard vulnerability management workflows.
The Accountability Shift
SBOM procurement requirements shift the accountability model for vendor software security. Without SBOMs, the vendor’s security posture is assessed through self-reporting and certification. With SBOMs, it’s assessed through the actual artifact.
Organizations that have implemented SBOM requirements in their vendor contracts describe the behavioral change among vendors: vendors who know their SBOMs will be evaluated invest in SBOM quality. Vendors who know SBOMs will only be filed and not reviewed optimize for format compliance rather than accuracy.
Making SBOM review a standard part of vendor security reviews—with documented evaluation criteria and follow-up on identified gaps—is what converts SBOM procurement requirements from paperwork into accountability.
The enterprises getting value from SBOM requirements are the ones who read the SBOMs.
