Answer yes only if you recheck shipped versions against new advisories on a schedule, not just at build time. Describe the trigger, the owner, how you decide whether a customer is affected, and how you notify them. A clean scan on release day says nothing about the next advisory.
Why this question is common
Software does not change after release, but knowledge about it does. An advisory published next month can make last month's build vulnerable. Buyers know this, so they ask whether you will find out and whether they will hear from you.
The mechanics
Hosted alerting from source platforms follows the same pattern: when a new advisory is added to the advisory database, it is matched against the dependency graph and an alert is created if the project is affected. Your process should do the equivalent for every released version still in use, not only the current branch.
You need three things:
- A stored inventory for each released version.
- A feed of new advisories and exploitation data.
- A match step that runs on a schedule and when new data arrives.
Decision table: what happens after a match
| Finding state | Action |
|---|---|
| Affects shipped versions, exploited in the wild | Immediate triage, customer advisory when confirmed |
| Affects shipped versions, vulnerable code reachable | Fix and release per policy timeline |
| Affects shipped versions, not reachable | Record rationale, consider an exploitability statement |
| Does not affect shipped versions | Close with note |
Notifying customers
Define in advance who decides, which channel you use and what the notice contains: affected versions, impact, fixed version, mitigations. State a notification commitment only if it is in your contract or policy. See customer asks: were we affected, how to answer.
A model answer
"We keep a software inventory for each released version and recheck it against new advisory and exploitation data on a recurring schedule. When a match is found we assess whether the vulnerable code is reachable in our product, set a remediation timeline, and notify affected customers through our advisory channel."
Evidence to offer
A description of the monitoring schedule, a sample alert and its triage record, and a past customer advisory if you have one.
Mistakes
Monitoring only the main branch. Forgetting end-of-life versions customers still run. Promising instant notification without a defined trigger.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a new disclosure is matched against what is already shipped. That match is what your answer promises.
Quick check
How often should rechecks run?
Daily is common, and also on each new advisory feed update. Pick a schedule you can keep and state it.
Do older versions need monitoring?
Yes, for every version you still support or that customers still run.
Safeguard offers zero-day discovery, continuous dependency monitoring and a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
