Defenders' playbook | Cyber Posture

My last article on how attackers will behave showed what they’ll do once LLMs flood the system with new CVEs. This essay looks at what defenders should do in response. Some moves are obvious. Others break twenty-year norms. 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.

Fixing issues, not finding them, is the constraint. The average time to fix a vulnerability is 252 days, and rising. Every recommendation below builds on that conclusion — finding more issues won’t move the needle.

Group	Name	Product appeal	LLM adoption	Primary attacker workflow
1	Soft primes	High	Slow	Zero-day mining, long dwell
2	Treadmillers	High	Fast	Patch-diff racing
3	Background noise	Low	Slow	Commodity scans, mass ransomware
4	Quiet efficient	Low	Fast	Lowest active pressure

The vendor-group map from the previous article. Vertical axis: product attractiveness to attackers. Horizontal axis: vendor LLM-adoption posture. Top-left = Vendor Group 1 (Soft primes), top-right = Vendor Group 2 (Treadmillers), bottom-left = Vendor Group 3 (Background noise), bottom-right = Vendor Group 4 (Quiet efficient).

Open chart in new tab · PNG version

Vendor options

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.

Recommendations.

Run a rapid LLM-assisted internal review of the code paths attackers hit most: authentication, deserialization, 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 moves to evaluate. Four moves worth considering:

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 labelled training example handed to attackers.
Why this is the playbook: The publish-to-exploit window has already collapsed (KEV Day-30 exploitation share: 8% in 2021 to 65% by 2023). Vendor Group 2 sits at the leading edge of that curve.

Recommendations.

Pay bug-bounty rewards high enough to beat the gray market, so researchers come to you instead of selling on the side.
Distribute patches through mechanisms that mask which file(s) changed: ship encrypted patch bundles and signed binary diffs only, no raw source diffs.
Implement auto-update tooling that gets patches deployed in hours, not days.

Unorthodox moves to evaluate. Four moves worth considering:

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.

Recommendations.

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 moves to evaluate. Three moves worth considering:

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.

Recommendations.

Keep doing what works.
Don’t broadcast your AI investment.
Position in advance the remediation infrastructure and a mature patch pipeline at Vendor Group 1 levels, even though current threat doesn’t warrant it.

Unorthodox moves to evaluate. Two moves worth considering:

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 uncomfortable 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 overview table summarises all thirteen; the detailed catalog below it lists how each one works, which attacker workflow it breaks, and the main risk.

#	Tactic	What it does	Main risk
1	Synthetic patch noise	Publish 2–3× the advisories actually needed, with cosmetic-only patches mixed in.	Erodes customer trust; legally risky where advisories imply a standard of quality.
2	Obfuscate patches	Rewrite each fix into a less obvious form so the real change is buried in unrelated refactors.	Hurts your own engineers; degrades patch quality long-term.
3	Randomize disclosure cadence	Spread advisory releases across the week or month instead of Patch Tuesday.	Friction for customer patch-management teams.
4	Coordinated customer disclosures	NDA-share critical advisories 30 days early with vetted customers.	Violates CRA, SEC rules, and 20+ years of full-disclosure norms.
5	Take credit for all CVEs	Claim every CVE was found in-house, even when an outside researcher reported it.	Betrays researchers; reputational hit if challenged publicly.
6	Over-attribute to LLMs	Add “discovered with [LLM]” to every advisory regardless of how the bug was found.	Pollutes industry data on actual LLM-discovery rates.
7	Silent-fix preference	Ship the fix in the next feature release without publishing a CVE.	Customers can’t prioritise; legally required for known-exploitable bugs.
8	Honeypot CVE issuance	File CVE numbers for non-vulnerabilities to noise-up the data attackers train on.	CNA abuse can cost the vendor CNA status.
9	Quiet-ignore reports	Stop processing external vulnerability reports entirely.	Violates responsible-disclosure norms; researchers go public with unfixed bugs.
10	Reclassify vulnerabilities	Narrow the disclosure policy to accept fewer kinds of reports.	Invites ridicule; legal liability if a dismissed bug later causes a breach.
11	Sacrificial-product strategy	Keep one weakened product as a deliberate honeypot to observe attacker tooling.	Customers on that version are unwitting bait.
12	Strategic silence	Don’t announce LLM-assisted SDLC publicly; stay off AI-security marketing lists.	Gives up the marketing benefit.
13	Decoy attractive products	Launch a sealed “demo” product to divert attacker attention from real ones.	High cost for unclear benefit.

