Many security teams can already list their vulnerabilities. Scanners for code, dependencies and cloud configuration are common and cheap to turn on. The harder question is how many of those findings turn into fixes that are merged and running in production, and how long that takes. The distance between a finding and a fix is the remediation gap, and it is where most security programs stall. This guide shows where fixes get stuck, five metrics that measure the gap, and what automated remediation can and cannot do about it.
Four stages, and where findings wait
A finding passes through four stages before it stops being a risk. Each has a different owner and a different way of stalling.
| Stage | Who usually owns it | Where it stalls |
|---|---|---|
| Detected | Security tooling | Rarely. This stage is mostly solved. |
| Validated and prioritized | Security team | Duplicates, false positives and unclear severity use up review time |
| Assigned and fixed | Engineering | The ticket lacks context, the owner is unclear, and the fix competes with roadmap work |
| Merged and deployed | Engineering and release process | Reviews wait, tests fail, or the change is held for a release window |
Most investment goes into the first row. Most of the delay sits in the last three.
Why backlogs grow even when scanning works
A scanner adds findings faster than a team can close them, and nothing in the tool slows it down. Three forces keep the backlog growing:
- Findings arrive faster than fixes. Turning on a new scanner can produce hundreds of results in a day, while fixing each one takes an engineer's attention.
- Severity labels do not match urgency. A high-severity finding in code that is never reachable can matter less than a medium one on a public endpoint. Sorting by label alone sends effort to the wrong place.
- Nobody is accountable for closing the loop. The security team can report on findings, and engineering owns the code. Without a named owner for the outcome, the item waits. See who owns security at a startup.
The hidden cost of handing findings from security to engineering
Every handoff has a price that does not appear in the scanner's dashboard. A developer receiving a ticket has to understand the finding, find the code, decide whether it is real, work out a fix that will not break anything, write a test and get a review. Each of those steps is context the original finding rarely supplies.
The cost compounds in three ways. Developers switch away from planned work, so the fix is never free. Tickets with weak context get questions, which adds a day of waiting each way. And after enough false positives, developers stop trusting the queue and treat it as noise, which is the point at which a real critical finding gets ignored with the rest.
Why the number of findings is a poor measure
"We found 4,000 vulnerabilities" says how loud the scanner is. It does not say whether the company is safer. A bigger number can mean a better scanner, a larger codebase, or a newly turned-on rule. A smaller number can mean a fixed backlog, or a scanner that stopped running.
Count what happens to findings after they are found. Measure outcomes, not detections.
Five metrics to track
| Metric | The question it answers | How to measure | Watch out for |
|---|---|---|---|
| Remediation time | How long does a finding take to be fixed? | Median and 90th percentile time from detection to merged fix, by severity | Averages hide the long tail. Report the slowest decile too. |
| Backlog age | How old is the risk we are carrying? | Age distribution of open critical and high findings | A flat count can hide a growing number of very old items. |
| Fix acceptance rate | Of the fixes proposed, how many are merged? | Merged fix pull requests divided by fix pull requests opened, over a stated period | Say what counts as accepted, and over what time. |
| Remediation effort | What does each fix cost in engineering time? | Hands-on minutes per fix, from first look to merge | Ask developers for estimates, or sample a few fixes. |
| Recurrence | Does the same kind of flaw keep returning? | Share of new findings in a weakness class already fixed once | A high rate points to a missing guardrail, not a one-off bug. |
Pick three to start. Remediation time and backlog age need data you already have. Fix acceptance rate needs a stated definition, as the next section shows.
What automated remediation changes
Automated remediation tools reduce the work in the "assigned and fixed" stage. Instead of opening a ticket and waiting, they open a pull request containing a proposed fix, so the developer reviews a change rather than researching a finding. That shortens remediation time and lowers effort, provided the fixes are good enough to merge.
That proviso is why fix acceptance rate matters most. A tool that opens many pull requests nobody merges has moved the backlog from a ticket queue to a pull request queue.
What our own numbers show, and what they do not
Orbis AppSec scans repositories, filters out false positives and opens pull requests with fixes. We looked at our own pull request history to see how often the fixes are accepted.
In a sample of our 992 most recent pull requests, taken in early October 2026, 639 were opened against repositories that we do not own. Of those, 219 were merged, which is 34.3%. An earlier sample of 937 such pull requests gave 31.6%. In both samples, "merged" means an outside maintainer chose to merge the change.
Read those figures carefully:
- It is a merge, not a verified deployment. A merged pull request shows a maintainer accepted the change. It does not show that the fix was tested, released or confirmed to remove the risk.
- It is a hard test. These are unsolicited pull requests to open-source projects whose maintainers did not ask for them and do not know us. A team receiving fixes for its own repositories is a different situation, and these figures do not predict that team's acceptance rate.
- Merge rate is a blunt signal. In the same data, about a third of rejected pull requests were closed within two hours, and about a quarter were closed without a comment. A rejection often says nothing about why.
- It covers only our own pull requests. It is not a benchmark of the industry.
We use this number to test and improve our fixes, not to claim an outcome for any customer. The useful lesson for a security leader is the method: measure acceptance on your own repositories, over a stated period, and keep merge and deployment as separate questions.
A quarter to close the gap
- Weeks 1 to 2: record remediation time and backlog age for critical and high findings. These are your baseline.
- Weeks 3 to 6: pick one source of findings and one team. Agree who owns the outcome and by when critical findings should be closed.
- Weeks 7 to 10: try automated remediation on a small set of repositories. Track fix acceptance rate with a written definition and a start and end date.
- Weeks 11 to 12: compare against the baseline and decide whether to expand. Report to the CEO in outcomes: older items closed, time to fix, effort saved.
Any tool should be evaluated against your own repositories before you commit.
Frequently asked questions
Does fixing faster mean taking more risk? Not if every change still goes through review and tests. Automated fixes should arrive as pull requests, not direct commits.
What if developers distrust automated fixes? Start with low-risk classes, such as dependency upgrades, and measure acceptance. Trust follows a record of fixes that were correct.
Is a merged pull request the same as a fixed vulnerability? No. Merged means the change was accepted. A fixed vulnerability means it was released and the risk is gone. Track both.
How is the gap different from alert fatigue? Alert fatigue is one cause. The gap also includes assignment, review and release delays that come after the alert.
This guide is general guidance. The figures above are from Orbis AppSec's own pull request data and describe that sample only.