They should measure less exploitable risk. A lower finding count can hide unresolved exposure if the remaining issues are the ones that actually run in production. A better test is whether the programme can show fewer reachable issues, faster remediation of validated findings, and less repeat introduction of the same control failures.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, OWASP SAMM and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | Auth flaws often determine whether a finding is exploitable in production. |
| V8 — Authorization | Authorization weaknesses turn a low-volume issue set into material access risk. | |
| Recommendation — Verify authentication controls to reduce reachable attack paths rather than chase raw finding counts. Validate authorization paths to remove exploitable access instead of measuring volume alone. | ||
| OWASP SAMM | Measurement — Measurement | AppSec success here depends on measuring outcomes, remediation speed, and recurrence. |
| Verification — Verification | Verified exploitability matters more than untriaged scan output for this question. | |
| Recommendation — Track outcome-based metrics that show whether control failures are actually being reduced. Assess verified issues and production reachability before prioritising remediation work. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Exploitability-based prioritisation aligns with continuous vulnerability management. |
| Recommendation — Prioritise vulnerabilities by reachability and exposure, not by raw inventory size. | ||
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?