Match the message to one of four outcomes: still checking, affected with no fix yet, fixed, or not affected. The OpenVEX specification uses the same four statuses: under_investigation, affected, fixed and not_affected. Give each customer a clear status, an action if one exists, and a time for the next update.
Why four outcomes work
During the first hours after a public dependency issue, customers do not need a long essay. They need to know which box they are in. Using a small fixed set of statuses keeps your message consistent between support, sales and the website.
OpenVEX defines these meanings: not_affected means no remediation is required, affected means remediation or mitigation is recommended, fixed means the product versions contain a fix, and under_investigation means it is not yet known whether the product is affected.
The decision table
| Outcome | What to publish | Must include |
|---|---|---|
| Still checking | A short holding note | Time of next update, what you are checking |
| Affected, no fix yet | Advisory with workaround | Versions, mitigation, expected update time |
| Fixed | Advisory with upgrade path | Fixed versions, how to confirm the upgrade |
| Not affected | Short statement | Reason, versions checked, date |
For affected statements, OpenVEX says an action statement describing how to remediate or mitigate must be included. Apply the same rule to your messages: never say "affected" without saying what to do.
Steps for the first day
- Identify the products and versions that include the dependency, using your SBOM or dependency inventory.
- Sort each product into one of the four outcomes.
- Post a holding note for any that are unresolved. Do not guess.
- Publish a clear message for the ones that are resolved.
- Brief support and sales with the exact wording, so customers get one answer.
- Set the next update time and keep it.
- When status changes, revise the note and say what changed. See correcting a published advisory.
Wording that stays honest
Avoid certainty you do not have. Prefer "we have not found evidence of exploitation as of this date" to "no customers were affected". Avoid timelines you cannot meet. A time for the next update is a smaller promise than a time for the fix.
Different customers need different depth
Some customers want a single sentence. Others, such as security teams, want a machine readable file, version ranges and a contact. Offer a short statement first, with a link to detail. That respects both.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a newly published issue is matched against an existing inventory.
Quick check
Can I say not affected while still checking?
No. Use "under investigation" until you have a reason and a version list.
Do I need to publish if the answer is not affected?
Not always, but customers who ask should get a clear, dated answer with a reason. Publishing a short statement can save many tickets.
Safeguard's SBOM and dependency scanning, plus continuous monitoring, help teams sort products into these outcomes quickly. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
