Security vulnerabilities were once treated as occasional risks—important, but manageable. That world no longer exists. Today, vulnerability management has become an overwhelming daily operational burden, with over 130 new CVEs disclosed every single day in 2025. This relentless volume quietly drains engineering resources, with recent data showing that developers now spend up to 19% of their weekly hours on security-related tasks, often at the direct expense of innovation.
Anyone who regularly tracks public vulnerability disclosures on platforms like CVE Details can see the scale of the problem firsthand. New vulnerabilities are reported continuously, across languages, frameworks, and libraries that modern applications depend on every day.
The issue is no longer awareness. The issue is capacity.
While detection speed has reached a pinnacle—with nearly 50% of incidents identified within 24 hours—remediation has not kept pace. With organizations still remediating only about 16% of their vulnerabilities each month, the gap between discovery and fix is where modern security programs are now getting stuck.
If you want to explore this challenge in more detail—and see how AI can help close the gap between detection and remediation—watch our webinar: Transform Vulnerability Management with AI
Vulnerabilities are no longer an edge case
One of the clearest trends in vulnerability management is that developers are spending more time than ever fixing vulnerabilities. Over the last year alone, vulnerabilities in open-source libraries have increased by almost 20%.
Modern applications are assembled from third-party components—frameworks, libraries, and dependencies maintained outside the organization. Each dependency introduces inherited risk, and each disclosed CVE eventually becomes an engineering responsibility.
What was once periodic security work has become continuous engineering work.
Where engineering time actually goes
When vulnerability remediation effort is categorized and mapped to engineering time, a clear pattern emerges.
Roughly 75% of total remediation effort sits with application developers. Of that effort:
- Around 15% is spent fixing application-level vulnerabilities such as SQL injection and cross-site scripting.
- Approximately 60% is spent upgrading libraries.
Library remediation is typically version-based. A vulnerability appears in one version of a dependency and is resolved in a newer version. Engineers are required to upgrade from the affected version to a fixed one—for example, from version 2.4 to 2.5. In many cases, a single upgrade resolves multiple CVEs at once.
From a security standpoint, this is efficient. From an engineering standpoint, it represents the largest share of time spent on vulnerability remediation.
The real cost of manual remediation
Several real-world projects illustrate how vulnerability remediation expands far beyond its initial scope.
In one case, a misconfigured security group in a cloud environment led to data exposure. Although the data was synthetic and the environment non-production, the incident triggered broader hardening work across environments.
In another, unresolved high and critical CVEs violated agreed SLAs, putting customer renewals at risk.
In a third case, non-critical CVEs were deprioritized for too long. Over time, the backlog grew to nearly 2,000 vulnerabilities. Eventually, a prospect refused to move forward unless the CVE count was reduced. What had been considered low priority became a business blocker.
The remediation timelines varied—from weeks to months to well over a year. Across all scenarios, the dominant effort was not in writing new security logic, but in upgrading and stabilizing dependencies.
Why traditional vulnerability tools fall short
Most organizations already run security scanners. These tools identify vulnerable libraries, list CVEs, assign severity scores, and suggest fixed versions.
The problem is not lack of information. The problem is lack of direction.
Traditional tools:
- Generate large volumes of alerts
- Present multiple upgrade options without guidance
- Offer no prioritization across dependencies
- Do not account for code impact or effort
- Leave teams to figure out execution on their own
As a result, developers are overwhelmed rather than enabled. Engineers spend time researching fixes, experimenting with upgrades, resolving failures, and repeating work already done elsewhere in the organization.
Detection alone does not reduce risk. It often increases noise.
Looking to build AI-powered remediation and automation workflows? Explore our AI development services.
The KPI trap: Why backlogs keep growing
Engineering leaders typically track metrics such as:
- Mean Time to Remediate (MTTR) for critical CVEs
- The number of aging CVEs older than a defined threshold
Most organizations focus heavily on critical CVEs—and rightly so. But non-critical CVEs cannot be ignored indefinitely. When they remain unresolved for months, the attack surface grows, and future upgrades become harder.
Incremental upgrades are manageable. Large jumps across multiple versions are not.
Over time, delayed remediation increases both technical complexity and business risk. Critical and non-critical CVEs alike begin to impact renewals, sales cycles, and customer confidence.
The mandate becomes unavoidable: reduce the engineering effort required to stay within acceptable risk thresholds.
Why this is an engineering problem, not just a security one
One remediation effort made this especially clear.
A team attempted to manually resolve roughly 2,000 CVEs. Initial estimates placed the effort at 72 man-months. A large team was staffed with an aggressive timeline. After two months, progress was minimal.
The challenges were structural:
- CVEs were addressed purely by priority labels
- There was no batching or smarter periodization
- Multiple engineers worked on the same issues independently
- There was confusion about whether security specialists or product engineers were needed
- Framework and library upgrades were poorly coordinated
The problem was not skill or commitment. It was process.
Vulnerability remediation was treated as a series of isolated fixes rather than a coordinated engineering system.
Asking the right question about AI
This led to a more grounded question—not whether AI could replace security tools, but whether it could reduce engineering effort.
Specifically:
- Can AI help automate or accelerate dependency upgrades so CVEs don’t accumulate?
- Can AI reduce the time required to fix critical CVEs without compromising quality or control?
These are practical questions rooted in delivery pressure, not experimentation.
Why AI matters now
AI becomes relevant not because vulnerability discovery is broken, but because remediation is repetitive, decision-heavy, and time-consuming.
Choosing which libraries to upgrade first, selecting safe target versions, understanding breaking changes, coordinating fixes across teams, and validating results—these are all areas where intelligent assistance can remove friction.
When applied correctly, AI does not remove humans from the process. It removes unnecessary loops.
In one large remediation effort, applying an AI-assisted approach reduced the total effort to approximately ten man-months. The improvement came from better prioritization, reuse of knowledge, and automation of repetitive execution—not from bypassing review or reducing standards.
Conclusion – The shift teams must make
Vulnerability management can no longer be treated as reactive cleanup work. It must be designed as an engineering system that scales with modern software.
Knowing you have a bug (Detection) is useless if you don’t have the resources to fix it. With over 130 new CVEs appearing daily in 2025, “finding” is easy; “fixing” is the bottleneck.
What matters now is:
- Context
- Prioritization
- Reuse
- Execution efficiency
- Governance
These five pillars define “Precision Remediation.”
Context means knowing if a bug is reachable; Prioritization means fixing what matters; Reuse prevents double-work; Execution is the speed of the patch; and Governance ensures every fix meets compliance standards.
This is where AI moves from experimentation to infrastructure.
In the next article, we’ll break down how an AI-assisted remediation pipeline works in practice—from intelligent analysis to guided upgrades and automated code fixes—and why it fundamentally changes how teams handle CVEs at scale.
