To fix vulnerabilities faster, shrink the queue before you work it. Rank by exploitation and exposure, drop findings whose vulnerable code is never called, automate pull requests for available fixes, give every finding an owner, and remove exposure where you cannot patch. Speed comes from fewer, clearer tickets.
Key takeaways
- Most of the delay is triage and ownership, not the code change.
- Known exploited vulnerabilities come first. CISA says to treat them as a top priority.
- Reachability analysis can show whether your code calls the vulnerable function.
- Removing an asset from the internet is a valid fix and can extend its deadline under CISA's BOD 26-04.
Why are vulnerabilities slow to fix?
Usually because nobody knows who owns the finding, the list is too long to rank, or the update is risky. Fix those three and the work moves. The code change is often small.
What are the seven changes?
- Rank by exploitation. Put KEV listed and high EPSS items first. CISA's earlier directive noted that fewer than 4% of known vulnerabilities have been used in real attacks, so most of the list can wait.
- Check reachability. If your code never calls the vulnerable function, the finding can drop in priority. Safeguard offers reachability analysis for this.
- Automate fix pull requests. Dependabot security updates open a pull request to the lowest fixed version and link it to the alert. Merging closes the alert.
- Group updates. Dependabot can combine security updates per ecosystem to reduce pull request volume.
- Auto dismiss low risk alerts. GitHub suggests auto triage rules for this, and auto dismissed alerts send no notifications.
- Assign owners at creation. Tag each asset with an owner so tickets route themselves.
- Reduce exposure. Close ports, remove public access or retire the asset when patching will take time.
How do I know a fix is really available?
Check the advisory for a fixed version and see whether your package manager can reach it. Dependabot reports an error on the alert when it cannot upgrade without breaking the dependency graph, and for non npm ecosystems it cannot update a transitive dependency that needs a parent update. Those cases need a manual change.
What should I measure?
Track time from detection to merged fix, by risk tier. Look at the oldest exploited item first. A shrinking median with a growing tail means you are fixing easy items and avoiding hard ones.
Try it yourself
Take your current backlog and mark each item as exploited, reachable, or fixable by upgrade. Count how many are all three. That list is your fast lane.
Click through it at your own pace, or open it full screen.
Frequently asked questions
What is the fastest way to reduce vulnerability backlog?
Rank by exploitation, drop unreachable findings, and merge automated fix pull requests for the rest.
Does reachability analysis remove the need to patch?
No. It helps you order the work. An unreachable flaw can become reachable when code changes, so schedule it rather than ignore it.
Should developers or security fix vulnerabilities?
The team that owns the code or system should fix it. Security sets priorities and checks the result.
Is it risky to auto merge dependency updates?
It can be. Require passing tests, and consider keeping manual review for major version jumps.
Sources
- CISA BOD 22-01 (revoked) and FAQ: https://www.cisa.gov/news-events/directives/bod-22-01-reducing-significant-risk-known-exploited-vulnerabilities
- CISA BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- GitHub, about Dependabot security updates: https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates
- GitHub, about Dependabot alerts: https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
Last reviewed: 19 October 2026.
