Report a vulnerability with no available fix as an open exposure with three attached items: a mitigation or compensating control, a named owner, and a review trigger such as a vendor release or a change in exploitation status. Do not mark it closed, and do not count it against remediation speed while no fix exists.
Why it needs its own category
Standard remediation metrics assume a fix exists. If a library has no patched version, the clock is not measuring your team, it is measuring the upstream project. Lumping these in with fixable items makes performance look worse than it is, and leaving them out hides risk.
NIST's guide to enterprise patch management describes patching as a routine preventive process of identifying, prioritising, acquiring, installing and verifying patches. When step three, acquiring, is impossible, you need another response, and your report should show which one you chose.
Split the backlog three ways
| Category | Definition | Clock |
|---|---|---|
| Fixable now | A patched version or workaround exists | SLA runs |
| Fix pending | Upstream has acknowledged, no release yet | Tracked separately |
| No fix expected | Project abandoned or end of life | Needs a replacement plan |
Responses when no patch exists
- Mitigate: configuration change, input filtering, network restriction, feature disabled.
- Remove: drop the dependency or the vulnerable feature.
- Replace: move to a maintained alternative.
- Accept: record the risk, with approver, expiry and compensating controls.
Each response should be written into the finding, so a reader sees what is being done and not only that nothing has been fixed.
Review triggers
- Upstream publishes a release.
- The vulnerability is added to the CISA KEV catalog.
- Exploit probability climbs.
- The component becomes reachable from new code.
- A planned replacement date arrives.
What to show leaders
Show the count of unfixed exposures, the oldest one, the response in place for each, and the planned exit date for the worst. Keep the metric separate from SLA compliance, with a short note explaining why.
Check for a fix again
Fixes sometimes appear without notice, in forks, backports or newer major versions. Re-check automatically on each scan rather than relying on someone reading an advisory feed.
Try it yourself
Open the demo and watch how it flags that a fix is available. Imagine the same list with none of those flags.
Click through it at your own pace, or open it full screen.
Safeguard supports this with SBOM and dependency scanning, reachability analysis and fix PRs (off by default), and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Should unfixed items count toward SLA breaches?
Track them separately. The SLA clock is not meaningful until a fix or workaround exists.
Can we just accept the risk?
Yes, with a record that names the approver, compensating controls and an expiry.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities catalog
Last reviewed: 19 October 2026.