1. Generate synthetic patch noise: How. Publish two to three times the advisories actually needed, with cosmetic-only patches interleaved with real fixes. Effect. Each fake advisory still costs an attacker a full round of patch analysis. Risk. Erodes customer trust in your advisories; legally risky in jurisdictions where advisories imply a standard of quality.
2. Obfuscate patches: How. Use the same LLM that found the bug to rewrite the fix in a less obvious way — refactor a few hundred lines around it so the real change is buried. Effect. Significantly extends the time attackers need to turn the patch into an exploit. Risk. Makes the patch harder for your own engineers to review; degrades patch quality over the long term; creates technical debt that the LLM finding the next bug can’t easily untangle.
3. Randomize disclosure cadence: How. Stop publishing on Patch Tuesday. Randomize advisory release across the week, or across the month. Effect. Breaks automated attacker tooling that assumes a predictable release schedule, and puts the attacker on your schedule instead of the other way around. Risk. Creates friction for customer patch-management teams who plan around the schedule; some customer SLAs presume Tuesday delivery.
4. Coordinated customer disclosures: How. Form an industry alliance where critical advisories are shared with vetted customers under NDA for 30 days before public CVE filing. Effect. Gives vetted customers a head start on remediation before attackers see the CVE. Risk. Violates the EU Cyber Resilience Act’s Article 13 disclosure timelines, the US SEC’s 4-day material-incident disclosure rule, and 20+ years of full-disclosure norms. Antitrust risk grows as the alliance gets larger.
5. Take credit for all CVEs: How. Claim credit for finding every CVE in your products, even when an outside researcher actually found it. Effect. Signals that your product is thoroughly audited internally and moves you off the attackers’ “under-audited” target list. Risk. Betrays the researchers who reported the bugs to you; damages the bug-bounty ecosystem you also depend on; if a researcher publicly contradicts your claim, the reputational hit outweighs the targeting benefit.
6. Over-attribute CVEs to LLMs: How. Add “discovered with [LLM]” to every advisory, regardless of how the bug was actually found. Effect. Inflates the attacker’s perception of vendor AI-assisted development pipeline maturity. Has an interesting connection to the LLM-credit tracker: if this tactic spreads, the public-credit signal becomes less meaningful. Risk. Pollutes the industry-wide picture of actual LLM-discovery rates; a partial confession (“we used an LLM for review, not discovery”) is hard to keep consistent.
7. Silent-fix preference: How. When a vulnerability is internally found, ship the fix as part of the next feature release rather than as its own advisory. Effect. Without a CVE, attackers have no patch-diff to study as training material. Risk. Customers can’t tell what to prioritise; the EU CRA and US SEC require CVE filing for known-exploitable bugs; the bug stays out there longer than necessary.
8. Honeypot CVE issuance: How. File CVE numbers for non-vulnerabilities — internal refactors, dead code paths, deprecated APIs. Effect. Keeps the data attackers train on noisier than the actual signal. Risk. CNA abuse — a vendor with CVE Numbering Authority (CNA) status filing junk CVEs can lose that status; permanent reputational damage if the practice is exposed publicly.
9. Quiet-ignore of external reports: How. Stop processing vulnerability reports from outside researchers. Send incoming reports to /dev/null (the digital trash). Effect. Your bug-bounty pipeline doubles as a way for attackers to find targets; shutting it down reduces inbound attention. Risk. Violates responsible-disclosure norms; frustrated researchers go straight to the public with unfixed bugs; legal liability rises if an ignored report later leads to a breach.
10. Re-classification of “what is a vulnerability”: How. Rewrite your vulnerability disclosure policy to accept fewer kinds of reports — e.g. “issues without a working exploit chain that shows customer harm are not vulnerabilities.” Effect. Reduces the incoming triage workload and the number of advisories you publish. Risk. Invites ridicule from the security community; legal liability if an issue you dismissed is later used in a breach; sets a fragile precedent that depends on aggressive legal interpretation.
11. Sacrificial-product strategy: How. Keep one product version intentionally weakened or poorly maintained as a deliberate honeypot. Effect. Watch what attackers throw at it without putting the core product line at risk. Risk. Customers stuck on that version are unknowingly being used as bait; ethically toxic if it ever comes out; the moment researchers spot the pattern, the deception turns into a much bigger story than the intelligence you got from it.
12. Strategic silence: How. Don’t announce your LLM-assisted development pipeline publicly. Don’t appear on lists of vendors doing AI-assisted security work. Effect. Stay invisible to attacker-side open-source intelligence (OSINT). Risk. Gives up the marketing benefit; some procurement teams reward visible AI investment when evaluating vendors.
13. Decoy attractive products: How. Spin up a deliberately well-marketed “demo” product that looks attractive but is a sealed environment (sandboxed deployment, no real customers). Effect. Diverts attacker attention from real revenue products. Risk. High cost for unclear benefit; difficult to maintain credibility without real customers; once detected, the deception turns into a PR liability.

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:

Automatic rollback when a patch ships, so customers can apply patches quickly without fearing regressions.
Distribution improvements: signed binary diffs delivered through standard package managers, with cryptographic patch authenticity. Cuts the chance that an adversary can intercept and tamper with patches in transit.
Customer beta channels for security patches that catch regressions quickly and feed back into release decisions.
“Patch Tuesday is dead.” A continuous-patch model where security fixes ship within 48 hours of being ready internally, separate from feature releases.
Publish a patch-deployment timeline for each customer cohort. Tells attackers what window to expect and makes the patch-Tuesday-to-attack-Tuesday cycle less profitable.

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

Closing

The two-sided LLM arms race resets the strategic question for every vendor. Not “how do we find more bugs faster,” but “how do we change what the attacker sees, knows, and can build with, now that both sides have LLMs.” The orthodox playbook — faster discovery, broader audit, heavier internal pipeline — is necessary but not enough, because it speeds up both sides equally. The unorthodox catalog above tries to break that symmetry between attacker and defender. Most of its entries come with costs that mainstream vendors will not pay today. A handful are already happening quietly, in places that won’t admit it.

Further research on individual tactics in the catalog — measuring how the cost of patch-diffing scales, mapping the legal limits in each jurisdiction, modelling how vendor groups settle into a game-theoretic equilibrium — will follow as separate posts as the analysis comes in.

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 not 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 cross-group moves dominate the leverage. Automated rollback, signed patch distribution, customer beta channels, continuous-patch releases, and published patch-deployment timelines.