The clearest signals are a growing backlog, low merge rates for automated fixes, and a programme that still talks mostly about vulnerabilities found rather than vulnerabilities removed. If triage consumes more effort than repair, the organisation has not built a real remediation path.
What the resolution gap looks like when appsec is stuck in it
The resolution gap shows up when the programme can identify issues faster than it can close them. You will usually see a widening queue of findings, a low conversion rate from automated or assisted fixes into merged code, and a reporting culture that still values “found” more than “removed.” At that point, the programme is producing visibility without durable remediation.
A healthy programme does not just discover defects, it turns them into code change, validation, and release decisions. When that path is missing, triage becomes the dominant workload and the organisation starts optimising for review activity instead of risk reduction. The practical test is whether the team can consistently move from detection to repair without manual bottlenecks swallowing the benefit of automation.
One useful signal is the relationship between backlog age and fix throughput. If new findings keep arriving but older items do not age out, the programme is not absorbing defects at operational speed. Another signal is that engineering teams only engage when a vulnerability is escalated, rather than when remediation is already part of the normal development workflow.
Why the gap persists even in mature programmes
The gap is rarely caused by a single weak tool. It usually comes from a mismatch between detection capacity, ownership, and delivery process. Appsec teams may be able to classify issues accurately, but if developers do not have clear fix patterns, if product priorities do not reserve capacity, or if acceptance criteria stop at “ticket created,” the work accumulates instead of disappearing.
Another common pattern is a false sense of progress built on metrics that track analysis volume rather than closure quality. A programme can look busy while still leaving the same classes of defects unresolved release after release. That is especially common when remediation guidance is generic, ownership is ambiguous, or vulnerable components remain embedded in features that are considered too risky to change late in the cycle.
Tooling can also widen the gap when it creates more findings than the organisation can realistically act on. The issue is not volume alone, it is whether findings are normalised into engineering work. If the programme lacks guardrails such as prioritised queues, repeatable fix patterns, and clear ownership boundaries, the back half of the process will always lag the front half.
What practitioners should measure to confirm the programme is closing the loop
Track the indicators that show motion from detection to disposal, not just detection to triage. The most useful signals are ageing backlog, merge rate for approved fixes, time from finding to code change, and the share of recurring findings in the same component or service. If remediation is effective, those numbers should improve together, not trade off against one another.
It also helps to separate defect classes. Some issues are best handled in the codebase, while others require dependency updates, configuration changes, or compensating controls. If every issue flows through the same manual review path, the programme will slow down even when the actual fix is straightforward. A good programme makes the next action obvious enough that triage does not become a second security project.
For appsec leaders, the most honest dashboard is the one that shows whether the organisation is reducing exposure or merely accumulating evidence. When the same vulnerabilities keep reappearing in similar forms, the problem is no longer detection quality, it is remediation capacity and engineering integration.
Risk and Threat Considerations
When an application security programme cannot convert findings into fixes, exposure compounds quietly. Attackers do not care whether a weakness was identified; they care whether it is still reachable, exploitable, and left in production long enough to use.
Failure mechanism: Findings pile up, ownership stays ambiguous, and repair work is deferred until the vulnerable code becomes normalised. That creates a durable attack surface, especially when the same defect class is repeatedly rediscovered without a structured path to elimination.
Impact: The organisation keeps paying the cost of triage while its real risk remains in place. Over time, that can increase breach likelihood, complicate audit and governance discussions, and erode trust in the appsec programme because the team is measuring discovery more effectively than reduction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Appsec resolution depends on fixing code and design weaknesses, not just finding them. |
| Recommendation — Build remediation into secure design and coding practices so identified issues are removed, not merely tracked. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The topic is about closing application vulnerabilities through an operational security program. |
| Recommendation — Use application security practices that drive findings into verified remediation workflows. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The resolution gap is fundamentally a failure to remediate discovered flaws at pace. |
| Recommendation — Prioritise and track flaw remediation until identified weaknesses are corrected or formally mitigated. | ||
Practitioner Guidance
What to prioritise: Focus first on the bottleneck between finding an issue and getting a change merged. If that handoff is weak, improving scan coverage will only enlarge the queue.
What to verify: Check whether each high-confidence finding has an owner, a target fix path, and a closure criterion that engineering can act on without waiting for a second security review loop.
Common mistake: Treating triage volume as a success signal. High triage activity can be a symptom of weak remediation design, not strong control coverage.
Decision rule: If a finding cannot be repaired within the normal delivery process, classify that as a programme design issue, not just an exception request.
Practitioner takeaway: A programme is stuck in the resolution gap when security can name the problem but engineering cannot routinely retire it, and the only durable fix is to make remediation part of delivery rather than a separate after-the-fact queue.
Related resources from NHI Mgmt Group
- What are the signs that an application security programme is still fragmented despite increased automation?
- What are the signs that an application security programme is not gaining developer traction?
- What are the signs that an application security programme is being slowed down by tool sprawl rather than improved by more scanning?
- What are the signs that a security programme is stuck in the Big Disconnect?