The resolution gap is the distance between identifying a security issue and actually eliminating the risk it creates. In AppSec, it appears when scanners produce findings faster than teams can triage, fix, test, and deploy them. The gap is operational, not theoretical.
Expanded Definition
The resolution gap describes the operational delay between discovery and risk removal. In application security, that often means a vulnerability is identified by a scanner, ticket, or review, yet remains exploitable because the underlying code, configuration, dependency, or deployment path has not been corrected. The concept is broader than simple remediation time. It also covers the chain of work needed to prove a fix is safe, obtain approval where required, and push the change into production.
Within security operations, the term is useful because it highlights a measurable weakness in the security lifecycle, not just a backlog problem. A team can have strong detection coverage and still carry meaningful exposure if triage, ownership, testing, and release coordination are slow or fragmented. That is why the gap is often discussed alongside NIST Cybersecurity Framework 2.0, which emphasises coordinated governance and risk management across the full lifecycle.
Definitions vary slightly across vendors and teams, especially when the discussion moves from application flaws to identities, cloud misconfigurations, or exposed secrets. The common thread is always the same: detection has happened, but the risk still exists because the fix has not been completed and validated. The most common misapplication is treating the resolution gap as a pure scanner metric, which occurs when organisations measure findings volume without measuring time to effective risk removal.
Examples and Use Cases
Implementing resolution-gap reduction rigorously often introduces workflow constraints, requiring organisations to weigh faster risk elimination against change-control overhead, testing effort, and service stability.
- A SAST tool flags a high-severity flaw in a customer-facing API, but the fix waits for the next release train, leaving the issue open for weeks.
- A cloud security platform detects a public storage bucket, yet remediation stalls because the bucket is owned by a different team and no clear approval path exists.
- An exposed secret is rotated quickly, but dependent services are not updated in time, so the exposure is only partially resolved and the gap remains.
- A zero-day in a third-party library is triaged immediately, but the patch cannot be deployed until regression testing completes across multiple environments.
- Teams using OWASP guidance may prioritise web application risks well, yet still accumulate a resolution gap if fixes are not tracked through to verified release.
These cases show that the resolution gap is not limited to code defects. It also appears wherever ownership is unclear, risk acceptance is informal, or remediation depends on cross-team coordination. The practical question is not only “was the issue found?” but “was it actually removed from the attack path?”
Why It Matters for Security Teams
The resolution gap matters because attackers do not care that an issue has been logged if the exploitable condition is still present. A large gap turns detection into a false sense of control: dashboards look active, but exposure persists. For security leaders, this means prioritisation must extend beyond severity scoring to include fixability, dependency chains, and proof of effective remediation. For engineering teams, it means building ownership and deployment pathways that can move from finding to verified closure without unnecessary delay.
This is especially relevant in identity and NHI environments, where stale credentials, over-privileged service accounts, and misconfigured secrets can remain live long after they are detected. In that context, the gap can become a direct access problem, not just a defect-management issue. Frameworks such as NIST Cybersecurity Framework 2.0 are useful because they encourage coordinated governance, but teams still need operational discipline to close the loop.
Organisations typically encounter the resolution gap only after a breach, audit failure, or repeated vulnerability aging report, at which point closing it becomes operationally unavoidable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MI | CSF addresses timely response and mitigation after issues are found. |
| NIST SP 800-53 Rev 5 | RA-5 | Continuous vulnerability scanning must lead to timely remediation. |
| ISO/IEC 27001:2022 | A.8.8 | Technical vulnerability management requires action after identification. |
| OWASP Non-Human Identity Top 10 | NHI exposure often persists when secrets and service identities are found but not rotated. | |
| NIST Zero Trust (SP 800-207) | Zero trust reduces impact when a discovered weakness cannot be fixed immediately. |
Assume exposure may persist and enforce stronger verification until remediation is complete.
