How to request an SBOM from your software vendor

Your last compliance audit flagged it. Or your security team added it to the vendor review checklist. Either way, you now need to collect SOBM documentation from your software vendors.

Asking is the easy part. Asking in a way that gets you something useful is harder. Vendors interpret SBOM requests differently, and the format matters more than most people realize. This guide gives you the language, the criteria, and a checklist you can attach directly to your vendor questionnaire.

What you should be asking for

A software bill of materials (SBOM) is a machine-readable inventory of everything inside a piece of software: every open-source component, third-party library, and dependency, with version numbers, license information, and supplier details included.

When you make the request to your vendor, the single most important thing to specify is format. Ask for CycloneDX or SPDX — both are internationally recognized standards and both satisfy the EU Cyber Resilience Act (CRA)'s requirement for a "commonly used, machine-readable format."

If a vendor sends you a spreadsheet, that's not an SBOM. It's a manually assembled list with no guarantee of completeness, no machine-readable structure, and no way to cross-reference it against vulnerability databases when a new CVE drops. A vendor who offers a spreadsheet either doesn't have a proper SBOM or hasn't understood what you're asking for.

Beyond format, a complete SBOM should include component names and version numbers, supplier or origin information for each component, license details, and the dependency relationships between components. Missing any of those fields limits what you can do with the document.

Update cadence matters too. An SBOM produced at contract signing is outdated within weeks. Ask for updates tied to each major release at minimum — and if the vendor can describe an automated process where the SBOM is generated as part of their build pipeline, that's a good sign.

How to phrase the request

Most vendors won't push back on an SBOM request if it's framed as a standard procurement requirement rather than an investigation. Keep the language matter-of-fact — you're not implying anything about their security posture; you're just documenting what's in the software you depend on. That framing tends to get faster, more cooperative responses.

Here's a query example you can copy directly into a vendor questionnaire or security review:

"Please provide a Software Bill of Materials (SBOM) for [product name] in CycloneDX or SPDX format (.json or .xml). The SBOM should include all components and their version numbers, dependency relationships, license information, and supplier or origin details. Tie it to a named product release and include a date of generation. Confirm your process for providing updated SBOMs following each major release, including the timeline for delivery."

If you're adding it to a contract amendment, it belongs in the security or compliance annex. Specify delivery within 30 days of signing, and updated SBOMs within 14 days of any major release. Having those timelines in writing gives you something to point to if the vendor falls behind.

What a good response looks like

A vendor who has this handled will send you a machine-readable file — JSON or XML — generated directly from their build system, dated, and tied to a specific release version. You should be able to open it and see component names, version numbers, and license identifiers without hunting for them.

What that gives you is practical: when a new vulnerability is disclosed, you can cross-reference your SBOM against it immediately and know whether your software is affected, without waiting for the vendor to tell you. That's the operational value of a properly formatted SBOM that a spreadsheet or PDF list can't replicate.

A few signs a vendor takes this seriously:

• The SBOM was generated automatically rather than assembled by hand.
• It's linked to a specific release rather than the product in general.
• They can describe their update process without needing to check with someone else.

A vendor with a mature SBOM process treats this as routine — it should take them less than a day to respond.

What a vendor's response tells you

How a vendor handles an SBOM request is diagnostic beyond the document itself. Be on the lookout for these four red flags:

1. Refusal on IP grounds. Some vendors claim an SBOM exposes proprietary information. It doesn't — an SBOM lists components, open-source libraries, and dependencies. It doesn't reveal proprietary logic or source code. A refusal on these grounds usually means the vendor hasn't produced one, not that they're protecting trade secrets. Ask them to clarify in writing what information they believe would be exposed.

2. A one-time document with no update process. If a vendor sends you a static document and can't describe how it stays current, treat it as a point-in-time snapshot with an unknown shelf life. The moment a dependency is updated or a new component is added, your SBOM is out of date. Push for a written answer: how do updated SBOMs get delivered after each release?

3. Incomplete component data. Missing licenses, missing version numbers, no dependency relationships — these gaps aren't minor. They limit your ability to assess risk and may not satisfy the documentation requirements of frameworks like the EU Cyber Resilience Act. Request a complete document before accepting it.

4. No SBOM at all. This is less common among established software vendors, but it still happens. A vendor who has never produced an SBOM is running software they haven't fully inventoried themselves. That's not necessarily disqualifying, but it's relevant context for how you manage that vendor relationship going forward.

What to do if a vendor won't or can't produce one

Not every vendor will comply. Some are too small to have the tooling in place. Some are mid-process. Some will decline. If the software is non-critical and the vendor relationship is low-risk, it may be reasonable to note the gap and move on.

For critical software — anything your operations depend on — two options are worth considering alongside each other.

You can make a harder push for the SBOM and make it a contract condition. Enterprise procurement teams include this as a renewal requirement more often now, giving vendors a defined window to produce documentation or risk losing the contract. It's a slow lever, but it's one you have.

The second is software escrow. If you can't see what's inside the software, you can at least guarantee access to it. A software escrow agreement ensures that if the vendor fails, is acquired, or discontinues support, you receive the source code, data, and documentation you need to keep operating. It doesn't tell you what components the software contains — that's what an SBOM does. But for critical vendor relationships where full transparency isn't yet possible, escrow covers a different class of risk: continuity when the relationship ends.

» Learn more about how software escrow can secure long-term software resilience. 

SBOM vendor request checklist

Use this checklist as a standalone attachment to your vendor questionnaire or security review.

Format and delivery

• SBOM provided in CycloneDX or SPDX format (.json or .xml).

• Machine-readable file, not a spreadsheet or PDF table.

• Tied to a specific product version and release number.

• Dated at time of generation.

Content completeness

• All components listed with names and version numbers.

• Supplier or origin information for each component.

• License information for each component.

• Dependency relationships documented.

Ongoing process

• Vendor has confirmed their update process after each major release.

• Delivery timeline for updates specified in writing (e.g., within 14 days of release).

• Named point of contact for SBOM-related questions.

Red flags to document

• Vendor refused on IP grounds — reason requested in writing.

• Vendor provided a spreadsheet or non-standard format — follow-up sent.

• SBOM is undated or not version-linked — completion requested.

• No update process described — contract language required.

What uncooperative vendors are telling you

An SBOM request isn't a technical audit. You're not asking a vendor to prove their code is clean or their architecture is sound. You're asking them to tell you what's in the software you're running your business on. That's a basic documentation question, and in 2026, it's a routine one.

A vendor who treats it as anything other than routine — who pushes back, delays, or produces something that doesn't meet the format requirements — is showing you how they handle accountability when it's inconvenient. That's useful information to have before you renew, not after.

» Some of your critical vendors may not have an SBOM process in place yet. Talk to a software resilience specialist about what software escrow coverage looks like for those relationships.