If a critical CVE lands during a buyer's review, check your exposure first, then tell the buyer yourself, before they ask. Send a short note: whether you are affected, what you are doing, and when you will update them. Handled well, this is the best proof of process the buyer will see.
Why you should speak first
A buyer's security team reads the same news you do. If they see a major advisory and then hear nothing from you, they assume you do not know or do not care. If you write within hours with a clear status, you show the exact capability they came to test.
The first hours
- Identify the component. Which package, which versions, which condition triggers the flaw?
- Search your inventory. Use your SBOM or dependency scan to find every product and container that includes it.
- Check reachability. Is the vulnerable function used in your code, and is it exposed to untrusted input?
- Check for exploitation. Is the flaw on CISA's Known Exploited Vulnerabilities list? CISA tells organizations to use that catalog as an input to prioritization.
- Decide the action. Fix, mitigate, or document that you are not affected.
This is where a current inventory pays for itself. Teams without one spend the first day just finding out where the package is used.
The note to the buyer
Keep it under 150 words.
| Element | Example wording |
|---|---|
| Status | "We have reviewed the advisory and identified one service that includes the affected library." |
| Impact | "The vulnerable function is not reachable from external input. We are not aware of exposure." |
| Action | "We are upgrading in tomorrow's release and will rescan afterwards." |
| Next update | "We will confirm by end of day on Friday." |
Do not write "not affected" unless you have checked. If the analysis is incomplete, say "assessment in progress" and give a time.
Do not overclaim
Avoid "no customer data was at risk" unless you can support it. Avoid promising a fix date you do not control, such as when an upstream maintainer will publish a patch. State the mitigation you will apply in the meantime.
After the event
Write a short internal note on what you learned: how long it took to find the component, which step was slow, what to automate. Update your runbook. Offer the buyer a copy of the summary if appropriate, with sensitive detail removed. Our guide on a vendor view of zero day response covers the buyer's side of the same event.
Prepare before it happens
You cannot prepare for the specific CVE, but you can prepare the routine:
- Keep an SBOM per release, searchable by package name.
- Subscribe to advisories for your main ecosystems.
- Name an on call owner for advisory triage.
- Keep a template for the buyer note.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a new advisory is matched against what you run, which is the first step in the hours above.
Safeguard offers zero day discovery, reachability analysis and dependency scanning, which cover steps two and three. Try the free scan.
Quick check
Should we tell the buyer even if we are not affected?
A brief note helps if the advisory is widely reported. One sentence saying you checked and are not affected shows good process.
Who should write the note?
An engineer drafts it and the deal owner sends it, so the facts and the relationship both stay in good hands.
Sources
Last reviewed: 19 October 2026.
