When a supplier's product may be affected by an advisory, send one short message asking five things: whether the product is affected, which versions, whether a fix or mitigation exists, whether they can share an SBOM or VEX, and when they will update you. Name the exact component and your deployed version.
Why the first message matters
During an incident, suppliers receive many vague emails. A message that names the component, the advisory and your deployed version is easy to route to the right engineer. The CISA minimum requirements for VEX note that VEX documents can be authored by the supplier or a third party, and that a statement gives a status for a product with respect to a vulnerability. Those are the answers you are asking for, so ask for them in those terms.
What to put in the message
- The advisory or identifier and the component name.
- Your product name and the version or release you run.
- The question: is this product affected, not affected, fixed or under investigation?
- Requested evidence: a VEX statement, a security notice, or an updated SBOM for that release.
- The action you need: fixed version, workaround, or confirmation that none is needed.
- A response time and a named contact on your side.
A short template
"We run [product] [version] in [environment]. Advisory [identifier] concerns [component]. Please confirm the status of this product (affected, not affected, fixed, or under investigation), the affected versions, and any fix or mitigation. If you can share a VEX statement or an SBOM for this release, please attach it. We will update our own customers by [time], so a reply by [time] would help."
Keep it neutral. Do not suggest the supplier is at fault.
Follow-up rules
| Situation | What to do |
|---|---|
| No reply by your deadline | Re-send to a security contact, and note the gap in your incident record |
| Reply says under investigation | Ask for a time for the next update |
| Reply says not affected without detail | Ask for the justification or impact statement |
| Reply says affected | Ask for the action statement and plan your own remediation |
What to do in the meantime
You can act without waiting. Check your own SBOM and deployment records for the product (see finding where you run a supplier's product), consider temporary controls around the system, and record that you asked. If a supplier will not share an SBOM at all, the post on what to do when a supplier will not provide an SBOM covers next steps.
Quick check
Should we ask for an SBOM in the first message?
Yes, as an optional request. Status and a fix path come first, but an SBOM speeds your own verification.
Who should receive it?
A security contact or product security team if one is published, plus your account contact.
Safeguard's SBOM and dependency scanning can ingest what a supplier sends and match it to advisories.
Sources
Last reviewed: 19 October 2026.
