First confirm whether the client's site actually uses the vulnerable package and code path. Then check the agreement for who owns post-launch fixes, tell the client what you found in plain words, patch or mitigate, and record the decision. Do the first two steps within hours, since they determine everything after.
This is operational guidance, not legal advice. Your contract decides obligations.
Step 1: confirm exposure
An advisory mentions a package and version range. Compare it to the client's lockfile and the dependency inventory from handover. Three outcomes are possible: the package is not present, it is present but the vulnerable function is not called, or it is present and reachable.
A scan that includes reachability helps tell the second from the third, though a human should still confirm for anything serious.
Step 2: check who owns the fix
Open the statement of work or maintenance agreement. Is there a warranty window? A retainer? Nothing? If it is unclear, do not argue about it first. Tell the client, fix the urgent items if you can, and sort the commercial side afterward. A client who was left exposed over a billing question remembers it.
Step 3: tell the client
Keep the message short and factual.
- What was disclosed, with a link.
- Whether their site is affected, and how you know.
- What you recommend, and by when.
- Whether it needs a decision from them, such as downtime or cost.
- What you do not know yet.
Avoid jargon and avoid false comfort. Do not say "no risk" when you mean "we have not seen exploitation." Our post on how to tell a client their plugin is vulnerable has wording for the harder cases.
Step 4: patch or mitigate
| Situation | Action |
|---|---|
| Fixed version exists, low change risk | Update, test, deploy |
| Fixed version needs a major upgrade | Plan; use a temporary mitigation if available |
| No fix upstream | Use an override or workaround, or remove the feature |
| Not reachable | Record the reasoning, set a review date |
Use the lockfile diff to confirm only intended packages changed. Redeploy, then re-scan to confirm the advisory has cleared.
Step 5: record and learn
Write down the date of disclosure, date you learned, date of fix, and the decision. Update the client's dependency inventory. Ask what would have caught it sooner: a scheduled scan, an alert subscription, a shorter update cadence.
Prevent the scramble
- Subscribe to alerts on the client's repository from the day of launch. GitHub, for example, can raise alerts for dependencies with known vulnerabilities based on the dependency graph.
- Keep the handover inventory current.
- Agree the response rules before you need them.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and see how exposure, severity and status sit together. That is the record you want for each client advisory.
Quick check
Should we patch without asking the client?
If the contract covers it and the change is low risk, usually yes, with notice. Otherwise ask first.
How fast is fast enough?
It depends on severity, exploitation evidence and the site. Agree targets in writing ahead of time.
Sources
Last reviewed: 19 October 2026.
