Generating an SBOM for the code you build is a solved problem: point a tool at your pipeline and you are done. The harder problem is the software you buy. Most of your attack surface ships from vendors, and when the next Log4Shell drops, "we emailed our suppliers and are waiting to hear back" is not an incident response plan. A supply chain SBOM program only works if it covers the code you do not control, and that means getting SBOMs from your third-party software vendors, systematically, in a format you can actually use.
Here is how to ask for one, what to accept, and what to do with it.
Why you need vendor SBOMs now
Two forces make this urgent. The first is the attack pattern itself: SolarWinds, 3CX, and XZ Utils all showed that a single compromised component inside a trusted product can reach thousands of downstream organizations. When the compromise is inside a vendor's product, your own scanners see nothing. The SBOM is the only artifact that tells you what is actually running inside the software you bought.
The second force is regulation, and it is converging fast:
- The EU Cyber Resilience Act requires manufacturers of products with digital elements to maintain an SBOM for their products. Your vendors selling into Europe will have to produce one anyway; you might as well receive it.
- NIS2 makes supply chain security an explicit obligation for essential and important entities, including assessing the security practices of direct suppliers.
- DORA requires financial entities to manage ICT third-party risk with real evidence, not just contractual promises.
- US federal procurement, following Executive Order 14028, has pushed SBOMs into purchasing requirements, which means most serious vendors already have customers asking.
In short: your vendors are being asked for SBOMs by regulators and by their largest customers. Asking is no longer exotic. Not asking is what stands out.
What exactly to ask for
A vague "please provide an SBOM" gets you a vague answer. Be specific:
- A machine-readable format: SPDX or CycloneDX, in JSON. Not a PDF, not a spreadsheet, not a proprietary export. If you cannot parse it automatically, you cannot use it at scale.
- One SBOM per release, delivered with each version you deploy, not a single snapshot from whenever the vendor last ran a scan. Software changes with every release; a stale SBOM is a false sense of coverage.
- A deployment SBOM, not just a source SBOM. A source SBOM describes what the developers declared; a deployment SBOM reflects what actually ships to you: the container base image, the bundled runtime, the packaged dependencies. The gap between the two is exactly where surprises live.
- Dependency depth: transitive dependencies included, not just the top-level packages. Log4j was rarely a direct dependency; it was buried three levels down.
- VEX statements (Vulnerability Exploitability eXchange) alongside the SBOM. An SBOM tells you a vulnerable component is present; a VEX document tells you whether the vendor considers the CVE actually exploitable in their product. Without VEX, you will drown your vendor (and yourself) in false positives.
How to ask
The channel matters as much as the content.
Put it in the contract. New agreements and renewals are your leverage. A workable clause requires the vendor to deliver a machine-readable SBOM (SPDX or CycloneDX) with each release, covering transitive dependencies, plus VEX statements for disclosed vulnerabilities, with a defined delivery timeline. A requirement that lives only in an email thread is a favor, not an obligation.
Put it in the security questionnaire. Add direct questions: do you produce SBOMs, in which format, per release or ad hoc, do you provide VEX, and can you share a sample. The sample question is the useful one; it separates vendors who do this from vendors who plan to.
Put it in the onboarding checklist. SBOM delivery should be a gate in vendor onboarding for any software that touches production or sensitive data, alongside certifications and breach-notification terms. It is part of third-party risk management, not a side quest for the security team.
Adjust for small vendors. A two-person SaaS shop may not have a mature process, but SBOM generation is genuinely cheap: open source tools like Syft or Trivy produce a CycloneDX file in minutes. A reasonable ask for a small vendor is a per-release SBOM generated in CI, even without VEX at first, plus a commitment date for the rest. Accept imperfect but honest; do not accept nothing.
What to do when you receive one
An SBOM you file away in SharePoint is decoration. To get value from it:
- Ingest it into a central inventory, versioned per vendor and per release, so you can query "which vendors ship component X" in seconds.
- Match components against known-exploited vulnerabilities, starting with the CISA KEV catalog. A component with a CVE is a finding; a component with a KEV-listed CVE is a priority conversation with the vendor this week.
- Track drift between releases. Diffing consecutive SBOMs shows you new dependencies appearing, abandoned ones lingering, and components that never get updated. A vendor whose SBOM never changes across releases is telling you something about their patching discipline.
If you are building this pipeline for your own software too, our guide on understanding and managing your software supply chain covers the internal side: formats, generation, and connecting SBOMs to CVE intelligence.
Red flags
- PDF-only SBOMs. It means the SBOM is produced for auditors, not for machines, and probably by hand.
- One-off snapshots. An SBOM dated eighteen months ago describes a product you are no longer running.
- Refusal on "intellectual property" grounds. An SBOM lists mostly open source components; it reveals little that a determined attacker could not discover. Offer an NDA if it helps, but treat a hard refusal as a posture signal.
- No named owner. If nobody at the vendor can say who produces the SBOM, nobody does.
Handling realistic pushback
Expect three objections. "It exposes our IP": offer to receive it under NDA, and point out that the component list is overwhelmingly open source. "We don't have the tooling": the tooling is free, and a CI integration is a day of work; ask for a committed date rather than accepting a shrug. "Sharing it is a security risk": attackers do not need your SBOM to exploit you, but you need it to defend yourself; this argument mostly signals that the vendor has not looked at their own component list and is worried about what you will find.
When a strategic vendor still resists, use the renewal cycle. Requirements attached to money move faster than requirements attached to goodwill.
Make it part of continuous vendor oversight
An SBOM request is one control inside a wider vendor lifecycle: inventory, tiering, evidence-based assessment, and continuous monitoring. The FortaRisks TPRM module keeps that lifecycle live, observing your vendors continuously rather than once a year. And if you want to start asking today, our free vendor security questionnaire already includes SBOM and supply chain questions you can send as-is. The first vendor SBOM is the hardest to get; after that, it is just process.