A fix available but not applied metric counts open vulnerabilities where a patched version already exists and you have not deployed it. It matters because this is risk you can remove with known effort, and every day it stays open is a choice, not a limitation of the market.
Why separate it from the rest
Open findings are a mix of two kinds. Some have a published fix. Others do not, and need a workaround, a replacement, or a risk decision. Blending them makes the backlog look like one problem.
The first group is a delivery question: who applies the update, and when. The second group is a risk question: what do we do while we wait. Different owners, different conversations.
How to measure it
- For each open finding, record whether a fixed version exists, and the version.
- Compute the count and age of findings where a fix exists.
- Record how long the fix has been available. Use the date the fixed version was released when your data has it.
- Report count, median age since fix release, and the oldest.
A short table works for leaders.
| Group | What it shows |
|---|---|
| Fix available, not applied | Delivery backlog |
| No fix yet | Risk backlog needing workarounds |
| Fix requires a major upgrade | Planning backlog |
The third row is worth splitting. A patch release and a breaking major version are not the same effort, and lumping them makes the first group look harder than it is.
Set a target the team can hit
Pick a target by exposure and severity, for example a short window for internet-facing, high severity findings and a longer one for internal, low severity ones. Write the target down in policy. NIST's patch management guide frames patching as preventive maintenance, a normal cost of running technology, which is a helpful way to explain recurring updates to leaders.
Why fixes sit unapplied
- Nobody owns the component.
- The update breaks tests, and no one has time to fix them.
- The update bundles unrelated changes.
- The service is rarely deployed.
Each cause has a different remedy. Ownership gaps need a named owner. Fragile tests need investment. Rare deploys need a release cadence. Report the top cause next to the count, so the ask is specific.
What to say to an executive
"We have a number of findings with fixes available that we have not applied. The oldest has been fixable for a stated number of days. The blocker is test coverage in two services. We ask for time in the next two sprints." That is a decision the executive can make.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice which findings show a fixed version, since those make up this metric.
Quick check
Should this metric include findings that need a major upgrade?
Count them, but show them as their own group. They need planning, not a quick patch.
What about a fix that is only a workaround?
Track it as mitigated, not fixed, and keep the finding open until the real update lands.
Sources
Last reviewed: 19 October 2026.
