A few days ago, I wrote about the CVE Tsunami and the uncomfortable reality facing vulnerability management today.
The problem isn’t simply that vulnerabilities are increasing.
It is that the entire ecosystem around vulnerabilities is accelerating.
Researchers are finding weaknesses faster. AI is making vulnerability discovery faster. Attackers are getting better at turning technical knowledge into exploitation.
But one part of the equation hasn’t accelerated at the same pace:
Remediation.
That is why Cloudflare’s announcement of Vulnerability Discovery and Remediation (VDR) caught my attention.
Not because another security vendor is using AI to find vulnerabilities.
But because Cloudflare is trying to connect discovery with what is actually happening in production — and then connect that understanding to mitigation and remediation.
That is a much more interesting evolution.
The problem with knowing that a vulnerability exists
Imagine your scanner tells you:
“There is a vulnerability in this application handler.”
That’s useful information.
But it leaves several questions unanswered.
Is the vulnerable code actually deployed?
Is the vulnerable function reachable?
Which production route reaches it?
Is that route actively being used?
How much traffic does it receive?
Is someone probing it?
Are existing security controls already blocking those requests?
Those questions matter because a vulnerability sitting in code is not automatically the same thing as an actively exposed vulnerability.
Cloudflare VDR is designed to bring some of this context into the vulnerability investigation.
Cloudflare says VDR can connect source-code analysis with information about active routes, traffic, security events and, when WAF is enabled, existing protections.
That changes the conversation from:
“We found a vulnerability.”
to:
“We found a vulnerability, and we have evidence about where and how it is exposed.”
That is a much more useful starting point for remediation.
The vulnerability and the exposure are two different things
This distinction deserves more attention.
A vulnerability can exist without being meaningfully exposed.
A vulnerable piece of code might be:
- unreachable from the internet
- behind an inactive route
- protected by effective controls
- deployed but rarely used
- or sitting in functionality that isn’t currently receiving suspicious activity
Another vulnerability with the same technical severity could be sitting behind a heavily used internet-facing API that is actively being probed.
Same vulnerability.
Very different situation.
This is why the next evolution of vulnerability management cannot rely solely on vulnerability metadata.
The code matters.
The asset matters.
The route matters.
The traffic matters.
The security activity matters.
The controls around it matter.
Cloudflare’s approach is interesting because it attempts to bring those signals together rather than treating the vulnerability as an isolated finding.
AI is moving from scanning to investigation
There is another part of VDR that I find particularly interesting.
Cloudflare isn’t describing a single AI model simply scanning an entire codebase and producing a list of findings.
Its workflow uses a reconnaissance agent to map request paths to relevant parts of the code, followed by hunter agents that investigate targeted sections of the authorized source code.
That is closer to an investigation than a conventional scan.
And there is an important control built into the process.
Cloudflare says production activity can help the system focus attention on code behind active or recently targeted routes, but that activity does not establish that a vulnerability exists.
The finding still has to be supported by evidence in the source code.
That distinction is critical.
Otherwise, AI could easily turn correlation into a finding.
The objective should not be:
AI finds more.
It should be:
AI investigates better.
The interesting part comes after discovery
This is where the story connects directly back to the CVE Tsunami.
If AI makes discovery dramatically faster, the industry cannot simply create more tickets.
At some point, the workflow has to move closer to the point where risk can actually be reduced.
Cloudflare VDR is designed around that idea.
After its investigation and validation process, Cloudflare says it can produce a recommended code patch and, where the evidence supports it, a narrowly scoped WAF rule that can reduce exposure while the code fix is reviewed.
That creates an interesting model:
Discover
↓
Validate
↓
Understand production exposure
↓
Reduce immediate exposure
↓
Fix the underlying code
↓
Verify
This is different from simply:
Scan → Ticket → Patch
Mitigation is not remediation
This distinction is extremely important.
A WAF rule can potentially reduce the ability to exploit a vulnerable path.
But it does not remove the vulnerability from the application.
The vulnerable code remains.
So I would look at the proposed WAF capability as a compensating control, not as a replacement for permanent remediation.
That can still be extremely valuable.
Consider a vulnerability discovered in an internet-facing application.
The development team may need time to understand the issue, develop the fix, test it and deploy it safely.
If a validated and narrowly scoped control can reduce exposure during that period, the organization has another option:
Reduce the risk now. Fix the defect permanently next.
That is a much more practical approach than treating remediation as a binary choice between “patched” and “unpatched.”
This is where the CVE Tsunami changes shape
This brings me back to the central idea behind my earlier article.
The CVE Tsunami isn’t just about the number of vulnerabilities.
It is about the increasing speed differential between discovery and remediation.
If discovery becomes machine-speed while remediation remains largely human-speed, the backlog can grow faster than the organization can process it.
Cloudflare VDR is interesting because it attempts to compress several steps that traditionally sit apart:
Code analysis
Production context
Risk evidence
Mitigation
Remediation
That doesn’t eliminate the remediation challenge.
But it potentially reduces the distance between discovering a vulnerability and doing something meaningful about it.
The real evolution is from findings to evidence
This may be the most important shift.
A traditional vulnerability finding might look like:
Vulnerability: X
Severity: High
Asset: Application A
A context-aware finding can become something closer to:
Vulnerability exists in this code path.
The code is deployed behind this production route.
The route is actively used.
Security activity is being observed against it.
Existing controls provide limited protection.
Here is a proposed mitigation.
Here is a proposed code fix.
The second version is much closer to something an engineering team can act on.
It reduces the amount of investigation that has to happen after the security team raises the finding.
And that is where AI could have a real impact on remediation velocity.
But automation needs boundaries
There is also a reason not to get carried away with the “AI fixes vulnerabilities” narrative.
Application security is full of edge cases.
A generated code change can introduce a regression.
A WAF rule can block legitimate traffic.
A seemingly correct remediation can behave differently under production conditions.
Cloudflare acknowledges this by keeping customer review in the loop. Its current VDR service performs automated checks on proposed changes, and the customer decides whether a proposed patch or mitigation is tested or deployed. The service is currently available through invitation-only early access via Managed Defense.
That is an important model:
Automate the investigation and preparation. Keep the decision and accountability where they belong.
Where vulnerability management could be heading
I think we are moving toward a vulnerability-management model where the unit of work is no longer simply the CVE.
It becomes the exposed vulnerability.
And eventually, perhaps, the exploitable exposure.
That means the workflow starts looking less like a vulnerability database and more like a continuous feedback loop:
Code
↓
Vulnerability
↓
Production exposure
↓
Threat activity
↓
Risk
↓
Mitigation
↓
Remediation
↓
Verification
The significance of Cloudflare VDR is not that it has solved this entire problem.
It hasn’t.
It is currently an early-access service, and the capabilities described are tightly connected to environments and telemetry within Cloudflare’s ecosystem.
But it demonstrates an important direction.
The race has changed
The first race was to discover vulnerabilities.
Then came the race to prioritize them.
Now the race is becoming:
How quickly can we move from discovery to meaningful risk reduction and permanent remediation?
That is the part of the CVE Tsunami story that I believe deserves more attention.
AI may continue to increase the number of vulnerabilities we can discover.
That is not necessarily the problem.
The real test will be whether our vulnerability-management processes can absorb that speed without simply producing a larger backlog.
Cloudflare VDR offers one possible direction:
Use AI to investigate the code.
Use production context to understand exposure.
Use evidence to determine urgency.
Use mitigation to reduce immediate risk.
Use remediation to remove the underlying weakness.
And keep validation in the loop.
The future of vulnerability management may therefore not be about finding more CVEs.
It may be about creating a much shorter path between:
“We found it.”
and
“The risk is gone.”
And that is where the real race from discovery to remediation begins.
