Should organisations measure AppSec success by fewer findings or less exploitable risk?

Why fewer findings can be the wrong success metric

Finding counts are useful for backlog management, but they are a weak proxy for security outcome. A programme can reduce total findings by suppressing low-value tests, narrowing scan coverage, or leaving a small number of high-impact issues untouched. AppSec success is better measured by whether the organisation is removing reachable and exploitable weaknesses that matter in production.

That distinction matters because a single authenticated path, a reachable injection point, or an exposed secret can be far more material than dozens of low-risk issues. Mature teams therefore track the quality of remediation, not just the quantity of findings: what was actually exploitable, what was fixed, and what keeps coming back.

What less exploitable risk looks like in practice

Less exploitable risk means the programme is shrinking the attack surface that an adversary or an accidental failure could really use. That usually shows up as fewer internet-reachable issues, fewer weaknesses on production paths, fewer high-severity findings that remain untriaged, and fewer instances where the same control failure reappears after a release or refactor.

It also means prioritising by exploitability, not volume. A small set of validated issues with a clear path to production data, privileged functions, or externally reachable APIs is a more meaningful indicator than a large backlog of issues that cannot be reached or chained into impact. OWASP ASVS is useful here because it frames verification around concrete security properties such as authentication, authorization, and access control rather than raw issue counts.

For teams building the programme itself, security maturity should be visible in how well controls are embedded into delivery, not just in the output of a scanner. OWASP SAMM helps teams assess whether the process is actually improving design, implementation, verification, and response across the software lifecycle.

How to measure whether the risk is really dropping

The best metrics distinguish between discovery and danger. Reachability, exploitability, and remediation speed are more decision-useful than gross finding totals because they reflect whether the remaining exposure is still viable in production. A good dashboard should answer: which validated issues can be hit, which ones are blocked by compensating controls, and which ones have been fixed before they can be reused or rediscovered.

Practitioners should also watch for repeat failure patterns. If the same authentication mistake, access-control gap, or insecure configuration keeps returning, the programme has not reduced risk even if the annual finding count fell. That is why control failure recurrence is a stronger signal than a one-time reduction in volume. OWASP Cheat Sheet Series is a practical reference when teams need implementation guidance for the recurring issues that often drive exploitable exposure.

Exploitability-based prioritisation is also easier to defend when it is tied to external evidence of real-world exploitation. FIRST EPSS helps teams estimate how likely a vulnerability is to be exploited, while CISA Known Exploited Vulnerabilities Catalog highlights issues that are already being used in the wild. Those signals are much closer to risk than a simple count.

Risk and Threat Considerations

A low finding count can create false confidence when the remaining issues are the ones with real attack paths. The main risk is not volume, it is concentration: a few reachable flaws, exposed secrets, or over-privileged paths can deliver the bulk of practical exposure even after a successful reduction in overall findings.

Failure mechanism: Teams optimise for scan results or closure rate, but the underlying control weaknesses remain in production, are reachable from real user flows, or can be chained into privilege or data access.

Impact: The programme appears healthier than it is, exploitable risk persists, and prioritisation shifts away from the issues most likely to cause actual compromise or business impact.

Practitioner Guidance

What to measure: Use a small set of outcome metrics that reflect exposure, not noise, such as reachable validated findings, median time to remediate validated issues, and recurrence of the same control failure after release.

Decision rule: If a finding is not reachable in production, treat it as lower priority; if it is reachable, exploitable, or tied to sensitive paths, prioritise it ahead of low-risk backlog reduction even when the total count looks worse.

Practitioner takeaway: A better AppSec programme makes the attack surface harder to use, not merely harder to count.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• When does automated remediation create less risk than manual workflows for exploitable findings?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?