A library owner should publish a service level that states how fast it will acknowledge, assess and release a fix for each severity, and how fast consumers must upgrade. Keep the numbers modest, tie them to evidence, and review them after every real incident.
Two clocks, not one
A fix has two clocks. The owner's clock runs from the moment a vulnerability is known to the moment a patched release is published. The consumer's clock runs from that release to deployment. Writing one number for both hides who is late.
A template
The figures below are examples, not recommendations. Set yours from what your team can sustain.
| Severity | Owner acknowledges | Owner releases fix | Consumers deploy |
|---|---|---|---|
| Critical and exploited | Same business day | As fast as safely possible | Next deploy, escalate if blocked |
| High, reachable | 1 business day | Short, stated number of days | Stated number of days |
| High, not reachable | 2 business days | Next planned release | Next planned release |
| Medium and low | 5 business days | Batched | Batched |
Add one line: severity is set by the owner using exploitation evidence and reachability in the consumers, not only the base score.
Use reachability to calibrate
A vulnerable function that no consumer calls is a different problem from one that sits on a request path. Reachability analysis shows which consumers actually reach the vulnerable code. That lets an owner tell consumers who must hurry and who can wait for the next release.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the findings and note how many drop in priority once reachability is applied.
What a good service level includes
- Scope. Which libraries and which versions it covers.
- Contact route. A queue, not a person.
- Exceptions. Who can approve a delay and for how long.
- Reporting. Monthly counts of open fixes and overdue upgrades by team.
- Review. After each critical event, ask whether the numbers held.
Pitfalls
Do not copy service levels from a regulation or a large company without checking that you can meet them. A missed commitment erodes trust faster than a modest one honoured. Do not treat the service level as legal advice or as a contract term, unless your legal team has reviewed it.
Pair it with the support window from which versions should get security fixes.
Safeguard can help with the inventory side: its SBOM and dependency scanning shows which services pull in a given internal library, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Should owners and consumers share one deadline?
No. Give the owner a release deadline and consumers a separate upgrade deadline that starts when the fix ships.
Who approves a delay?
A named approver outside the requesting team, ideally the owner of the risk, with a written end date.
Last reviewed: 19 October 2026.
