# My AI Security Pipeline for WordPress Plugins — Austin Ginder ## 🗂️ Triage — annotated highlights surfaced > [!note]- Cross Reference > - **An AI finding is a claim, not a vulnerability** — the governing rule; the audit is the maker, the proof-of-concept is the blind checker. #xref #aphorisms > - **Make the AI run the exploit to kill false positives** — reading code asserts, running the exploit proves; transferable to any AI-assisted engineering. #xref #addendum > - **Audit the unique build, not each website** — hashing identical builds is what makes personal-scale coverage possible (already promoted to a Permanent). #xref > - **Coverage, not the bounty, is the payoff** — most real bugs pay nothing but still need patching; report to the vendor. #xref #aphorisms ## 🧭 Bib capsule Austin Ginder, "My AI Security Pipeline for WordPress Plugins," anchor.host, 2026 — https://anchor.host/anyone-can-audit-wordpress/ ## 🧠 Author's thesis (Adler Q1+Q2) A solo host operator built a four-step Claude Code pipeline that audits plugin code, proves each finding by firing the exploit on a fresh local WordPress install, then submits it to a bounty platform or the vendor — moving plugin security auditing from specialist firms to any individual with a Claude subscription. In detail, the load-bearing rule is governance, not tooling: an AI audit produces a claim, and a claim is not a vulnerability until a live exploit fires against real WordPress defenses (`wp_kses`, capability checks). The Gutenverse near-miss — where Claude nearly discarded a real tagless-attribute bug by pattern-matching it to a disproven one — is proof that source-reading asserts while execution proves. Two rules make it cheap: audit only the latest version, and audit each unique build once by hash. ## 🧩 Key arguments - The prove-by-running gate is maker/checker discipline applied to security research: the false-positive rate "drops off a cliff" once the model must fire the exploit instead of asserting from a code read. - Scaling comes from auditing code, not installs — hashing identical builds lets one operator on a $200/month plan cover the popular head of the repository (every plugin above 500k installs at its current version). - The economics have inverted: most real bugs earn no bounty, so the payoff is coverage, and direct-to-vendor becomes the default path — but every metric here is single-source self-report (94.7% install-weighted flatters the raw 41%). ## 🗒️ Notes — Literature atoms ### An AI finding is a claim, not a vulnerability > [!quote] > It is a claim that needs to be verified. - **Where**: "Treat every AI finding as a claim, not a fact" section - **Why**: The governing rule of the whole pipeline; maps directly to maker/checker — audit is the maker, proof-of-concept is the blind checker. ### Make the AI run the exploit to kill false positives > [!quote] > The false positive rate drops off a cliff the moment you make Claude prove its own claims instead of asserting them from an audit. - **Where**: Same section, immediately after the thesis - **Why**: Reading code asserts, running the exploit proves — transferable to any AI-assisted engineering. ### Audit the unique build, not each website > [!quote] > You are auditing code, not websites. - **Where**: "Two rules that save an enormous number of tokens" section - **Why**: Hashing identical builds across thousands of installs is what makes personal-scale coverage possible — this claim is already promoted to a Permanent note. ### Coverage, not the bounty, is the payoff > [!quote] > The value is not the bounty. The value is the coverage. - **Where**: "Most real bugs are not worth any money" section - **Why**: Reframes success — most real bugs pay nothing but still need patching, so report to the vendor. ### The popular head of the repository is fully covered > [!quote] > Every single plugin above 500,000 installs has been audited at its current version. - **Where**: Coverage-by-tier section near the close - **Why**: The headline result; note it's install-weighted, not raw-count (2,050/5,000 = 41%). ## 🔖 Permanent candidates - Audit the build, not the install — already promoted as [[Auditing the Build Not the Install Is What Makes Personal-Scale Coverage Possible]]; no new promotion needed. - Trust an AI claim only after it re-derives from source — already covered by [[The Maker Should Not Grade Its Own Homework]]; link rather than re-promote. ## Links - [[WordPress Hosting Security Stack MOC]] — home MOC; this is the "anyone can audit" democratization layer of the plugin-security stack. - [[Open Source Governance MOC]] — reframes who is responsible for scanning the repository, a governance question as AI-scale reporting arrives. - [[Auditing the Build Not the Install Is What Makes Personal-Scale Coverage Possible]] — the promoted Permanent this note's strongest claim (H3/H5) already feeds. - [[The Maker Should Not Grade Its Own Homework]] — the run-it-to-prove-it rule is maker/checker discipline; the Gutenverse near-miss is a worked instance. - [[AI Finds Exploit Chains Faster Than Humans Can Audit Them]] — extends the same pipeline tension: automated discovery scales faster than human reproduction and disclosure work. - [[Build anything with Claude & WordPress]] — Ginder's companion talk; the build-fast pipeline whose output this security-audit pipeline scans at scale. ## ✅ Processing checklist - [x] Claim atoms carried from deep-read analysis - [ ] Permanent candidates reviewed for promotion - [ ] Version History Diff check