To track which customers run an affected version, join your SBOM hit list to whatever records link releases to customers: download and licence logs, support tickets, update checks where they exist, and account notes. Where records are missing, tell those customers to check themselves rather than guessing.
Start from the release, not the customer
Your SBOM search gives you products and releases that include the vulnerable component. Customers are a second step. Keep them separate in your working sheet so a data gap on the customer side does not blur the technical verdict.
Sources of customer to release links
| Source | What it tells you | Limit |
|---|---|---|
| Download or licence records | Which release was issued to whom | Customer may not have installed or upgraded |
| Update or telemetry checks | Version in use, if enabled | Often disabled in locked down networks |
| Support tickets and logs | Versions customers reported | Stale quickly |
| Account manager notes | Context on deployment type | Informal and uneven |
| Customer's own SBOM or scan | Authoritative for their environment | They have to share it |
Steps
- List the affected releases from your SBOM hits.
- For each release, pull the customers with a matching issued or reported version.
- Mark confidence: confirmed from telemetry, probable from records, unknown.
- Tier customers by exposure (see which customers to notify first).
- Send notices that state the affected version range plainly, so customers can check without waiting for you.
- Track upgrades as customers confirm them, and keep the sheet current.
Give customers a self check
Customers who cannot be identified still deserve a clear way to check. A good self check section has three parts: where to find the product version, the affected version range, and the fixed version. If the component can be listed with a command or a file path, include that. Keep the commands generic and test them before publishing.
Be honest about confidence
State in the notice that your records show certain customers on affected releases, and that you cannot see every installation. The CISA minimum requirements for VEX note that VEX information may be incomplete and does not require an author to list every product known to exist. Saying what you do not know is acceptable, while claiming completeness is not.
Closing the loop
Mark a customer as done only when they confirm the upgrade or when your telemetry shows the new version. A sent email is not a fix. Set a reminder for customers who stay silent on high exposure deployments, and offer help from support or customer success.
Quick check
What if we sell to customers who run offline?
You will have no telemetry. Rely on licence records and send a clear self check with the notice.
Should we contact customers on affected versions we cannot confirm they run?
Yes, with wording that says you believe they may be affected and how to verify.
Safeguard's compliance and evidence automation can help keep the records for these steps in one place.
Sources
Last reviewed: 19 October 2026.
