The defender's playbook for LLM-powered vulnerability discovery

As attackers use large language models to find and exploit CVEs faster, vendors need to shift from finding more bugs to fixing, shipping and deploying patches faster.

Takeaways

• Remediation speed is now the defining risk factor. Attackers can find vulnerabilities faster with large language models (LLMs), but the real exposure comes from slow patch deployment and delayed fixes.
• Different vendor profiles require different defensive strategies. Product attractiveness and AI adoption shape attacker behavior, meaning there is no one-size-fits-all security playbook.
• Unorthodox tactics may reduce attacker advantage—but carry real costs. Techniques like patch obfuscation, disclosure timing changes, or decoy efforts can introduce legal, operational, and trust risks.

My last article on how attackers will behave showed what they’ll do once LLMs flood the system with new Common Vulnerabilities and Exposures (CVEs). This essay looks at what defenders could do in response. Some moves are obvious. Others break norms and carry risk. We group by the four vendor types from that article, then list every move with its trade-offs.

The four vendor segments, recapped

The previous article sorted vendors along two axes: how fast they’re adopting AI and how appealing their product is to attackers. Each of the four vendor groups faces a different attacker playbook, so each needs a different defense.

Recommendations by segment

Vendor Group 1 — Soft primes (attractive product, slow AI adoption)

• Attack profile: The most attacked of the four groups; products are valuable to compromise.
• Key constraint: Slowest to speed up, because of outdated development pipelines and procurement rules.
• Why this is the playbook: They can’t outpace attackers over the next few years. “Just adopt LLM-assisted scanning faster” won’t close the gap by itself.

Orthodox moves:

• Run a rapid LLM-assisted internal review of the code paths attackers hit most: authentication, deserialization, server-side request forgery (SSRF).
• Aim to catch up with Vendor Group 2 within 18 months.
• Publicly commit to a patch-deployment timeline so customers can plan around it.
• Invest in automating fixes before automating discovery.

Unorthodox options:

• Issue fake patches alongside real ones.
• Hide what each patch actually changes.
• Vary the timing of CVE issuance.
• Coordinate disclosures with customer fleets.

See the catalog below for how each works, its risks, and when to use it.

Vendor Group 2 — Treadmillers (attractive product, fast AI adoption)

• Attack profile: Lives with the patch-diff treadmill. Attackers reverse-engineer every patch as soon as it ships.
• Key constraint: Every CVE they publish ships with a patch, and every patch is a labeled training example handed to attackers.
• Why this is the playbook: The publish-to-exploit window has already collapsed (Known Exploited Vulnerabilities (KEV) Day-30 exploitation share: 8% in 2021 to 65% by 2023). Vendor Group 2 sits at the leading edge of that curve.

Orthodox moves:

• Bug-bounty payouts high enough to beat the gray market, so researchers come to you instead of selling on the side.
• Patch distribution mechanisms that mask which file(s) changed: encrypted patch bundles and signed binary diffs only, no raw source diffs.
• Auto-update tooling that gets patches deployed in hours, not days.

Unorthodox options:

• Claim credit for every CVE, whether your team found it or not.
• Over-credit LLMs as the discoverer when reporting CVEs.
• Prefer silent fixes: ship the fix without publishing a CVE.
• Issue decoy CVEs as honeypots for attackers.

See the catalog below for how each works, its risks, and when to use it.

Vendor Group 3 — Background noise (low-attractiveness product, slow AI adoption)

• Attack profile: Not actively targeted by skilled attackers but swept up by automated scans and mass-ransomware campaigns.
• Key constraint: Smallest security budgets, often in the lowest-margin product categories.
• Why this is the playbook: Cost-effective tactics win here. The standard playbook is mostly to subtract and simplify.

Orthodox moves:

• Subscribe to managed development-pipeline services instead of building your own.
• Ship bare-bones advisories — “a vulnerability exists, update to v X.Y.Z” with no CVE description, no detail on which function is affected, no proof-of-concept — that make attackers do their own discovery work.
• End-of-life discipline: retire products on a publicly-announced schedule and don’t let a product turn into a permanent source of unpatched CVEs for attackers.

Unorthodox options:

• Quietly ignore reports from outside researchers.
• Rewrite the vulnerability disclosure policy to accept fewer kinds of reports.
• Sacrificial-product strategy: let an attractive product absorb attacker attention so the rest of the lineup stays quieter.

See the catalog below for how each works, its risks, and when to use it.

Vendor Group 4 — Quiet efficient (low-attractiveness, fast AI adoption)

• Attack profile: Lowest priority for active attacker campaigns; attackers pay less attention.
• Key constraint: AI investment pays off precisely because nobody is watching.
• Why this is the playbook: Real risk is climbing the attractiveness ladder by accident — an acquisition can flip a niche vendor into Vendor Group 1 overnight, and lighter security infrastructure gets brutally exposed during the transition.

Orthodox moves:

• Keep doing what works.
• Don’t broadcast your AI investment.
• Put the remediation infrastructure and a mature patch pipeline in place before you need them.Prepare at Vendor Group 1 levels, even though current threat doesn’t warrant it.

Unorthodox options:

• Stay strategically silent about your LLM-assisted development pipeline.
• Launch decoy attractive products to divert attacker attention.

See the catalog below for how each works, its risks, and when to use it.

The unorthodox catalog

These are not endorsements. They are moves the attacker-response model from the previous article says are available, each with its own trade-offs. The table below lists all thirteen: how each one works, the effect it has on the attacker, and the main risk it carries.

