Vulnerability research used to be constrained by the number of skilled people willing to stare at parsing code. That constraint is gone, and the numbers coming out of the machines that replaced it are hard to hold in your head.
Palo Alto Networks' NOVA system produced 14,090 findings across 3,915 open source projects in two months. Anthropic's Project Glasswing reported more than 23,000 potential vulnerabilities in the first half of 2026. AISLE, a company built entirely around autonomous vulnerability research, says it has disclosed more than 225 issues across thirty-odd projects including OpenSSL, curl and FreeBSD — that figure is the vendor's own account, though the curl and OpenSSL advisories crediting it are public.
On 22 July 2026, AISLE became the first AI-native CVE Numbering Authority, under ENISA's CVE root rather than the CISA and MITRE root that has historically governed this.
The number that reframes the others
Of Glasswing's 23,000 potential vulnerabilities, roughly 6% converted into published CVEs.
Hold onto that, because it disciplines the headline figures. Tens of thousands of findings is not tens of thousands of holes in your software. The overwhelming majority are false positives, duplicates, or technically real but not exploitable in any configuration anyone runs. Anyone quoting the raw finding counts at you — including a vendor selling scanning — is quoting the wrong number.
But 6% of 23,000 is still well over a thousand genuine vulnerabilities from a single programme in half a year, in software you almost certainly depend on transitively.
The actual problem: triage did not scale
Discovery is now automated. Verification is not. A human maintainer still has to read each report, reproduce it, judge severity, write a fix and coordinate disclosure — and open source maintainers were already overloaded before machines started filing reports at this rate.
The result is a growing backlog of flaws that are known to someone and not yet published, sitting in queues calibrated for a pre-AI submission rate. That backlog is the thing to think about, not any individual CVE.
It is also why the new CNA designation matters less than it sounds. AISLE's authority is narrowly scoped to its own software — vulnerabilities it finds in third-party projects still route through the affected project's own CNA, and therefore through the same human bottleneck. The pipeline was not widened.
What changes for a small team
Three things, none of which require you to become a security company.
CVE volume in your dependencies is going up, permanently. A spike in advisories against a library is now weak evidence about that library's quality — it may simply mean someone pointed a model at it. Do not switch away from a dependency because it started reporting more CVEs. The one that reports none may just be unexamined.
Absence of a CVE means less than it did. "No known vulnerabilities" used to loosely imply someone had looked. With a triage backlog, it can now mean the finding exists and has not surfaced. Treat quiet dependencies as unknown rather than safe.
Patch cadence beats auditing. You cannot review this volume and neither can anyone else. What you can do is shorten the gap between a fix existing and you running it, which is the only variable in this that you actually control.
The practical setup
For a small team, a workable posture is genuinely small.
Turn on automated dependency updates — Dependabot or Renovate — and configure them to group patch-level bumps into one pull request a week so the noise does not train you to ignore them. Enable your host's vulnerability alerts and actually route them somewhere a person reads.
Know what you ship. You cannot assess an advisory against a dependency you did not know you had, and most applications carry an order of magnitude more transitive dependencies than direct ones. A generated dependency list, refreshed on release, is enough.
Then triage by exploitability rather than by severity score. A critical rating in a code path your application never executes matters less than a moderate one in your authentication flow. The score describes the vulnerability; only you know your usage.
And upgrade regularly in small steps. The teams that get hurt are not the ones that missed a specific advisory, they are the ones three major versions behind who cannot take a security patch without a migration project.
The part worth watching
Attackers have the same tools. The published research is defensive and disclosed responsibly, but nothing about this technology is exclusive to the people filing reports. The window between a vulnerability becoming discoverable and becoming exploited should be expected to compress.
That is another argument for cadence over analysis. Speed of patching is the defence that scales with the threat; reading advisories is not.
The bottom line
Automated research has broken the old assumption that an unreported vulnerability is an unlikely one. Most of what these systems find is noise — the 6% conversion rate says so — but the real remainder still exceeds what maintainers can process. You cannot fix the pipeline. You can update your dependencies weekly, know what you actually ship, and prioritise by whether the vulnerable path is one your code ever runs.