When customers run your software in their own environment, an exception decision is shared with them. Record the affected versions, what a customer can do to limit exposure, and when a fixed release will ship, then communicate it. You cannot accept risk on their behalf.
Hosted software lets you patch once. Shipped software lives on versions you no longer control, and some customers will not upgrade for months.
What changes when you ship to customers
Three things differ from the hosted case.
- Exposure is outside your view. You do not know which customers expose the affected feature to the internet.
- Fixes need adoption. A patch release does nothing until customers install it.
- Your decision becomes their problem. If you defer a fix, every customer inherits that deferral.
Decide with the customer in mind
| Question | Why it matters |
|---|---|
| Is the vulnerable component reachable in a default install? | Defaults reach the most customers |
| Is the CVE on the CISA KEV list? | Known exploitation raises urgency |
| Can customers mitigate by configuration? | A setting may buy time |
| Does a supported older version also need the fix? | Backports can be needed |
If exploitation is known or the default install is exposed, a deferral is hard to justify. Ship the fix.
What goes in the record
- Product, versions, and components affected.
- The exposure analysis: default or optional feature, authentication needed, network position.
- Customer guidance: a configuration change, a feature to disable, or a note that no action is needed.
- Target release and date for the fix.
- Approver, expiry, and review date.
Tell customers, in writing
A security advisory or release note should state the issue, who is affected, the mitigation, and the fixed version. If you are using a VEX statement to say a product is not affected, the OpenVEX specification requires that a not_affected statement include either a justification label or an impact statement, so the reader can see why. Do not use that status for an accepted but still exploitable issue.
Keep the internal record separate
The public advisory is for customers. The internal exception is for auditors. They should agree on facts and dates, but the internal record can hold more detail about compensating controls and decision reasoning.
Review on a clock
Set the expiry to the planned release date plus a small buffer. If the release slips, that is a renewal decision with a fresh review, not an automatic extension.
Where Safeguard fits
Safeguard's SBOM and dependency scanning show which components ship in each build, and its exploitability and reachability analysis helps decide whether the vulnerable code is exposed in a default configuration.
Try it yourself
Click through it at your own pace, or open it full screen. Run the check and compare a finding that is exploitable with one that is not, as you would before choosing customer guidance.
Quick check
Can I use VEX to publish an accepted risk?
VEX describes exploitability status. A not_affected claim needs a justification. An accepted but exploitable issue should be stated as affected, with mitigation guidance.
Who approves the exception for shipped software?
Your own approver, independent of the engineer who owns the code. Customers decide what they run, but not your internal risk acceptance.
Sources
Last reviewed: 19 October 2026.
