Why do critical vulnerabilities remain open for so long in modern appsec programmes?

Why This Matters for Security Teams

Critical vulnerabilities do not linger because teams fail to detect them. They linger because modern applications are tightly coupled, release cycles are fast, and remediation can trigger outages in load-bearing services. That gap between finding and fixing is where risk accumulates. NIST’s NIST Cybersecurity Framework 2.0 treats remediation as part of risk management, not a separate downstream task, which is the right lens for appsec programmes that keep inheriting technical debt.

The problem is often worse when the vulnerable component is a secrets path or credentialed service. NHIMG research on The State of Secrets in AppSec shows an average of 27 days to remediate a leaked secret, even as many organisations remain highly confident in their controls. That pattern is familiar across appsec: visibility arrives faster than operational readiness, and the backlog grows when ownership, dependencies, and rollback options are unclear. In practice, many security teams encounter repeated delay only after a production blast radius has already forced the fix to wait.

How It Works in Practice

Long-lived critical vulnerabilities are usually a coordination problem disguised as a technical one. A scanner may flag a serious flaw immediately, but remediation depends on whether the affected service is still maintained, whether the vulnerable code sits in a shared library, and whether the team has a safe deployment path. If any of those answers are missing, the issue gets deferred even when the severity score is high.

Effective programmes reduce this friction by turning findings into decision-ready work items. That means linking each vulnerability to the service owner, the exact dependency chain, runtime exposure, compensating controls, and a rollback plan before asking for a fix date. The issue then becomes a managed change, not just a ticket.

• Map the vulnerable component to the owning team and production path before prioritising.
• Record whether the flaw is in first-party code, a transitive dependency, or a shared service.
• Require a rollback or feature-flag plan for high-risk fixes.
• Use compensating controls, such as segmentation or temporary deny rules, when patching is delayed.
• Track exceptions with expiry dates so deferrals do not become permanent.

For broader guidance on risk-based response, current guidance from the NIST Cybersecurity Framework 2.0 aligns well with prioritising remediation based on business impact rather than severity alone. NHIMG’s DeepSeek breach research also reinforces how quickly exposure can compound when sensitive assets are left reachable in production-like environments. These controls tend to break down when ownership is split across platform, application, and vendor teams because no single group can safely authorise the change.

Common Variations and Edge Cases

Tighter remediation governance often increases operational overhead, requiring organisations to balance faster patching against release stability and service availability. That tradeoff is real, especially for legacy systems, regulated workloads, and shared platform components where a single fix can affect many downstream services.

Best practice is evolving for environments that rely on microservices, transitive open-source dependencies, or CI/CD pipelines with frequent release trains. In those settings, static SLAs for all critical findings are usually too blunt. A vulnerability in an internet-facing API with an exploit path deserves a different response from the same CVE inside an isolated internal service. The better model is context-aware prioritisation: exploitability, exposure, asset criticality, and available mitigations should drive the order of work.

There is also a real exception for dependencies that cannot be upgraded quickly because the vendor has not released a compatible patch. In those cases, teams should document the exception, apply compensating controls, and set a review date rather than leaving the issue open indefinitely. NHIMG’s State of Secrets in AppSec data is useful here because it shows how confidence and actual remediation speed often diverge. The practical lesson is simple: unresolved vulnerabilities persist when remediation is treated as a binary fix-or-ignore decision instead of a managed risk process.

Related resources from NHI Mgmt Group

• Who is accountable for certificate and key lifecycle failures in modern identity programmes?
• Why do non-human identities create audit risk in modern environments?
• Why do leaked secrets remain such a persistent NHI risk?
• Why is NHI governance critical in the age of AI attacks?