SBOM Inventory or VEX Statement: Which Answers a Buyer's Vulnerability Question?
A product-security sales lead's guide to separating component inventory (SBOM) from affected-status context (VEX) before qualifying a vendor-onboarding request.
A buyer’s request usually says “send your SBOM,” but the artifact you deliver should match the question behind it. Use a software bill of materials (SBOM) — a nested inventory of the components inside a product, as defined by CISA — when the buyer asks what the product contains; use a Vulnerability Exploitability eXchange (VEX) statement — a document stating whether a product is affected by a known vulnerability — when the buyer asks whether a specific Common Vulnerabilities and Exposures (CVE) identifier affects a named product version; and use both when the buyer needs both questions answered. For a product-security sales lead qualifying vendor-onboarding requests, it decides what your team can produce, who owns it, and what counts as done.
CISA’s Software Bill of Materials (SBOM) resource hub (accessed 3 August 2026) treats the SBOM as an inventory and the VEX document as a separate attestation of affected status; a request for an SBOM names an artifact category, not whether the buyer needs existing-file access, new generation, format normalization, or ongoing updates.
Two artifacts, two questions
A security review asks two questions. Inventory: which components, versions, and suppliers make up the product? The SBOM answers that. Affected status: does a known vulnerability affect this product, and why? The VEX statement answers that with a status and justification, per CISA’s Minimum Requirements for VEX (published 21 April 2023, retrieved 3 August 2026).
Product context is the part sales roles most often miss. OWASP CycloneDX’s VEX capability page (accessed 3 August 2026) explains that VEX conveys the exploitability of vulnerable components in the context of the product in which they are used; a scanner result alone does not establish whether a component is reachable, affected, or ready for a release decision.
Five fields that separate an SBOM from a VEX statement
Run every request through the same five fields for both artifacts.
| Field | SBOM | VEX statement |
|---|---|---|
| Named product and version | Lists every component, its version and supplier inside a named product | Names the product and version the vulnerability is judged against |
| Question answered | What is in this product? | Is this product affected by this known vulnerability, and why? |
| Update trigger | A dependency or a release changes | A new CVE is disclosed or the affected status changes |
| Evidence owner | Build and release engineering | Product security, with a named owner for status and justification |
| Delivery or acceptance condition | A machine-readable file that can be imported and compared | Status plus justification per CVE, accepted against the buyer’s stated criteria |
NTIA’s Minimum Elements for a Software Bill of Materials (published 12 July 2021, retrieved 3 August 2026) lists supplier name, component name, version, unique identifiers, dependency relationship, author and timestamp as SBOM data fields; CISA’s VEX minimum requirements (published 21 April 2023, retrieved 3 August 2026) require product or version, vulnerability identifier, component path, status, justification owner and release decision. A scanner finding without those starts a VEX conversation, not the document — see turning a scanner finding into a complete request.
Key facts from the official sources
- CISA, SBOM resource hub, accessed 3 August 2026: SBOM is a nested component inventory; VEX is an attestation of affected status.
- CISA, Minimum Requirements for VEX, published 21 April 2023, retrieved 3 August 2026: VEX communicates affected status with status and justification.
- NTIA, Minimum Elements for an SBOM, published 12 July 2021, retrieved 3 August 2026: minimum elements span data fields, automation support, and practices and processes.
- OWASP CycloneDX, VEX capability, accessed 3 August 2026: exploitability is judged in product context, not scanner results alone.
- Telegram Privacy Policy, accessed 3 August 2026: bots are independent third-party services; the interface shows message-access mode, and developers should ask permission before accessing data.
These dates are document history, not buyer intent: they say when a standard was issued or accessed, nothing about a buyer’s urgency or whether an artifact will be accepted.
A composite onboarding request, worked through
Composite request (illustrative, not a customer message). This Telegram message arrives from a prospective buyer during onboarding:
Hi, we need your SBOM before we add you as a vendor. Please confirm whether CVE-2025-1234 affects version 2.4, and send updates whenever new vulnerabilities are published. Security review closes Friday.
The quote, CVE identifier, deadline and vendor context are invented for this walkthrough, not from any customer. Apply the five fields:
- Named product and version: the message names version 2.4, so the SBOM must cover that release, not the whole line.
- Question answered: the buyer asks two questions — “your SBOM” (inventory) and “does CVE-2025-1234 affect 2.4” (affected status). Both artifacts are needed.
- Update trigger: “send updates whenever new vulnerabilities are published” is a VEX trigger, not an SBOM trigger — SBOMs change when components change, VEX statements when CVEs are disclosed.
- Evidence owner: release engineering signs the SBOM; product security must name an owner for each VEX status and justification.
- Delivery or acceptance condition: the SBOM ships as an importable file; the VEX is accepted only if each entry names product, version, CVE, status and justification — the message names no CVE list or acceptance criteria, so the first reply asks for those.
The gap is the finding: the SBOM can ship if the file exists; the VEX half waits on the buyer’s CVE list and review criteria.
Why the distinction matters
Neither artifact is a security certificate. An SBOM is an inventory; a VEX statement is a status claim. Accepting either does not mean the buyer approved the vendor, and presenting either as proof of security invites a failed review. An SBOM also differs from build provenance: inventory says what is inside the product, provenance describes how it was built — see how the two evidence types differ in onboarding.
What remains unknown must be verified: your product team checks that the SBOM matches the shipped release and each VEX status is defensible; the buyer checks that the artifacts meet their acceptance criteria. Sales cannot declare either step complete for them.
Once the artifact route is settled, the same discipline applies to onboarding’s human side. TOP Prospect processes only Telegram groups a user intentionally connects and is authorized to access, produces candidates for a person to review rather than certifying facts, leaves the decision to a human, and does not contact group members automatically — consistent with Telegram’s privacy policy, which describes bots as independent third-party services whose access mode the interface shows. If triaging group messages is your next question, the workflow is on the product pillar.
FAQ
Is an SBOM a security certificate? No. An SBOM is a component inventory; receiving one says nothing about whether the product is secure.
When does a buyer actually need a VEX statement? When the question is whether a specific CVE affects a named product version, and why.
Can one document cover both? CycloneDX can carry VEX data inside an SBOM, but acceptance differs: the inventory must be complete, and each VEX entry must name product, version, CVE, status and justification.
Next time a message says “send your SBOM,” count how many of the five fields you can fill from the message alone. The empty fields are the questions you send back.
Frequently asked questions
Is an SBOM a security certificate?
No. An SBOM is a component inventory; receiving one says nothing about whether the product is secure.
When does a buyer actually need a VEX statement?
When the question is whether a specific CVE affects a named product version, and why.
Can one document cover both?
CycloneDX can carry VEX data inside an SBOM, but acceptance differs: the inventory must be complete, and each VEX entry must name product, version, CVE, status and justification. Next time a message says "send your SBOM," count how many of the five fields you can fill from the message alone. The empty fields are the questions you send back.
Sources and further reading
- CISA, Software Bill of Materials (SBOM) resource hub (accessed 3 August 2026)
- CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX) (21 April 2023)
- OWASP CycloneDX, Vulnerability Exploitability eXchange capability (accessed 3 August 2026)
- NTIA, The Minimum Elements for a Software Bill of Materials (12 July 2021)
- Telegram Privacy Policy (accessed 3 August 2026)