The remediation imperative

None of the tactics above substitute for closing the remediation gap. The previous article’s finding that remediation is the binding constraint has to come first; every other move on this page builds on it: if customers stay vulnerable for 252 days after a patch ships, attacker tactics adapt around that window no matter how clever your discovery work is. Concrete moves with the highest cross-group leverage:

1.      Automatic rollback when a patch ships. The real reason customers delay security patches isn’t ignorance — it’s fear of breaking production. A patch that takes down a live system can hurt as much as the attack it prevents, so teams test for weeks while the risk stays open. Automatic rollback removes that fear: every update ships with a safe, instant way to undo it and return to the last working state, with no data loss. When a patch can be reversed in seconds, customers stop stalling and apply it right away. The catch is that some changes — like database migrations — are hard to undo, so vendors have to build for reversibility from the start.

2.      Better patch distribution — small, signed updates. How a patch reaches customers matters as much as how fast it’s written. Many vendors still ship patches as big installers or raw source changes — slow to roll out and easy for an attacker to study or tamper with. The fix is to deliver small, signed updates that contain only what changed, through the package managers customers already use. The signature proves the patch really came from the vendor and wasn’t altered on the way; the small size means it installs in seconds, so more customers patch sooner. A side benefit: shipping a binary update instead of readable source gives attackers less to reverse-engineer.

3.      Customer beta channels for security patches. Vendors can find out whether a security patch breaks anything before it reaches everyone. A beta channel lets a small group of willing customers run updates first, in real environments, so problems show up within hours instead of after a company-wide rollout. That early signal tells the vendor whether to ship widely now or hold and fix. It also gives other customers confidence to patch quickly, because the update has already been proven on systems like theirs. The trade-off: beta customers take on a little more risk for early access, so the program needs clear opt-in and good monitoring.

4.      “Patch Tuesday is dead” — continuous patching. Monthly “Patch Tuesday” was built to keep enterprise IT predictable. But predictability now helps attackers: they know the schedule, and a fix that’s ready early can sit unreleased for weeks while it leaks or gets rediscovered. A continuous-patch model ships each security fix as soon as it’s tested — within a firm deadline like 48 hours — through a security-only channel, separate from feature updates. This removes the one delay fully in the vendor’s control: the gap between “fix ready” and “fix shipped.” It works best alongside rollback (#1) and beta channels (#3), and it asks customers to accept frequent small updates instead of one big monthly batch.

5.      Publish a patch-deployment timeline per customer cohort. This sounds backwards — why announce your schedule to attackers? But attackers already estimate how fast customers patch, and they time their exploits to the slow tail of that curve. The recommendation turns that hidden lag into a public, committed deadline for each type of customer (say, critical-infrastructure 72 hours, standard 7 days, long-tail 30 days). Making the commitment public pressures the vendor’s own teams to actually meet it, helps customers plan, and shrinks the window attackers rely on. The point isn’t secrecy — it’s accountability. Beating a deadline you’ve published is what removes the attacker’s timing advantage.

These five are the conservative baseline; the uncomfortable catalog above is the speculative layer on top.

Closing

The two-sided LLM race changes the main question for every vendor. It is no longer just “how do we find more bugs faster?” It is “now that attackers have the same tools, how do we change what they can see, learn, and build?” The orthodox playbook — faster scanning, broader audits, a heavier internal pipeline — is necessary but not enough on its own, because it speeds up both sides equally. The uncomfortable catalog above is an attempt to break that tie. Most of its moves carry costs mainstream vendors won’t accept today, and a few are already happening quietly, in places that won’t admit it.

That word “today” matters. By current norms, every tactic in the catalog ranges from distasteful to indefensible, and none of this is an endorsement. But norms follow conditions. If the trend the attacker-side analysis described keeps going — attackers finding most CVEs, a patch backlog that never shrinks, and disclosure rules that increasingly help the offense — it is fair to ask whether some of these moves shift from unthinkable to reluctantly debated. The disclosure norms that feel permanent today were themselves a reaction to an earlier threat era, and they can change again. The real question is not whether regulators and vendors should reach for these options. It is whether we are quietly heading toward a future bad enough to put them on the table — and whether it is better to weigh the trade-offs now, calmly, than to improvise them later under pressure.

We will dig into individual tactics in later posts: how quickly patch-diffing costs scale, what the law allows in each country, and how the four vendor groups settle into a stable strategy.

Key takeaways

• Fixing matters more than finding. Mean time to remediate is 252 days and climbing; every recommendation in this essay assumes that as the binding constraint.
• Different vendor groups need different playbooks. Soft primes (Group 1) need remediation-side automation first; Treadmillers (Group 2) need patch obfuscation and faster auto-update; the lower-attractiveness groups need cost-effective subtraction.
• Orthodox moves are necessary but may not be enough. Faster discovery, broader audit, and heavier internal pipelines accelerate both sides symmetrically.
• The unorthodox catalog breaks symmetry, with costs. Most entries trade legal exposure or ecosystem damage for attacker friction. A handful are already happening quietly.
• Five concrete moves provide leverage. Automated rollback, signed patch distribution, customer beta channels, continuous-patch releases, and published patch-deployment timelines.

Daily CVE analysis · Data: National Vulnerability Database (NVD), Exploit Prediction Scoring System (EPSS), Cybersecurity and Infrastructure Security Agency (CISA) KEV, MITRE ATLAS, OWASP LLM Top 10 for LLMs