My AI Security Pipeline for WordPress Plugins  🔗 **Source:** [My AI Security Pipeline for WordPress Plugins](https://anchor.host/anyone-can-audit-wordpress/) > [!note]+ Document Notes > tags: [ai-security, wordpress-plugins, vulnerability-disclosure, claude-code, bug-bounty, security-automation] > author: Austin Ginder > source: anchor.host > reference: https://anchor.host/anyone-can-audit-wordpress/ > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: My AI Security Pipeline for WordPress Plugins > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Coverage scoreboard — wpregistry.io/coverage](https://wpregistry.io/coverage) - [Patchstack](https://patchstack.com/) and [Wordfence](https://www.wordfence.com/) — the two bug bounty platforms referenced. - CVEs named: JetSmartFilters (9.3 SQL injection), Abandoned Cart Pro for WooCommerce (privilege escalation), WooCommerce Anti-Fraud (broken access control), Simple Shopping Cart (IDOR). ## 📝 Summary - A solo WordPress host operator built a four-step AI pipeline (Claude Code slash commands) 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 straight to the vendor. - Why it matters: it moves plugin security auditing from specialist security firms (Wordfence, Patchstack) to any individual with a Claude subscription and a local WordPress. That reframes who is responsible for scanning the repository. - Key stakeholders: WordPress plugin authors, bounty platforms, hosting companies, and the millions of sites running the top 5,000 plugins (~327M active installs). - Risks and tradeoffs: AI over-reports (false positives), bounty economics are shrinking, and the metrics here are one operator's self-reported dashboards, not independently audited numbers. - Bottom line: the discipline that makes AI auditing trustworthy is the same maker/checker rule — never trust a finding until you make it prove itself by running the exploit. Reading beats source-reading; only runtime confirms. ## 📖 Main Content - The core thesis is a governance rule, not a tooling trick: an AI audit produces a *claim*, and a claim is not a vulnerability until you have fired the exploit against a real WordPress install with its own defenses (`wp_kses`, capability checks) in place. This directly mirrors Courtney's maker/checker doctrine — the auditor is the maker, the proof-of-concept run is the blind checker that re-derives truth from source (a live exploit) rather than grading the audit's own reasoning. - The pipeline has four steps, each a Claude Code slash command: (1) `/wp-registry-scan` fans out parallel sub-agents to read every PHP file for injection, missing capability checks, and broken access control; (2) `/proof-of-concept` spins up a fresh site, installs the exact version, seeds the scenario, and tries to fire the exploit — if nothing fires, the finding dies; (3) submit real high-impact bugs to a bounty platform, everything else to the vendor; (4) redirect or follow up (out-of-scope → vendor, duplicate → move on, accepted → track to CVE). - The Gutenverse case is the load-bearing anecdote. The "glamorous" finding (an image block echoing an SVG value with no sanitizing) was a false positive — `wp_kses` stripped the tag. The "boring sibling" (a Fun Fact block attribute breakout with *no tag*) was the real vulnerability, because `wp_kses` only processes tags, so a tagless value survives. Claude nearly discarded the real bug by pattern-matching it to the disproven one. Only the run-it rule saved it. - The tell for guessing: if your reason for dismissing a finding uses words like "bounded," "harmless," or "does not reach," you are inferring runtime behavior from source code — the moment to stop and build the proof of concept. - The economics: most real bugs are not bounty-eligible (only the highest-impact tier qualifies — unauthenticated SQLi, account takeover). A Contributor-level stored XSS is real, needs patching, but pays nothing. Report anyway; route to the vendor. Payout math is thin and shrinking: ~$550 for May, which the author says would have been $0 in June under tightening guidelines. - Two rules make it scale cheaply: audit only the latest version (old versions waste tokens and get rejected as stale), and audit each unique build exactly once (hash identical files across thousands of sites — you audit code, not websites). The bottleneck is tokens, not speed; the whole operation runs on a $200/month Claude Max plan shared with all other work. - Contested / uncertain: every performance and coverage number is self-reported from the author's own logs and dashboards. The 94.7% weighted coverage figure counts by active installs, which flatters the picture — the raw count is 2,050 of 5,000 plugins (41%). Both framings are true; the weighting choice is a rhetorical one worth naming. ### 🗒️ Notes - Author positions himself as not-a-security-researcher — a host who patches sites and cleans malware — to make the "anyone can do this" claim land harder. - Democratization framing: "Not just Wordfence. Not just Patchstack." One person + Claude subscription + local WordPress can audit a large portion of the repository. - Step 2 is the whole thesis operationalized: force the AI to stop reading and start running. False-positive rate "drops off a cliff" once Claude must prove claims rather than assert them. - Gutenverse transcript is a rare in-the-wild example of an AI catching its own pattern-matching error mid-reasoning — "I refuted the first one empirically. I am about to refuse the second one on a guess." That self-correction is exactly the behavior maker/checker discipline is meant to force structurally rather than hope for. - Wordfence scorecard: 8 pending, 6 duplicates, 1 rejected out of scope, 1 validated. Duplicates dominate — others are running similar scans, so speed-to-file matters (echoes the job-scan "apply same-day" pattern). - Patchstack May: 10 validated, 7 valid-but-duplicate, 5 rejected. Validated ten ranged CVSS 6.5 up to a pair of criticals at 9.8 and 9.9. - Public CVEs that landed: 9.3 SQLi in JetSmartFilters, priv-esc in Abandoned Cart Pro for WooCommerce, broken access control in WooCommerce Anti-Fraud, IDOR in Simple Shopping Cart. - Scale numbers: 918 unique plugin/theme builds in a 7-day stretch; busiest single day 396; ~100 plugins per sitting with 10 audits running in parallel. - Inflow vs. throughput: top 5,000 plugins pushed only 612 updates in 7 days (1,680 over 30 days). One person auditing ~1,000 builds/week outpaces the ~600/week inflow — an individual can stay current with the popular half, not just sweep once. - Coverage by install tier: 10M+ 100% (3/3); 500k+ 100% (68/68); 100k+ 99% (333/335); 10k+ 62% (886/1,433); 1k+ 13% (368/2,766). The head is covered; the long tail is the gap. - Turnover framing: last 24h 112 plugins (2.2%, ~33.7M installs); 7d 612 (12.2%, ~81.4M); 14d 984 (19.7%, ~117.3M); 30d 1,680 (33.6%, ~184.5M). ## 📚 References - [My AI Security Pipeline for WordPress Plugins — Austin Ginder, anchor.host](https://anchor.host/anyone-can-audit-wordpress/) - [wpregistry.io/coverage — public coverage scoreboard](https://wpregistry.io/coverage) - [Patchstack](https://patchstack.com/) - [Wordfence](https://www.wordfence.com/) - Related reading for Courtney's own thread: Patchstack 7.0.2 SQLi and Repository RCE disclosure writeups (recently deep-read). ## 🗣️ Paraphrase - Auditing WordPress plugins for security used to belong to specialist firms. It doesn't anymore — one person with Claude and a local WordPress install can scan a big slice of the repository and find unreported bugs. - The pipeline is four commands: audit the code, prove the finding by actually firing it locally, submit it to a bounty platform or the vendor, then redirect or follow up until it closes. - The one rule that matters most: an AI finding is a claim, not a fact. Make the AI run the exploit for real; the false-positive rate collapses the moment it has to prove rather than assert. - A real example: the flashy finding was fake (stripped by `wp_kses`), the boring one was real (a tagless attribute breakout that survives the filter), and the AI nearly threw the real one away by assuming it matched the fake one. - Most real bugs earn no bounty but still need patching, so report them to the vendor. Two rules keep it cheap: audit only the latest version, and audit each unique build once. The value isn't the payout — it's the coverage. ## 📰 Newsletter - A WordPress host just showed that plugin security auditing is no longer a job only Wordfence and Patchstack can do. Austin Ginder wired four Claude Code slash commands into a pipeline that reads plugin code, then *proves* each finding by firing the exploit on a throwaway WordPress install before anyone submits it. - The keeper idea for anyone building with AI: treat every finding as a claim, not a fact. The false-positive rate falls off a cliff the moment you make the model run the exploit instead of asserting it from a code read. It's maker/checker discipline applied to security research — and there's a great real-world moment where Claude nearly discards a genuine bug because it looked like a false positive it had just disproven. - The scale is the eye-opener: one operator, ~1,000 unique plugin builds a week, on a $200/month plan, covering every plugin above 500k installs at its current version. Coverage scoreboard: [wpregistry.io/coverage](https://wpregistry.io/coverage). - Worth reading alongside the recent Patchstack disclosures if you run production WordPress or ship plugins. ## ✅ Action Items #### DevRel - Developer advocacy: consider a talk/demo on "treat AI findings as claims" — the run-it-to-prove-it rule generalizes well beyond security to any AI-assisted dev workflow. - Education: build a short workshop or office-hours segment on local proof-of-concept setup (fresh WP install, seed scenario, fire exploit) as a teachable maker/checker loop. - Developer experience: document the `wp_kses` tag-vs-attribute nuance (tagless values survive the filter) as an examples-first security note for plugin authors. - Developer marketing: the "anyone can audit" framing is a strong narrative hook for responsible-disclosure content. - Community management: flag the disclosure-etiquette angle — the author thanks platforms for tolerating early mistakes; set norms for new AI-assisted reporters. - Internal/external/cross-project: align with plugin review team on the duplicate-flood problem this creates. #### OSPO - Policy & Governance: define contribution/disclosure policy for AI-assisted vulnerability reports before the volume spikes. - License Compliance: not applicable to this source — the piece is about security auditing, not licensing. - Security Management: vuln intake and embargo policy needs an explicit "proof-of-concept required" gate matching step 2 of this pipeline. - Software Inventory: hashing unique plugin builds is a de facto SBOM-adjacent practice worth borrowing for freshness tracking. - Developer Support: consult on tooling/legal guardrails for individuals now running mass audits. - Community Engagement: coordinate with upstream platforms on scaling submission review. - Strategic Alignment: report the coverage-vs-bounty economics shift to leadership. #### Community - Maintainers: release hygiene matters more now — a new release is the only thing that creates a fresh build to audit. - Contributors: onboarding for first-time security reporters to avoid platform-banning mistakes. - Sponsors: not applicable to this source — no sponsorship model discussed. - Ecosystem: coordinated-disclosure drills as AI raises report volume. #### WordPress - Core: not applicable to this source — no core-specific action; the piece targets plugins. - Plugins: review throughput and security-liaison capacity will be stressed by AI-scale reporting; provenance checks on unique builds are relevant. - Security: map the Contributor-level stored XSS "coverage gap" (real bug, no bounty) as a policy question for the security team. - Hosting: cross-host checklists could adopt the "audit the build, not the install" hashing approach. - Meta/Tide: Tide's automated scoring overlaps this space — a false-positive review loop is directly relevant. - Documentation: examples-first pattern for `wp_kses` behavior with tagless attributes. #### The WPCC - Not applicable to this source — no funding-experiment or fellowship angle raised. ### FAIR - Technical independence: the build-hashing/provenance approach aligns with local metadata and provenance goals; a self-run auditing pipeline is an independence story worth noting. ## 🧪 Hypotheses - Requiring a live proof-of-concept before submission reduces false-positive vulnerability reports by a large margin versus audit-only reporting. - Auditing each unique build once (by hash) rather than per-install lets a single operator cover the popular head of the repository within a fixed token budget. - Tightening bounty guidelines in 2026 reduces payouts faster than AI reduces the cost of finding bugs, pushing more valid findings toward direct-to-vendor reporting. - AI code auditors systematically over-weight "glamorous" tag-based findings and under-weight tagless attribute-breakout bugs unless forced to test empirically. - Duplicate rates rise as AI auditing democratizes, making speed-to-file the dominant factor in bounty eligibility. ### 📊 Methodology - Controlled comparison: run a sample of plugins through audit-only vs. audit-plus-proof and measure validated-vs-rejected rates on a bounty platform. - Token-budget study: log token spend per unique build and model coverage as a function of monthly budget and inflow rate. - Longitudinal payout tracking across the guideline change to test the $550→$0 claim generalizes beyond one operator. - Blind classification test: feed known tagless-attribute bugs to an AI auditor and measure the discard rate without a run-it rule. ### ❓ Questions - Does the "94.7% weighted by installs" figure hold up if weighted by number of plugins instead? (Raw count says 41%.) - How reproducible is the pipeline for someone who is not already a hosting operator with thousands of sites to hash? - What is the actual false-positive rate before and after step 2, in numbers rather than "off a cliff"? - How do platforms plan to handle the incoming volume of AI-assisted reports and the duplicate flood? - Where does vendor-direct disclosure go when the vendor is unresponsive or hostile? ### 🔮 Future Research - A shared, deduplicated registry of audited builds so multiple operators don't re-audit identical hashes. - Standardized proof-of-concept harnesses (fresh WP + seeded scenario) as reusable, open tooling. - Study of the "coverage gap" tier — bugs real enough to patch but below every bounty bar — and who ends up patching them. ### 💡 Implications - Practice: security auditing shifts from firms to individuals; the differentiator becomes disclosure discipline and proof, not access to scanning tools. - Policy: bounty platforms must redraw scope as supply of valid findings outpaces budget. - Security: the run-it-to-prove-it rule is a transferable safeguard for any AI-assisted engineering, not just security. - Education: local proof-of-concept setup becomes a core teachable skill. - Funding models: direct-to-vendor becomes the default path for the majority of real-but-unpaid bugs. ### 🧠 Learning Styles Assessment - Reading level estimate: approximately Flesch-Kincaid grade 8–9 (Flesch Reading Ease roughly 60–65). Short sentences, concrete nouns, minimal jargon beyond `wp_kses` and CVSS. Accessible to a general developer audience. #### 👀 Visual learners - Present: inline numeric breakdowns (coverage tiers, turnover percentages); a referenced public scoreboard. - Improve: an architecture diagram of the four-step pipeline; a before/after bar chart of coverage by install tier; a flow showing where findings branch to bounty vs. vendor. #### 🔊 Aural learners - Present: none — text only. - Improve: a 3–5 minute audio summary of the pipeline and the Gutenverse anecdote. #### 🗣️ Verbal learners - Present: strong analogies ("glamorous finding was fake and the boring sibling was the real one"), plain-language callouts in bold. - Improve: a short glossary (`wp_kses`, CVSS, IDOR, broken access control, stored XSS). #### 🧩 Kinesthetic learners - Present: step-by-step pipeline; the proof-of-concept is inherently hands-on. - Improve: a reproducible lab (sample vulnerable plugin + commands) readers can run. #### 🧠 Logical learners - Present: clear cause-effect reasoning; inflow-vs-throughput math; tiered tables in prose. - Improve: a decision tree for step 4 (out-of-scope → vendor, duplicate → drop, accepted → CVE); an explicit false-positive KPI. #### 🧑‍🤝‍🧑 Social learners - Present: the transcript dialogue between Austin and Claude models a pairing interaction. - Improve: a discussion prompt or community thread on disclosure etiquette. #### 🧘‍♀️ Solitary learners - Present: self-paced, reflective first-person narrative. - Improve: a self-check ("is my dismissal reason a guess?") worksheet from the "bounded/harmless/does not reach" tell. #### 🌿 Naturalistic learners - Present: ecosystem framing (head vs. long tail of the repository). - Improve: lifecycle view of a plugin build from release to audit to CVE. ### 📊 Accessibility Assessment - Assessment covers the source article as published; the reference is a blog post, so several media criteria are not applicable. #### Screen reader semantics - Present: clear heading hierarchy and bold emphasis in the source. - Improve: ensure the numeric breakdowns render as real tables with headers, not run-on prose, for screen reader navigation. #### Keyboard navigation - Present: standard blog article, links keyboard-reachable. - Improve: not applicable beyond standard web navigation — no custom interactions. #### Contrast and readability - Present: standard blog typography. - Improve: verify the anchor.host theme meets 4.5:1 on body text and links. #### Text resizing and reflow - Present: prose reflows. - Improve: confirm the inline data lists don't clip at 200% zoom. #### Media and captions - Present: the author mentions recording the exploit "on camera" but no captioned video is embedded in the text provided. - Improve: if a demo video ships, add captions and a transcript. #### Forms and interactions - Not applicable to this source — the article contains no forms. #### Standards reference - Map the prose-as-data-tables gap to WCAG 2.2 AA 1.3.1 (Info and Relationships); confirm link contrast against 1.4.3. ### 🌍 DEIB Assessment #### Cultural breadth - Present: the "anyone can do this" framing is inclusive of non-specialists. - Improve: examples are English/US-platform centric (Wordfence, Patchstack); note global disclosure norms. #### Inclusive language - Present: plain, jargon-light, gender-neutral. - Improve: expand security acronyms on first use for non-experts. #### Neurodiversity support - Present: chunked sections, consistent bolded takeaways, predictable structure. - Improve: a short TL;DR at the top would help. #### Representation - Present: single first-person operator perspective. - Improve: balance with voices from plugin authors on the receiving end of AI-scale reports. #### Psychological safety - Present: honest, non-blaming framing; the author owns his own mistakes ("nearly threw away the actual vulnerability"). - Improve: a note on responsible disclosure timelines to protect vendors and users. ### ✅ Logical Validity #### Strong reasoning - Causal (strong): "make the AI prove its claims → false-positive rate drops" is supported by a concrete mechanism (WordPress runtime defenses like `wp_kses`) and a worked example (Gutenverse), not just assertion. Location: the "claim, not a fact" section. - Inductive (moderate): the scaling argument (inflow < throughput, therefore one person can keep pace) follows from the author's own logs; the logic is sound *if* the input numbers are accurate. - Analogical (strong): the glamorous-vs-boring-sibling framing clarifies why pattern-matching misfires — a genuinely illuminating analogy. #### Fallacies - Hasty generalization / sample of one: "One person ... can audit a large portion of the entire WordPress repository" generalizes from a single operator who already runs thousands of sites (giving him the build corpus to hash). Fix: state the preconditions that make the throughput reachable. - Suppressed-framing / misleading vividness: "94.7% weighted by active installs" foregrounds the flattering metric; the raw 2,050/5,000 (41%) is present but downplayed. Both are true — name the weighting choice explicitly rather than leading with the rosier number. - Unverifiable self-report: all payout, dashboard, and coverage figures are the author's own screenshots. Not a fallacy per se, but every metric is single-source and should be read as a claim, not an audited fact — the same skepticism the article itself preaches. The $0-for-June payout is a projection, not a recorded result. #### Tone of voice - Confident, plainspoken, self-deprecating about mistakes ("Huge thanks for Patchstack and Wordfence for not outright banning me"). Persuasive and practitioner-credible; the humility about false positives strengthens rather than weakens the case. ### 🛡️ DARVO Analysis - Not applicable to this source — the article is a first-person methodology writeup with no accused party, no defensive posture, and no accuser to attack. There is no denial, attack, or victim/offender reversal to analyze. If anything, the author volunteers his own errors rather than deflecting them. ## 🎯 Conclusion - Bottom line: the tooling is interesting, but the transferable lesson is the discipline — an AI finding is a claim, and only running the exploit turns it into a fact. That is maker/checker doctrine applied to security research, and the Gutenverse near-miss is proof that no amount of careful source-reading substitutes for the checker step. - Practical next steps for readers: adopt a "prove it before you trust it" gate for any AI-assisted work; when your dismissal reason sounds like "bounded" or "harmless," stop and test; and read the coverage/payout metrics here as single-source claims, weighing the 41% raw coverage against the 94.7% install-weighted figure before repeating either. ## 🔄 Refactor Appendix — My AI Security Pipeline for WordPress Plugins > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Resonance filter applied: five atoms carry the piece — the claim-not-fact > thesis, the prove-by-running fix, the build-not-install scaling rule, the > coverage-over-bounty value inversion, and the head-of-repo coverage result. ### 📚 Literature Atoms (H3) #### [H1] An AI finding is a claim, not a vulnerability > [!quote] ID:rw_anchor01 > It is a claim that needs to be verified. **Context & use**: - "Treat every AI finding as a claim, not a fact" section. - The governing rule of the whole pipeline; maps directly to maker/checker — the audit is the maker, the proof-of-concept is the blind checker. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H2] Make the AI run the exploit to kill false positives > [!quote] ID:rw_anchor02 > The false positive rate drops off a cliff the moment you make Claude prove its own claims instead of asserting them from an audit. **Context & use**: - Same section, immediately after the thesis. - The operational fix: reading code asserts, running the exploit proves. Transferable to any AI-assisted engineering. **Tags**: #xref #addendum <!-- atomicity: 1 idea ✓ --> #### [H3] Audit the unique build, not each website > [!quote] ID:rw_anchor03 > You are auditing code, not websites. **Context & use**: - "Two rules that save an enormous number of tokens" section. - Hashing identical builds across thousands of installs is what makes personal-scale coverage possible. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H4] Coverage, not the bounty, is the payoff > [!quote] ID:rw_anchor04 > The value is not the bounty. The value is the coverage. **Context & use**: - "Most real bugs are not worth any money" section. - Reframes success: most real bugs pay nothing but still need patching, so report to the vendor. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H5] The popular head of the repository is fully covered > [!quote] ID:rw_anchor05 > Every single plugin above 500,000 installs has been audited at its current version. **Context & use**: - Coverage-by-tier section near the close. - The headline result — one person covering the most-installed plugins; note it's install-weighted, not raw-count. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Trust an AI claim only after it re-derives from source **Claim** (one sentence, Courtney's voice): An AI's finding is advisory until an independent check re-derives it from source — running the exploit, re-running the test — because source-reading asserts while execution proves. **Evidence pointer**: [[#H1]] and [[#H2]] **Scope & conditions**: Holds wherever an AI's output is a checkable claim (security findings, test results, code correctness). Breaks when no cheap deterministic check exists to re-derive the result. **Links** (≥1 with annotation): - [[Maker-checker discipline]] — because extends - [[Verify before done]] — because applies-in AI-assisted security work `proof_state: supported` <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] The `wp_kses` tag-vs-tagless-attribute nuance is a reusable plugin-security teaching example — write it up examples-first. #fleeting #inbox - [F2] Duplicate-flood pattern (6 of 8 Wordfence reports were dupes) echoes the job-scan "file same-day" lesson — worth a cross-note. #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a DevRel note or talk framing "treat every AI finding as a claim, not a fact" as maker/checker for AI-assisted dev — anchor.host pipeline #things - [ ] Read alongside the recent Patchstack SQLi/RCE writeups and log the Contributor-level XSS "coverage gap" as an open security-policy question #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/My AI Security Pipeline for WordPress Plugins.md|My AI Security Pipeline for WordPress Plugins by Austin Ginder]] ## Highlights - It is a claim that needs to be verified. ([View Highlight](https://read.readwise.io/read/01kxts7c9ja8w79ms2yptc7c6p)) - Note: H1 — the governing rule: an AI audit produces a claim, not a vulnerability. Only a live proof-of-concept confirms it. This IS the maker/checker doctrine applied to vuln research. - Tags: atom/literature/h1 - The false positive rate drops off a cliff the moment you make Claude prove its own claims instead of asserting them from an audit. ([View Highlight](https://read.readwise.io/read/01kxts7dqr2y1nn6wfy4175yva)) - Note: H1 — the operational fix: source-reading asserts, running the exploit proves. Force the AI to stop reading and start running. - Tags: atom/literature/h1 - The value is not the bounty. The value is the coverage. ([View Highlight](https://read.readwise.io/read/01kxts7hnbs83avrpawvhw7qqx)) - Note: H2 — reframes success: most real bugs pay nothing but still need patching, so report them to the vendor anyway (step 4 of the pipeline). - Tags: aphorisms, atom/literature/h2 - You are auditing code, not websites. ([View Highlight](https://read.readwise.io/read/01kxts7fng1djewzsc7gv1nfy0)) - Note: H2 — the scaling insight: hash identical builds and audit each unique build once. This is what makes personal-scale coverage of the repository possible. - Tags: atom/literature/h2 - Every single plugin above 500,000 installs has been audited at its current version. ([View Highlight](https://read.readwise.io/read/01kxts7kqj2aby3w5zytn0m7wv)) - Note: H3 — the headline result from one solo operator (install-weighted: 2,050 of 5,000 raw, but 94.7% by active installs; 100% above 500k). - Tags: atom/literature/h3