Much of the conversation throughout 2026 thus far has hyper focused on AI’s industrialization of vulnerability discovery and exploit development and the need to “patch faster”.
Tal Be’ery’s Dense in Depth challenges an assumption behind much of vulnerability management, that enough finding and fixing will eventually exhaust the supply of serious bugs. His dense-versus-sparse framing gives us a useful way to think about industrialized discovery and why our defenses need to work with vulnerabilities still present.
I’ve been unpacking this throughout the year in my Vulnpocalypse writing, and more recently in From Vulnpocalypse to Breachpocalypse?. Finding more weaknesses gives defenders valuable information, but turning that information into less business exposure requires considerably more work.
My concern is that we keep responding to a potentially dense supply of vulnerabilities by asking for a bigger remediation bucket. If substantial patching still leaves attackers with plenty of options, we need to invest more in preventing recurring failure modes and limiting what exploitation can achieve rather than deluding ourselves into thinking we can patch our way out of this storm.
We of course should compress patch cycles and service-level agreements (SLAs), while building around the certainty that exploitable weaknesses remain. In this article, I want to walk through Tal’s argument and what it means for the controls we deploy alongside faster remediation.
A Deeper Lake
In Dense in Depth, Tal revisits the longstanding question of whether software vulnerabilities are sparse or dense through a fishing analogy. Repeated searches that remove a meaningful share of a small population should eventually produce smaller catches, while a large remaining supply can keep yielding findings.
If vulnerabilities are relatively sparse, removing them should progressively exhaust the supply. In a dense environment, even a productive security program can keep discovering serious weaknesses without approaching a point where attackers struggle to find another one.
Tal examines Chrome’s security fixes and argues that AI-assisted discovery has exposed a deep reservoir of latent bugs, with findings continuing despite sustained patching. He does acknowledge an important limitation, Google does not publish its scanning effort, so changes in capability and investment complicate the comparison.
I find the framing useful as a planning assumption, while recognizing that a browser study cannot establish a universal vulnerability density for every codebase. We should design around the possibility that exploitable weaknesses remain after substantial remediation.
This is something that is proving true even int he age of frontier models, for example where OpenAI’s latest GPT 6 Cyber found nearly 1,000 LPE vulnerabilities in Linux despite the codebase being scanned and reviewed for decades and even by prior frontier models from OpenAI and others.
An individual patch can still remove a valuable attack path, especially on a widely deployed component with known exploitation. The density argument should change our expectations about exhausting the backlog, while preserving the incentive to repair the weaknesses that create meaningful exposure.
Tal also emphasizes that weaknesses can emerge from combinations of program states and execution paths, including assumptions that fail when operations occur in a different order. Counting lines of code or individual fixes gives us an incomplete picture of those interactions.
Meanwhile, the software we need to understand keeps changing. GitHub’s latest Octoverse update reports 34.3 billion commits across public and private repositories during October 1, 2025 through September 30, 2026, alongside 17.9 billion pushes.
Those figures measure repository activity, and a commit can contain a small change, generated material or work that never reaches production. Converting them into lines of shipped code or a vulnerability total would give us precision the data cannot support.
They do show the scale of change developers and security teams are trying to accommodate. More activity creates opportunities for useful automation, while making comprehensive review and ownership increasingly important wherever those changes become running software.
Earlier this year, FIRST’s June forecast projected roughly 66,000 CVEs for 2026. By October 29, Jerry Gamblin reported 88,886 published CVEs, compared with 39,333 over the same period in 2025.
That June projection has already been overtaken, and Jerry’s broader point matters too. Assigning an identifier makes a weakness visible to the ecosystem, while declining to name it leaves the underlying problem in place.
Exploitation Needs Its Own Denominator
A larger CVE count describes more recorded vulnerabilities, with reporting practices and discovery capability both affecting the total. Understanding attacks requires separate evidence about which weaknesses adversaries use and what happens afterward.
Empirical Security’s Michael Roytman counted 83,167 CVEs published between January 1 and October 19, with observed exploitation of 696 of those vulnerabilities by that cutoff. His haystack framing captures the prioritization challenge facing teams trying to find consequential exposures inside a much larger collection of findings.
Recent vulnerabilities have had less time to accumulate exploitation evidence, and observation itself is incomplete. A finding without known exploitation still deserves assessment, especially when it is reachable, consequential or likely to become attractive to attackers.
VulnCheck’s State of Exploitation 2026 identified 884 vulnerabilities with first-time exploitation evidence during 2025. Of that group, 28.96% had exploitation on or before CVE publication, up from 23.6% in 2024.
Publication is the reference point in that analysis, which means the figure should not automatically become a claim that every affected vendor lacked a patch. VulnCheck also found that overall exploitation timing patterns remained highly consistent between 2024 and 2025, a useful qualification alongside the early-exploitation figure.
Then there is the Zero Day Clock, which I covered earlier this year. The project retired its time-to-exploitation metric after identifying problems including unequal observation periods, where older vulnerabilities had years to accumulate evidence and recent ones had far less time.
I covered that change in The Zero Day Clock Stopped Ticking. Its earlier collapsing-timeline chart should be read with that correction, rather than repeated as a current measurement of acceleration or proof of AI causation.
My recent conversation with Jeremiah Grossman provides another useful counterweight. His research found confirmed exploitation of 3,769 of 253,912 CVEs published from January 2018 through mid-July 2026, and he described relatively flat exploitation patterns within that evidence.
Jeremiah also discussed roughly 600 CVEs tied to financial losses visible through his insurance data relationships. That is his observed slice of claims, with its own coverage limitations, and it reinforces why we should connect prioritization to actual consequences while continuing to watch for changing attacker behavior.
Exploitation remains a major source of those consequences. As I discussed in my DBIR coverage, the 2026 primary report places it at 31% of known initial access in the relevant breach dataset, while Mandiant’s M-Trends 2026 attributes 32% of investigated intrusions to exploits.
The denominators differ, but both reports give practitioners a strong reason to prioritize exploitation. Neither supports treating every published CVE as an equivalent business risk, because they aren’t.
Remediation Has More Than One Gate
The operational constraints were present well before this AI wave. Cyentia and Kenna’s Prioritization to Prediction research examined a 2019 vulnerability cohort followed into 2020 and found that defenders generally needed about a month after patch availability to remediate 50% of vulnerable assets.
That measures a halfway point across assets, with substantial work still remaining. The 2026 DBIR uses a different measure, reporting only 26% of the CISA KEV vulnerabilities in its analysis fully remediated and a median of 43 days across company-level median times from detection to full resolution.
In that analysis, completion means addressing all instances of the specific vulnerability within an organization. These studies describe different populations and clocks, so their numbers should inform our understanding of operational friction without becoming a fabricated longitudinal comparison.
Asaf Ezra and Stephenie Zhang’s recent a16z piece puts those operational constraints at the center of its argument. Verizon’s own remediation figure shows considerable variation between organizations, which makes it especially important to understand the actual capacity of the team responsible for a system.
I’ve discussed the upstream problem in The Remediation Receipts From Glasswing and Patch the Planet. Anthropic’s Glasswing update describes maintainers asking it to slow disclosures because they needed more time to design patches, alongside the human work required to verify findings and assess severity.
Patch the Planet, run by Trail of Bits with OpenAI support, makes that work visible through a pipeline of findings and patches. A generated fix still needs review and upstream acceptance, and a merged upstream change still needs to reach downstream users.
Then an enterprise has to determine whether the affected component is deployed, who owns it and what changing it could disrupt. Testing compatibility, navigating competing priorities and agreeing on acceptable downtime all consume capacity that a faster discovery engine alone cannot supply.
The enterprise backlog also contains decisions that need an explicit business owner. If a system cannot tolerate an update during its operating period, someone needs to authorize a tested mitigation or a replacement plan and accept the remaining exposure until that change happens.
Leaving the ticket open indefinitely obscures that decision and makes accountability difficult. A security team can explain the attack path and recommend options, while the team responsible for the service helps establish what interruption and recovery would mean to the business.
I want us to automate as much of that work as we can. Ownership and deployment readiness deserve the same attention as finding another weakness, because those capabilities determine whether a security fix becomes an operational improvement.
AI Has to Help Close the Loop
AI-generated patches have considerable promise, especially for repetitive changes and reducing the effort required to prepare a fix. We still need evidence that the proposed change removes the vulnerable behavior and preserves what the application is supposed to do.
Keith Hoodlet’s team at 1Password evaluated 6,080 patches after exclusions across six complex vulnerabilities and two models. With mixed-correctness information in the prompts, 26.0% fully remediated the vulnerability without erroneous application changes or security regressions.
The article was updated in October and acknowledges feedback that its constraints may have limited what agentic tooling could produce. These results establish a validation problem within the tested setup, and they should encourage better verification rather than a blanket dismissal of AI-assisted remediation.
For practitioners evaluating these tools, verification should include attempting the original exploit and variations that exercise the same vulnerable mechanism. Functional tests need to check valid behavior too, because rejecting every input might stop an exploit while breaking the service customers depend on.
A reviewer should be able to understand which invariant the patch restores and what evidence supports that conclusion. Keeping that evidence with the change gives downstream teams something more useful than a confident explanation from the model that wrote it.
There is also measurable progress in generation. Veracode’s Fall 2026 update reports an average security pass rate increasing from 56% to 62%, with the leading models reaching 73% on its tests.
Those are controlled security tasks, and the improvement deserves credit. They still leave meaningful failure cases, with uneven progress across vulnerability categories and languages, so assuming generated code is secure is a massive false assumption to make based on the latest evidence from academia and industry alike.
I recently responded to Jason Clinton’s optimistic “vulnzero” prediction. I hope the direction is right, while remaining skeptical that improvements in generation will resolve the ownership and maintenance problems surrounding existing software.
We also cannot combine GitHub’s activity figures with Veracode’s benchmark to calculate an industry vulnerability total. My concern is operational, software change is expanding rapidly while the evidence still calls for independent security checks and substantial remediation work.
Controls That Survive the Backlog
Tal’s practical response is to identify the assumption a vulnerability violates and build a mechanism that enforces it across a family of failures. I think that gives us a useful starting point for deciding where to spend our security engineering effort.
Eliminating classes of bugs has a longer history than the current AI discussion, as do most of these security primitives even if the VC’s and AI safety community don’t realize it. CISA advanced Secure by Design under Jen Easterly’s leadership, while Bob Lord and colleagues explicitly argued for eliminating entire categories of defects before products reach customers.
Parameterized queries address the mechanism behind SQL injection, while safe rendering frameworks help prevent recurring injection problems. Memory-safe languages can remove important memory-corruption failure modes, although authorization mistakes and business logic flaws still require their own controls.
Tal argues that discoveries should also teach us which underlying assumptions and mechanisms need attention. A recurring failure should lead us to improve the shared library or development pattern behind it, so the next project inherits a safer implementation alongside the fixes to existing instances.
For existing systems, exposure management needs to translate into concrete changes. An administrative interface that only a small operations team needs should sit behind controlled access, with an accountable owner, rather than remaining reachable by anyone on the internet.
Consider a vulnerable application whose service identity can also administer production infrastructure. Narrowing that identity’s permissions and restricting reachable services could reduce what an attacker achieves through the application, while the code fix moves through testing.
This also follows Tal’s defense-in-depth argument, designing systems to contain an intrusion when a weakness is exploited. Segmentation can interrupt lateral movement, and egress restrictions can complicate the transfer of stolen data. Again, concepts like these are fundamental to security and we’ve known them for decades, the problem is most organizations have simply neglected implementing them, due to resource constraints, competing priorities and in some cases apathy or even neglect.
Those controls need testing against real access paths, including vendor connections and emergency administration, where an exception can undermine the intended boundary.
That containment work also has to account for compromised developer environments and third-party access, illustrated in a16z’s supporting diagram. Verizon reports third-party involvement in 48% of breaches, while Mandiant describes stolen tokens and misconfigurations alongside vulnerability exploitation.
Scoping vendor access and using short-lived credentials can limit the reach of a compromised account. Package provenance checks and installation controls address another part of the problem, where malicious software arrives through a trusted workflow rather than an unpatched service.
Runtime protection can also give teams time to deliver a permanent repair. A narrowly scoped rule might reject an exploit request before it reaches vulnerable code, with monitoring to verify coverage and detect legitimate traffic being blocked.
Temporary protection should run alongside the code fix, with staged enforcement and rollback, as a16z’s proposed workflow illustrates. Encrypted traffic, alternate exploit paths and incomplete instrumentation can limit coverage, so confidence needs to come from testing the deployed control.
Recovery belongs in the same discussion. Mandiant describes attackers targeting backup infrastructure and management planes, which means protecting recovery access and exercising restoration are part of defending the business.
Separating recovery access and proving restoration can reduce the consequences when other defenses fail, as the a16z recovery design illustrates. A backup accessible through the same compromised administrative identity can leave the organization with considerably less recovery capability than its dashboard suggests.
In practice, I would start with a consequential service and trace how an attacker could reach it, which identity the service uses and what that identity can access afterward. That exercise should expose both patching priorities and opportunities to remove unnecessary access without waiting for a vendor update.
The inventory needs to stay connected to deployment changes, including new dependencies and credentials. Otherwise a well-designed boundary can become a historical description of the environment while the actual service acquires new paths around it.
We should make these protections operationally accountable, with owners and evidence that they work. A mitigation needs an expiration and a path to permanent repair, while patch SLAs should reflect exploitation, reachability and the business consequence of leaving the exposure open.
Tal’s emphasis on learning from findings and containing compromise gives us a better basis for measuring progress. I would rather see teams measure how long consequential exposure persists and whether controls actually contain it, alongside faster patching of the systems and attack paths that matter.
Closing Thoughts
Tal’s dense-versus-sparse argument gives us a reason to plan for weaknesses remaining even after substantial remediation. We should use discoveries to improve the mechanisms that prevent recurring failures, while building boundaries that limit the consequences of exploitation.
There’s no bucket big enough for a strategy that depends on eventually finding and patching everything. Faster patching remains essential, alongside controls that reduce exposure and let the business withstand the weaknesses we have yet to remove.
As I’ve repeated throughout the article, we’ve known these security concepts for decades.
It’s well past time to start actually doing them, rather than deluding ourselves into thinking patching alone gets us out of this or creates a more resilient digital infrastructure.
Stay resilient.