When customers host your software, each install is another environment you cannot inspect. You still control what you ship, so track which release each customer runs, publish an SBOM per release, and notify customers when a dependency advisory affects a version they hold. Drift here is mostly about release age.
Why this is the hardest drift
In your own environments you can export package lists. In customer environments you cannot. Customers upgrade on their own schedule, some stay on old releases for years, and some modify the install. A vulnerability in one library can sit in dozens of versions across dozens of sites.
What you can control
| Control | Why it helps |
|---|---|
| One SBOM per release | You know exactly what each version contains |
| A release register | You know which customers run which version, where they tell you |
| Immutable release artifacts with checksums | Customers can verify what they hold |
| A published support window | Customers know when a version stops getting fixes |
| A clear advisory channel | Customers hear about fixes from you first |
Steps to set it up
- Generate and store an SBOM for every release you ship, tied to the release identifier.
- Keep a register of customers and installed versions. Source it from support records, license or update checks that the customer agreed to, and account notes. Do not invent telemetry that customers have not accepted. See phone home and egress inventory for on-premises software.
- When an advisory lands, search release SBOMs for the affected component and version, then list which releases and customers are affected.
- Publish a fixed release and a short note stating the affected versions, the fixed version, and any workaround.
- Follow up with customers on affected versions, through the channel they use.
What to say in an advisory note
Keep it factual: which releases contain the component, whether your product uses the vulnerable function, which release fixes it, and how to upgrade. Avoid claims you cannot verify, and do not promise timelines you do not control.
Let customers see drift too
Give customers a way to compare. A downloadable SBOM and a checksum per release let them check what is installed against what you published. Some customers will ask for this in security reviews, and having it ready shortens the conversation.
Retire versions on purpose
Old versions are the biggest source of drift. Announce end of support dates early, and make upgrading simple. A version nobody supports but many still run becomes a long tail of exposure.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a new advisory is matched against what you use. For customer releases, the same match runs against release SBOMs.
What Safeguard does here
Safeguard produces SBOMs and monitors them against new advisories, which helps you answer which of your releases contain an affected component. Try a free scan at gold.safeguard.sh/scan.
Quick check
Can I require customers to upgrade?
That depends on your contract. Ask your legal advisor. Technically, you can set support windows and make upgrades easy.
Do I need telemetry to track versions?
No. A register built from support records and customer-approved update checks is enough to start.
Last reviewed: 19 October 2026.
