# How to Request an SBOM from a Vendor: The Language That Works > Most buyers never receive a vendor SBOM because most buyers never actually ask in a way that gets answered. The request has to be a named artifact, in a named format, on a stated clock, with a consequence for silence. Here is the language that works, the contract clauses that make it stick, the regulatory backstops to cite when the vendor hesitates, and what to do the day the file actually arrives. - **Published**: 2026-10-26 - **URL**: https://vendorquals.com/blog/how-to-request-sbom-from-vendor --- # How to Request an SBOM from a Vendor: The Language That Works *Most buyers never receive a vendor SBOM because most buyers never actually ask in a way that gets answered. The request has to be a named artifact, in a named format, on a stated clock, with a consequence for silence. Here is the language that works, the contract clauses that make it stick, the regulatory backstops to cite when the vendor hesitates, and what to do the day the file actually arrives.* ## Key takeaways - **Ask for the artifact, not the assurance.** "Send us your SBOM in CycloneDX or SPDX JSON format, covering commercial, open-source, and off-the-shelf components, within 10 business days" gets answered. "Please share your security documentation" gets a brochure. - **The regulatory backstops do the persuading.** FDA section 524B requires the SBOM for cyber devices; the EU Cyber Resilience Act requires a machine-readable SBOM in product technical documentation with the main obligations from December 2027. A vendor selling into either market already owes this document to someone. - **Put it in the contract, with a clock.** SBOM clauses with delivery triggers (at signing, at each release, within 30 days of a major change) turn a one-time ask into a standing obligation, and they already appear in public contract-language patterns. - **Expect the two real objections.** "We do not produce one" is a maturity signal about their pipeline; "it is confidential" is a scoping negotiation, and both answers are resolvable. - **When the file arrives, the checkpoint starts.** A received SBOM is an inventory, not evidence: it needs the seven-element check and the vulnerability match. [How to verify a vendor's SBOM ->](/blog/vendor-sbom-verification) ## Why the ask fails when it fails The buyers who never get an SBOM usually asked for one of these instead: "do you have an SBOM policy?" (the answer is a paragraph about commitment), "are you secure?" (the answer is a certification PDF), or nothing at all. The request fails for the same reason most procurement asks fail: it names a topic instead of an artifact. A request that works names four things: 1. **The artifact**: an SBOM. 2. **The format**: CycloneDX or SPDX, machine-readable JSON (not a PDF, not a screenshot, not an email list). 3. **The scope**: commercial, open-source, and off-the-shelf components (the exact scope FDA's statute uses, and the scope that keeps a vendor from listing only their own code). 4. **The clock and the consequence**: by a date, delivered to a named channel, with the follow-up defined if it does not arrive. ## The request email, ready to send Adapt as needed; keep the four named things: > Subject: SBOM request for [product], [your company] > > As part of our vendor security review for [product], please provide a Software Bill of Materials covering the commercial, open-source, and off-the-shelf software components in [product] and its dependencies. > > Format: CycloneDX 1.5+ or SPDX 2.2+ JSON. Machine-readable: a JSON file, not a PDF or summary. Content: component names, versions, supplier, unique identifiers (purl or CPE), dependency relationships, and generation date, per the NTIA minimum elements. > > Delivery: within 10 business days, to [channel]. > > This supports our obligations under [your regulator or framework: FDA section 524B / the EU Cyber Resilience Act / DFARS 252.204-7012 supply chain visibility / our cyber insurance panel's vendor requirements]. If the file will take longer, tell us the date; if your practice differs, tell us what you provide instead and in what format. The last line exists because it converts silence into an answer. Most vendors who will not produce an SBOM will say so once asked specifically, and that answer is procurement information in itself. ## The contract clauses that make it standing language Public procurement patterns already carry SBOM delivery clauses; the shapes worth adopting: - **At signing:** "Vendor shall provide a complete SBOM in SPDX or CycloneDX format for each product at the time of first delivery." - **At each release:** "Vendor shall provide an updated SBOM with each major release of the product." - **On significant change:** "Vendor shall update the SBOM within 30 days of any significant change to the product's software components." - **On vulnerability discovery:** "Vendor shall notify the customer within [N] hours of learning of a critical vulnerability in any component listed in the SBOM, including the remediation plan." The notification clock is the one that matters most under pressure, and it pairs with [the breach response clauses every vendor contract should carry ->](/blog/vendor-contracts-breach-response-clauses). The DFARS pattern is worth knowing even outside defense: 48 CFR 252.204-7012 requires covered contractors to report cyber incidents within 72 hours and preserve data, and the SBOM is the artifact that makes a software incident reportable in component terms rather than prose. If your vendor is anywhere in the defense supply chain, they already live with a version of this clock. ## The two real objections, and the answers **"We do not produce SBOMs."** This is a pipeline maturity signal, and it is more common than the marketing suggests. The answers, in escalating order: open-source generators (Syft, Trivy, cdxgen) produce a workable SBOM from a container image or a codebase in minutes, at no license cost; the vendor's own build tooling (Microsoft's SBOM tool, GitHub's dependency graph export) produces one as a byproduct; and if none of that is possible, the question is what their software inventory actually is, which is a diligence finding to record, not a reason to end the conversation. **"The SBOM is proprietary; it reveals our stack."** This is a scoping negotiation, not a refusal. The workable middle grounds: a top-level SBOM (direct dependencies only, which is the scope the EU CRA accepts), a SBOM held in escrow (deposited with a neutral party, released on defined triggers), or a brokered check (a named third party verifies the file against the minimum elements and reports the verdict without the inventory crossing the boundary). The vendor who refuses all three while selling into a market with an SBOM requirement is telling you where they sit on the maturity curve. ## The regulatory backstops, cited When the vendor hesitates, the ask stops being yours alone: - **FDA section 524B** (21 U.S.C. 360n-2, for cyber devices): requires the manufacturer to provide an SBOM covering commercial, open-source, and off-the-shelf components in premarket submissions. A medtech vendor is already producing this document for FDA; the procurement ask is a copy of work they have already done. - **The EU Cyber Resilience Act** (Regulation (EU) 2024/2847, for products with digital elements): requires a machine-readable SBOM covering at least top-level dependencies, kept in the technical documentation, with the main obligations applying from December 2027. Any vendor selling into Europe is on this clock whether they have read the regulation or not. - **US Executive Order 14028 and the NTIA minimum elements** (July 12, 2021): the federal foundation for the whole practice, and the checklist that defines what makes a delivered SBOM usable rather than decorative. Cite the one that applies to your market. The vendor who still refuses with a live regulation behind the ask has answered a different, more useful question. ## The day the file arrives The request is the half of the checkpoint anyone can do. The verification is the half that makes the request worth making: the format check, the seven NTIA elements one by one, and the live vulnerability match against OSV. [The step-by-step verification guide ->](/blog/vendor-sbom-verification) Both halves are free and browser-side: [check the SBOM when it arrives ->](/tools/sbom-checker) ## Frequently asked questions **Can I really ask a vendor for this?** Yes. It is an inventory of the software you are buying, in the formats the industry standardized for exactly this exchange. The vendor may scope it, negotiate it, or escrow it, but the ask itself is ordinary procurement diligence. **What if the vendor is a giant with a standard no?** Large vendors increasingly publish SBOMs for regulated products and resist them for everything else. The regulatory backstop is your best lever there (the FDA obligation, the CRA date), and the escrow or brokered-check middle grounds exist precisely for vendors who treat the inventory as proprietary. **Should the SBOM request live in the RFP or the contract?** Both. The RFP asks for it (so every bidder prices it in); the contract obliges it (with the delivery triggers and the notification clock). A request that lives only in the RFP dies at signature. **What is a purl and why does the request mention it?** A package URL: the standard identifier that makes a component checkable against vulnerability databases. Asking for it by name in the request, as part of the NTIA element list, prevents the delivery of a name-and-version-only file that cannot be matched against anything. **What happens if the vendor refuses outright?** Three things, in order. First, record it: a refusal is a diligence finding about their software pipeline, and it belongs in the vendor file next to whatever they did provide. Second, check whose obligation this actually is: for regulated buyers the SBOM duty sits with the manufacturer (FDA 524B) or with anyone selling products with digital elements into Europe (the EU CRA, from December 2027), so a vendor refusing to share the artifact is still producing it for someone, and the refusal is a sharing decision, not a production gap -- which the regulatory citation usually converts. Third, if the refusal stands, the middle grounds (top-level scope, escrow, a brokered check) keep the checkpoint alive; a vendor who refuses all three while selling into a market with a live requirement is answering the qualification question you were about to ask the hard way. **How does this connect to the rest of vendor due diligence?** The SBOM covers the software's ingredients; the evidence-graded directory covers the firm behind them. A vendor whose SBOM checks out and whose firm is documented, source-cited, is the complete checkpoint: [search the firm ->](/tools/firm-visibility-check) Make the request with the language above. [Check the SBOM when it arrives ->](https://vendorquals.com/tools/sbom-checker) --- *The regulatory references here reflect FDA section 524B and its guidance chain, the EU Cyber Resilience Act as published, DFARS 252.204-7012, and the NTIA minimum elements document (July 12, 2021, under EO 14028), as last reviewed; regulations change, so verify current requirements with counsel before relying on them. Last verified: October 2026. Have a correction or addition? [Request inclusion or a correction ->]* Source: https://vendorquals.com/blog/how-to-request-sbom-from-vendor. This page is also served as HTML at https://vendorquals.com/blog/how-to-request-sbom-from-vendor. --- - [All articles](https://vendorquals.com/blog)