Set the clock from three inputs: severity, whether a fix exists, and whether the flaw is known to be exploited. A single severity-only deadline either buries teams in unfixable items or lets exploited flaws wait. Start with short deadlines for exploited and fixable findings, and a review date, not a deadline, for findings with no fix.
Why severity alone misleads
A critical finding with no available fix cannot be closed by any amount of effort. If your SLA says "critical in seven days", the team will miss it, learn to ignore the SLA, and miss the next one that was fixable. A medium finding in a library that is on a list of exploited vulnerabilities may deserve faster action than a high one that nobody exploits.
The CISA Known Exploited Vulnerabilities Catalog lists flaws with a date added for each entry. Checking your images against a list like that is a cheap way to find the findings that matter most.
An example table
These numbers are illustrations. Tune them to your capacity, contracts and risk.
| Finding | Exploited | Fix available | Example target |
|---|---|---|---|
| Critical or high | Yes | Yes | Days |
| Critical or high | Yes | No | Mitigate now, review daily |
| Critical or high | No | Yes | Two to four weeks |
| Critical or high | No | No | Review monthly with expiry |
| Medium | No | Yes | Next scheduled rebuild |
| Low | No | Any | Backlog |
For the findings with no fix, you act through mitigation rather than patching: remove the package, restrict access, or accept the risk with a dated owner. See what to do when an image vulnerability has no fix.
Count the clock correctly
Define when it starts. Three common choices are the date of publication, the date a fix became available, and the date your scanner first reported it. Fix availability is the fairest for the team, because before that moment they could not act. Publication date is the fairest for customers asking how quickly you reacted. Pick one and say which.
Also define when it stops. "Fixed" should mean the patched image is running in production, not that the pull request merged.
Reachability reduces the pile
Many container findings sit in code that your application never calls. Reachability analysis separates those from ones the application can actually hit, which lets you rank findings you cannot yet fix. See running vs registry vulnerabilities and priority. A reachable flaw in a deployed image gets the short clock. An unreachable one in an unused image can wait for the next rebuild, with the reason recorded.
Report it
Track three numbers: share of findings closed within SLA, median time to fix once a fix existed, and number of open exceptions past expiry. Review them monthly with the owners from who owns base image vulnerabilities.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how the demo separates findings with a fix available now from the rest.
Where Safeguard fits
Safeguard offers reachability analysis and fix pull requests, which are off by default with every category on Manual, plus policies and gates. A free scan will show which findings have fixes.
Quick check
Should the SLA start at publication or at fix availability?
Either works if you state it. Fix availability is fairer to engineers, publication date is easier to explain to customers. Pick one and be consistent.
What do we do with no-fix findings?
Mitigate, or accept with an owner and expiry date, and review when upstream ships a patch.
Sources
Last reviewed: 19 October 2026.
