Vulnerability remediation: why fixes stall and how a CISO frames the fix

The gap between finding and fixing

Aaron Momin, Chief Information Security Officer at Synechron, argues in a Synechron article that AI-assisted discovery now outpaces closure. The article's summary says frontier models found more than 10,000 critical flaws in production codebases, and 99% remain unpatched.

The article's central claim is that remediation takes weeks because of what surrounds the code change, not the code change itself. It says a fix can be identified, understood and written in hours.

The article also notes that a one-line fix and a complex one can both take weeks to reach production. It reads this as a sign that something other than engineering is setting the clock.

Four sources of delay

The article names four places where the delay builds up: ownership split between security, engineering, release and risk; engineering capacity committed before the finding arrived; hours lost to validating scanner output; and the confidence required to change a business-critical system safely.

The article gives the first question a leader should ask: what is preventing this fix from reaching production? It says the answers are usually organizational, and rarely the same twice.

Ownership and capacity

On ownership, the article says security typically identifies the issue, engineering owns the affected code, and a separate team controls its release. Risk gets involved when remediation is delayed or an exception is needed. By the time someone can make the change, the finding has crossed four teams, each with its own priorities and queue.

The article says this distribution is deliberate, but owning part of the process is not the same as owning the outcome. It adds that making one team faster achieves little if the work only reaches the next queue sooner.

On capacity, the article says a fix creates work that did not exist when the sprint was planned. Unless capacity has been set aside in advance, the fix competes with everything the team had already committed to.

Validation, context and confidence

The article says static analysis produces large volumes of false positive findings that are not reachable or exploitable, and someone must sort them before any fix begins. It says expanding scanning coverage adds findings to a process already constrained at validation, which lengthens the queue rather than shortening it.

Some flaws depend on understanding the application rather than the code. The article names broken access control, insecure direct object references and privilege escalation as the clearest examples. Fixing them safely requires an engineer to understand how the authorization model is supposed to behave, and the person who holds that context has likely moved on.

Even after the fix is made, the change moves through testing and release processes. For some systems the article says this means lengthy regression testing, formal change approval and a defined release window. It says these controls cannot be set aside in the name of speed, particularly for business-critical applications. The hard question is often not whether a vulnerability can be fixed, but whether the fix can be introduced safely.

How AI changes detection

A second Synechron article, by Momin and Bharadwaj D Jagannath, describes traditional detection as automated scanning, manual analysis by security experts, and comparison against databases of known vulnerabilities. It says prioritization is often based on severity scores such as those assigned by the Common Vulnerability Scoring System.

The authors say AI-powered tools can analyze vast amounts of data and code much faster than traditional methods, reducing false positives and giving more precise detection and scoring. They also say AI can evaluate vulnerabilities in the context of an organization's specific environment and risk profile.

The authors add a caution. As AI becomes embedded in digital infrastructure, they say, it also introduces new risks and vulnerabilities.

How the CISO frames the fix

The remediation article's framing is that discovery has been industrialized and closure has not moved with it, which puts the constraint somewhere other than in finding the problem.

Its answer is to look at what happens around the change. Momin says that using AI only to produce fixes faster would leave most of the delay untouched. The article poses three questions instead: how much engineering time goes to validation before useful remediation work can begin, how much application context can be recovered to inform the fix, and whether a team can establish a reliable picture of system behavior before a change and use it afterward to understand what the change did.

The article says there is no single bottleneck to remove. Remediation runs from confirming a real vulnerability to safely closing it, and the code change sits somewhere in the middle. Saving hours at one stage is worth little if the finding then waits weeks at the next.

The article closes by repeating its question: what is preventing this fix from reaching production? Its answer is that the cause will not always be code.