Promise what you control: how fast you assess a reported vulnerability, how you prioritise, how you notify customers, and a target fix window by severity that you can measure. Do not promise that every open source vulnerability will be fixed by a date, because upstream release dates are not yours to set.
Why patch promises break
Most broken commitments fail for the same reason. The promise was written around the fix, and the fix depended on a library maintainer, a vendor, or a customer's own upgrade schedule.
Split every commitment into the part you own and the part you do not.
| You own | You do not own |
|---|---|
| Time to acknowledge and assess a report | When an upstream project ships a fix |
| Time to ship a release that includes a fix once one exists | When a customer installs your update |
| Notifying affected customers | Whether a vendor accepts your report |
| A mitigation or workaround guidance | Third party disclosure timing |
A commitment you can usually keep
Write promises in terms of your own steps:
- We acknowledge security reports within a stated number of business days.
- We assess whether our product is affected and tell the reporter or customer.
- We target a fix release within a stated window by severity, measured from the point a fix is available.
- If no fix exists, we publish a mitigation and a status.
- We say how customers are notified.
Pick the numbers with engineering, based on how long your last ten fixes took, not on what sounds competitive. Then measure against them. A promise you cannot report on is a liability.
Use exploitation evidence, not only severity scores
A fixed window per severity label is easy to state but crude. FIRST describes the Exploit Prediction Scoring System as an estimate of the probability a published CVE will be exploited in the wild in the next 30 days, and recommends combining it with other inputs. CISA says organizations should use its Known Exploited Vulnerabilities catalog as an input to prioritization. A commitment can reasonably say that vulnerabilities with confirmed exploitation are handled on a faster track than the standard windows.
Say what happens when you miss
State how you will tell customers if you are going to miss a target and what interim steps you will offer. Customers tolerate a miss with an honest status far better than silence.
Check the wording with legal and security
Contract language is binding. Have legal review any number you put in writing, and have security confirm that the process behind it exists. Do not describe an audit, attestation, or certification as complete unless it is.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings move from detection to a tracked fix. Those timestamps are the data your promise is measured with.
Quick check
Should a customer contract promise a fix date for open source vulnerabilities?
Prefer a window measured from when a fix becomes available, plus a mitigation path when none exists.
Where do we get realistic numbers?
From the actual time to remediate on your recent fixes, tracked per severity.
Safeguard's policies and gates and its vulnerability tracking can record those timings, and you can try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
