Give a tiered, risk-based answer: faster for issues that are exploitable in your product, slower for those that are not reachable, with an exception path that is recorded. A single number such as "24 hours for everything" is hard to keep and easy to disprove.
What the customer is really asking
They want assurance that known flaws in open source parts of your product do not sit unfixed for months. NIST SP 800-218 asks producers to analyze each vulnerability, plan and implement risk responses, and monitor for new advisories in third-party components (RV.1.1, RV.2.1 and RV.2.2). Note the word risk. The framework does not ask for identical timing on every finding.
Build the answer from four inputs
| Input | Question it settles |
|---|---|
| Severity | How bad is the flaw if abused? |
| Exploitation signal | Is it being used in the wild? FIRST's EPSS gives a daily probability of exploitation in the next 30 days. |
| Exposure | Does the vulnerable code run in our product, and is it reachable? |
| Fix availability | Is a patched version available and compatible? |
Combining them gives you tiers you can defend.
Example tier wording
Vulnerabilities in open source components are triaged on arrival. Issues that are exploitable in our product and actively exploited are treated as urgent and addressed first. Others are scheduled by severity and exposure. Where a fix is not available or not safe to apply, we record a mitigation and a review date.
Add your actual targets if the logs support them. Pull the last two quarters of data before writing a number.
Where honest answers go wrong
- One promise for all severities. Missed on the first awkward case.
- Measuring from patch release, not from advisory. Customers measure from disclosure.
- Ignoring transitive dependencies. The fix may need an upstream release first.
- No exception record. "We accepted it" needs a name and a date.
Evidence to offer
A ticket sample with dates, a redacted remediation report and the written triage rule. A customer who sees the process usually stops asking for the number.
For more on measuring this, see benchmarking mean time to remediate.
Collecting the data
Pull the actual history before you write anything. For the last two quarters, list findings above your urgent threshold, the date each advisory was published, the date you triaged it and the date it was fixed or mitigated. The medians and the slowest cases tell you what you can truthfully say. If the slowest cases are embarrassing, say you are working on them and describe the change.
Try it yourself
Click through it at your own pace, or open it full screen.
Walk a finding from detection to closure and watch where severity, exposure and fix status change its priority.
Safeguard offers reachability analysis and autonomous remediation with fix PRs. Fix PRs are off by default and every category starts on Manual, so a person approves changes.
Quick check
Should the SLA be in the contract?
Only if you can measure and meet it. Otherwise point to the policy and offer reporting.
What if the upstream project has no fix?
Record the risk, apply a mitigation if one exists, set a review date and tell the customer if they are affected.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1
- FIRST, Exploit Prediction Scoring System (EPSS)
Last reviewed: 19 October 2026.
