Why do application security programmes struggle to prove improvement even when teams are shipping fixes?

Why This Matters for Security Teams

application security programmes often stall at the point where leaders need to answer a simple question: is the backlog shrinking in a meaningful way, or just being reshuffled? Counts of findings can go down while the underlying exposure stays flat if new issues are arriving at the same rate, or if old issues linger unresolved. That is why measurement has to move beyond volume and into flow, age, and closure quality. Current guidance in ISO/IEC 27002:2022 Information Security Controls supports more disciplined tracking, but security teams still need operational metrics that show whether remediation is actually keeping pace with discovery. NHIMG research on The State of Secrets in AppSec shows how easily confidence can outrun reality when organisations measure activity instead of outcome. In practice, many security teams encounter “improvement” only after a backlog review exposes that fixes are landing too slowly to offset fresh findings.

How It Works in Practice

The most useful AppSec reporting treats remediation as a pipeline, not a snapshot. Instead of asking only how many issues are open, teams track whether risk is closing faster than it is being created, and whether the oldest items are disappearing or simply surviving in a different report. That usually means combining vulnerability counts with age distribution, time-to-remediate, re-open rate, and risk class. A practical operating model typically includes:

• Open risk by severity, application, and business criticality, so leaders can see where exposure concentrates.

• Closed risk with evidence of fix quality, because “closed” findings that reopen do not represent durable progress.

• Median and 90th percentile time-to-remediate, since averages can hide long-tail failures.

• Discovery-to-closure flow, which shows whether engineering throughput is outpacing intake.

This approach aligns with the broader security-governance logic reflected in ISO/IEC 27002:2022 Information Security Controls, which emphasises consistent control operation rather than one-off activity. It also fits the measurement discipline discussed in The State of Non-Human Identity Security, where visibility gaps make it hard to distinguish exposure reduction from administrative cleanup. For application security, the same principle applies: a team can ship fixes every week and still fail to reduce organisational risk if those fixes are concentrated in low-value systems, duplicated findings, or stale tickets that were never truly verified. These controls tend to break down when findings are distributed across many repositories and issue trackers because duplicate suppression, ownership mapping, and validation status are rarely normalised end to end.

Common Variations and Edge Cases

Tighter measurement often increases reporting overhead, requiring organisations to balance visibility against the cost of normalising data across tools and teams. That tradeoff becomes sharper in fast-moving environments, where product releases, ephemeral infrastructure, and parallel remediation work can make the same metric look healthy in one system and unhealthy in another. Best practice is evolving here: there is no universal standard for which AppSec metric set best proves improvement, so teams should be explicit about what each metric measures and what it does not. Two edge cases matter most. First, a programme may show falling open counts because intake has slowed, not because remediation improved. Second, aggressive closure can hide weak verification, especially when fixes are marked done without retesting or when ownership changes leave tickets stranded. NHIMG’s The State of Secrets in AppSec illustrates how confidence can remain high even when operational reality is slower than expected, and the same pattern appears in broader application risk programs. The right response is to compare closed risk against new risk over time, then slice the results by application, team, and severity class. That is how leaders distinguish sustained progress from temporary housekeeping. In practice, the weakest reporting usually appears when board-ready metrics are built from defect counts alone instead of from the full remediation lifecycle.

Related resources from NHI Mgmt Group

• Why do application security programs struggle to prove value to leadership even when testing is happening?
• Why do small security teams struggle with cloud detections even when they have modern tools?
• How do security teams stop the same application vulnerability from shipping twice?
• Why do CTEM programmes fail even when teams buy more security tools?