"We Need VEX for This Scanner Finding"—Is the Request Ready for a Sales Call?
A scanner finding in a group message is not a VEX service request until you collect the product, version, CVE, component path, status, justification owner and release date. This how-to walks a product-security services business-development lead through the five-question qualification chain that separates a conversation starter from a qualified opportunity.
The short answer: no, not yet. A scanner finding pasted into a group message is a conversation starter, not a qualified service request. Before you put it in front of a sales call, you need five specific pieces of information the original message almost certainly does not contain.
What each term means before you qualify the request
Three core entities appear in nearly every VEX inquiry, and the person qualifying the lead needs to understand them well enough to spot what is missing.
A Vulnerability Exploitability eXchange (VEX) is a structured attestation that states whether a specific product is affected by a known vulnerability. It pairs a status — such as “affected,” “not_affected,” or “under_investigation” — with a justification that explains the reasoning (CISA, Minimum Requirements for Vulnerability Exploitability eXchange, published 21 April 2023). Without the exact product and version, a VEX document cannot be written at all.
A Software Bill of Materials (SBOM) is a nested inventory of the components that make up a software product (CISA, SBOM resource hub, accessed 3 August 2026). An inquiry that says “we also need an SBOM” tells you the artifact category the prospect wants; it does not tell you whether they need access to an existing file, new generation, format normalisation or ongoing updates. Treat SBOM as a separate scoping question.
A Common Vulnerabilities and Exposures (CVE) identifier is the unique label for a publicly disclosed vulnerability. If the scanner output does not include a CVE, the team that writes the VEX has nothing to assess.
The five-question qualification chain
Work through these questions in order. Each depends on the answer to the one before it.
1. Preserve the scanner finding exactly
Ask the prospect to paste the raw scanner output — not a screenshot, not a summary. The tool name, scan date, target and complete finding text all matter. A paraphrased request such as “we got a high on OpenSSL” gives you no component path, no CVE and no version range. Store the raw finding before you ask anything else.
2. Identify the exact product, version and component path
This is where most group-message requests stall. “Our web app” is not a product. You need the commercial product name, the version or build identifier, and the path to the vulnerable component inside that product — for example, acme-portal v4.2.1 / lib/openssl.so. OWASP CycloneDX describes VEX as conveying exploitability “in the context of the product in which they are used” (CycloneDX VEX capability page, accessed 3 August 2026). Without that product context, you cannot determine whether the component is reachable.
3. Select a supported VEX status
The CISA minimum requirements list four recognised statuses: not_affected, affected, fixed and under_investigation. Each requires a justification. Do not let the scanner severity drive this choice: a “critical” scanner finding can be not_affected if the vulnerable function is unreachable in the product build.
4. Obtain the evidence-backed justification and accountable owner
The justification answers why the status applies. Acceptable justifications include component_not_present, vulnerable_code_not_in_execute_path, inline_mitigations_exist or vulnerable_code_cannot_be_controlled_by_adversary. Ask: who inside the prospect’s organisation or the product vendor can document this evidence and sign off on it? An unattributed justification has no weight in a customer assurance process.
5. Record the release decision and date
A VEX document needs a dated release decision — even if the status is under_investigation with a planned review date. Without a date, the recipient cannot track currency. Confirm who will publish the statement and when.
An illustrative group message
The following composite example shows how a typical inquiry arrives and what it leaves out. Every detail is illustrative.
[Composite / illustrative Telegram message] “Hey team — our client ran a Nessus scan and got a critical on Apache Log4j. They want a VEX by Friday. Anyone available?”
This message names a scanner and a component family but omits the product, version, CVE, component path, exploitability status, justification owner, and release date. It is a lead, not a booked engagement. The correct reply asks for the raw scan output and the product context, then routes the request to the right queue.
A small route table
Once you have collected as much as the prospect can supply, route the request to the shortest possible next step.
| What you have | Route to |
|---|---|
| Raw scanner output only, no product context | Evidence collection — ask for product, version and component path |
| Product context present, no CVE or justification | Evidence collection — ask for the CVE and reachability analysis |
| Product, CVE, justification and owner confirmed | VEX authoring |
| Non-standard product or regulatory question | Specialist review |
| Scanner finding with no confirmed affected status | Watch — revisit when the vendor advisory or exploit data matures |
Key facts from the official sources
- CISA VEX minimum requirements (21 April 2023): The document specifies the minimum elements for a VEX document, including the product identifier, vulnerability identifier, affected status, justification and release date. These are baseline interoperability fields, not optional extras.
- CISA SBOM resource hub (accessed 3 August 2026): An SBOM is defined as a nested inventory of software components. The page separately describes VEX as an attestation indicating whether products are affected by known vulnerabilities. An SBOM inquiry without further qualification tells you the artifact type, not the scope of work.
- OWASP CycloneDX VEX capability (accessed 3 August 2026): VEX communicates exploitability in the product context. A general scanner result alone does not establish reachability or affected status.
- Telegram Privacy Policy (accessed 3 August 2026): Bots are independent third-party services that operate with or without message access, shown in the interface. Developers should ask permission before accessing data. This supports limiting any automated review to groups the user intentionally connects and is authorised to access.
Why it matters: a worked example
Imagine a prospect forwards a scanner alert: “CVE-2024-3094 in xz Utils — critical, need VEX.” You ask the five questions and discover the product is an internal dashboard that ships xz but never calls the compromised compression path. The reachability analysis shows vulnerable_code_not_in_execute_path. The VEX status is not_affected, the justification is documented, and the internal security team owns the release with a target date of 15 August 2026.
Without the qualification chain, the same inquiry could have been routed directly to VEX authoring as affected — producing a statement that misrepresents the actual risk and wastes a specialist’s time.
What remains unknown after qualification: the scanner’s false-positive rate for this CVE in this product version, whether the component path analysis is current against the latest build, and whether the prospect’s downstream customers accept not_affected with a code-path justification or require additional evidence. Each unknown belongs to a named owner before the request moves to authoring.
FAQ
Do I need a full SBOM before I can produce a VEX document?
An SBOM describes the component inventory that a VEX statement references. An existing SBOM speeds up component-path identification, but it is not a strict prerequisite: the minimum VEX fields defined by CISA (21 April 2023) require the product, version and vulnerability identifier, not an SBOM. If the prospect cannot supply either an SBOM or the component path, route to evidence collection first.
Can a scanner severity score substitute for a VEX status?
No. A scanner assigns a generic severity to a CVE; a VEX status states whether that CVE affects a specific product as used. OWASP CycloneDX (capability page, accessed 3 August 2026) underlines that exploitability must be assessed in the context of the product. A “critical” scanner finding can be not_affected in a particular build. Routing a scanner score as a VEX status skips the product-context step and produces a misleading attestation.
Who owns the release decision when the VEX is for a third-party component?
The product vendor or the organisation that builds and distributes the assembled product owns the release decision. The component upstream may issue its own advisory, but the VEX status and dated release belong to the entity that ships the product the prospect runs. If the prospect is the end-user organisation and not the vendor, confirm whether an internal security team can serve as the accountable owner or whether a vendor engagement is required before routing to VEX authoring.
When the method runs at scale
The qualification chain above works for one inquiry at a time. When a security services team monitors multiple group channels — industry forums, user communities, partner channels — the same pattern of incomplete scanner-to-VEX requests recurs across them. Recognising the missing fields and routing each request before a sales conversation starts becomes the bottleneck.
TOP Prospect reads only Telegram groups the user intentionally connects and is authorised to access. It produces candidates for review rather than fact certification, leaves the qualification decision to a person, and does not contact group members automatically. Teams that track scanner-finding discussions across groups can use it alongside the method described in /blog/telegram-signal-provenance/ and the confidence framework in /blog/business-signal-confidence-scoring/ to surface incomplete VEX inquiries before they age out of a busy channel. The product pillar is /telegram-business-signal-intelligence/.
Next step: Take the last three scanner-finding messages that arrived in your group channels and list what each one omitted. If all three are missing at least three of the five qualification fields, add a short “what we need” template to your first-response routine.
Frequently asked questions
Do I need a full SBOM before I can produce a VEX document?
An SBOM describes the component inventory that a VEX statement references. An existing SBOM speeds up component-path identification, but it is not a strict prerequisite: the minimum VEX fields defined by CISA (21 April 2023) require the product, version and vulnerability identifier, not an SBOM. If the prospect cannot supply either an SBOM or the component path, route to evidence collection first.
Can a scanner severity score substitute for a VEX status?
No. A scanner assigns a generic severity to a CVE; a VEX status states whether that CVE affects a specific product as used. OWASP CycloneDX (capability page, accessed 3 August 2026) underlines that exploitability must be assessed in the context of the product. A "critical" scanner finding can be `not_affected` in a particular build. Routing a scanner score as a VEX status skips the product-context step and produces a misleading attestation.
Who owns the release decision when the VEX is for a third-party component?
The product vendor or the organisation that builds and distributes the assembled product owns the release decision. The component upstream may issue its own advisory, but the VEX status and dated release belong to the entity that ships the product the prospect runs. If the prospect is the end-user organisation and not the vendor, confirm whether an internal security team can serve as the accountable owner or whether a vendor engagement is required before routing to VEX authoring.
Sources and further reading
- CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX) (21 April 2023)
- CISA, Software Bill of Materials (SBOM) resource hub (accessed 3 August 2026)
- OWASP CycloneDX, Vulnerability Exploitability eXchange capability (accessed 3 August 2026)
- Telegram Privacy Policy (accessed 3 August 2026)
