Support should answer with three things: whether the product is affected (yes, no, or still being checked), the time of the next update, and a safe action the customer can take now. Never guess, never say "not affected" before engineering has confirmed it, and never improvise technical detail.
Why support needs a script
A headline vulnerability produces a burst of tickets within hours. Support agents are not security engineers, and they should not have to be. What they need is a single approved answer that engineering and security keep current. Without one, five agents give five different answers, and one of them will say something that turns out to be wrong.
The fix is a shared status page or document with one line per vulnerability: name, current status, last checked time, owner. Support quotes that line. They do not paraphrase it.
The three statuses support can use
Use plain versions of the status values that VEX documents use. In the OpenVEX specification, the statuses are not_affected, affected, fixed and under_investigation. Support does not need the jargon, only the meaning.
| Internal status | What support says |
|---|---|
| Under investigation | We are checking whether this affects our product. Next update by a stated time. |
| Not affected | Our product is not affected. Engineering has confirmed this and the reason is available on request. |
| Affected, mitigation available | Yes, and here is the step to take now while a fix is prepared. |
| Fixed | A fixed version is available. Here is how to get it. |
A not affected answer should always have a reason behind it. The OpenVEX specification says a not_affected statement must carry either a status justification or an impact statement explaining why the product is not affected. If engineering cannot give you the reason, the honest status is still under investigation.
A macro you can adapt
Thank you for asking about the vulnerability in the news. Our security team is tracking it. Current status: [status line from the shared page, last checked at time]. We will update this page by [time]. In the meantime, [one specific safe action, or: no action is needed from you]. If you need a written statement for your own records, reply and we will send one once the status is confirmed.
Keep the macro short. Do not name affected versions unless the shared page does. Do not speculate about attackers.
What not to say
- "We are not vulnerable" before a confirmed status exists.
- "This is only a low risk" without a stated basis.
- Anything about exploitation in the wild unless the security team has supplied the wording.
- Promises of fix dates that engineering has not committed to.
Escalation rules
Give agents a short list of tickets that skip the macro and go straight to security: customers who say they have seen exploitation, customers asking for a formal letter, regulated customers with a notification clause, and anyone who shares what looks like a working exploit. The agent should acknowledge, not argue, and hand off.
Review the macro after every event. If agents kept getting the same follow-up question, put the answer in the next version.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding moves from open to resolved, and notice that every state has an owner. That is the same discipline the shared status line needs.
Where Safeguard fits
Safeguard can help here: the free scan at gold.safeguard.sh/scan lists the dependencies in a project and the known issues attached to them, and reachability analysis shows which findings your code can actually hit. That gives support's status line a factual starting point instead of a guess.
Quick check
Can support say a product is not affected if the scanner shows nothing?
Not on that alone. A clean scan can miss things, so wait for engineering to confirm the status and the reason.
How often should the shared status line be updated?
Whenever the status changes, and at the time you promised in the last update, even if the update is that nothing has changed.
Sources
Last reviewed: 19 October 2026.
