The Core Security Initiative  🔗 **Source:** [The Core Security Initiative](https://make.wordpress.org/security/2026/08/28/the-core-security-initiative/) > [!note]+ Document Notes > title: The Core Security Initiative > author: Rudy Faile (@rfaile313), WordPress Security Team > source: https://make.wordpress.org/security/2026/08/28/the-core-security-initiative/ > published: 2026-08-28 > type: literature > tags: [wordpress-security, ai-security-research, vulnerability-disclosure, open-source-governance, volunteer-labor, security-backlog, hackerone, wordpress-core] > > > [!info] Deep read — processed 2026-08-28 > > Source: make.wordpress.org/security, 12:52 pm ET 2026-08-28. 434 words including comments. > > Reader's own capture dropped the comment thread; this doc was rebuilt from source so the > > anchored comment (#70) is present. Site generator reports WordPress 7.2-alpha-63393. > > Primary source behind the "Core Security Initiative" item in the 2026-08-30 WP Trend Watcher. > <!-- deep-read:sections start --> ## 📝 Summary WordPress's security team announces a coordinated program — the Core Security Initiative — in response to what it calls a "substantial increase in the volume of incoming security reports" over the past year. The post attributes that increase directly to "the rapid advancement of frontier AI models and their growing capability to assist with security research." The response is organized as three pillars fitted to an **ABC** mnemonic: **A** better release process (more automation, better end-to-end testing, scheduled security releases); **B**reaking the backlog (more team members and volunteers, "with the aim of driving open findings down to zero"); **C**rush vulnerabilities with AI (AI-assisted scanning to find vulnerabilities proactively). The post carries no numbers. Not the report volume, not the backlog size, not the team headcount, not a target date. Every quantity in it is an adjective. ## 📖 Main Content **The admission is the news.** The WordPress project is saying, in its own words, on its own blog, that AI-assisted security research has changed its intake rate enough to require restructuring how the project operates. That is the same claim vendors have been making in sponsored framing all year — and it is much harder to dismiss coming from the maintainers who receive the reports. **The three pillars, as written:** | Pillar | Stated action | What it actually requires | |---|---|---| | **A** better release process | "tighter, more automated security release process, with improved end-to-end testing" | CI investment; the post notes releases are now being *scheduled* as a result | | **B**reaking the backlog | "more team members and volunteers… driving open findings down to zero" | Human triage capacity, unfunded except via sponsorship | | **C**rush vulnerabilities with AI | "AI-assisted scanning and tooling to find vulnerabilities before they can be exploited" | Tooling budget; *and it raises intake* | **Pillars B and C point in opposite directions, and the post does not acknowledge it.** B commits to driving open findings to zero. C commits to generating more findings — deliberately, proactively, at machine scale. You cannot converge a queue to zero while simultaneously adding a new high-throughput producer to it, unless remediation throughput grows faster than the scanner's discovery rate. Nothing in the post claims that it will. This is not a gotcha. It is the actual operational question: **what is the steady-state?** If AI scanning works, the backlog's floor is set by remediation capacity, not by discovery. "Zero" is then a category error — you would be measuring the wrong thing. A healthier target would be time-to-remediate at a given severity, which is a rate, not a count, and which does not get worse just because you got better at looking. **The ABC mnemonic is doing visible work on the naming.** "Crush vulnerabilities with AI" is a strained phrase; it exists because the framework needed a C. That matters slightly more than it sounds: a communications device shaped the taxonomy, which means the three pillars are a presentation of the work rather than a decomposition of it. There is no pillar for the thing the comments immediately asked about — hardening defaults for site owners. **"Report quality matters more than ever at this volume"** is the post's one direct ask of readers, and it is a cost transfer. Triage cost per report is roughly fixed; the project cannot lower it, so it asks reporters to lower it for them by submitting better reports. This is reasonable, and it is also unenforceable — the reporters generating the volume increase are precisely the ones using automated tooling, and automated tooling is what produces low-context reports. **On the comments.** - **#70 — John Blackbourn (@johnbillion), 1:00 pm, eight minutes after publication:** the entire comment is `+make.wordpress.org/core/`. This is o2 cross-post notation, a request to mirror the announcement to the Core blog. It carries no position, no critique, no endorsement. Its only informational content is that a longtime core security contributor thought the audience was too narrow — the security blog's readership is people already in security; core's is everyone who builds on WordPress. - **#71 — Torsten Landsiedel (@zodiac1978), next morning:** the substantive one. Proposes a **security feature plugin** on the model the performance and AI teams already use — explicitly *not* a full security suite, but "low-hanging fruits. Hardening recommendations. Integrity checks. Warning on abandoned/closed plugins." Landsiedel's third item is the one with teeth. **A warning on abandoned or closed plugins addresses the failure mode the initiative's three pillars don't touch.** All three pillars are about core. The overwhelming majority of exploited WordPress vulnerabilities are not in core — they are in plugins, frequently in plugins that no longer have a maintainer. A perfectly executed A-B-C leaves that exposure exactly where it was. That is a structural comment on the initiative's scope, offered by a contributor, sitting one comment below a cross-post request. ## 🗒️ Notes - Timing: posted 2026-08-28, following a security team meeting at WordCamp US "last week." - The previous post on this blog is "Hardening GitHub Actions workflows across the WordPress organisation" (2026-07-13) — supply-chain hardening of the project's own CI. Reads as the same program of work, one month earlier, without the branding. - "Contributors sponsored by companies across the WordPress ecosystem" is the funding model, stated in one clause. It is the load-bearing sentence for pillar B and it names no companies and no commitments. - HackerOne remains the intake channel: hackerone.com/wordpress. - `generator: WordPress 7.2-alpha-63393` — make.wordpress.org runs trunk. ## 📚 References - Post: https://make.wordpress.org/security/2026/08/28/the-core-security-initiative/ - Intake channel: https://hackerone.com/wordpress - Landsiedel's linked thread: https://x.com/zodiac1978/status/2093292207197368631 - Prior post: "Hardening GitHub Actions workflows across the WordPress organisation" (2026-07-13) - Downstream coverage: WP Trend Watcher 2026-08-30 ## 🗣️ Paraphrase AI made finding WordPress bugs easy, so many more are being reported than before. The security team's answer has three parts: ship fixes faster and more predictably, recruit enough people to clear the pile of open reports, and use AI to find bugs proactively instead of waiting for reports. The second and third parts work against each other — one wants the pile empty, the other adds to it. Nobody in the post says so. ## 📰 Newsletter WordPress's security team just said out loud what the rest of the industry has been circling: frontier AI models have changed how many vulnerability reports arrive, and the project has to restructure to absorb them. The announcement offers three pillars under an ABC mnemonic — better releases, break the backlog, crush vulns with AI. Read pillars B and C next to each other. B promises to drive open findings to zero. C promises to add an automated finding-generator. Those cannot both converge unless remediation outruns discovery, and the post makes no such claim. The honest metric here is time-to-remediate, not count-at-zero — a rate you can hold steady, rather than a number that AI scanning guarantees you will miss. Worth noting what's *not* in the three pillars: anything about the plugin ecosystem, where most exploited WordPress vulnerabilities actually live. A commenter had to raise it — Torsten Landsiedel proposing a security feature plugin with "warning on abandoned/closed plugins" among the low-hanging fruit. That single line targets more real-world exposure than the initiative's core-focused pillars do. ## ✅ Action Items - [ ] Track whether the promised "scheduled upcoming security releases" actually publish on a stated cadence — this is the only pillar with a falsifiable claim. - [ ] Watch whether Landsiedel's feature-plugin proposal gets a response from the team, or dies in the comment thread. - [ ] Note the absence of numbers; if a follow-up post supplies backlog size or intake rate, that's the datapoint worth capturing. - [ ] Check whether the post got cross-posted to make.wordpress.org/core per Blackbourn's request — a proxy for how seriously the team treats audience reach. - [ ] Connect to the abandoned-plugin exposure thread already in the vault. ## 🧪 Hypotheses 1. **"Zero open findings" will not be achieved and will quietly stop being cited.** Goals stated without a baseline or date are usually rhetorical. Falsifiable: watch for it in the next initiative update. 2. **Pillar C will land before pillar B.** Tooling is purchasable; volunteer triage capacity is not. Expect AI scanning news before backlog-cleared news. 3. **The plugin-ecosystem gap will be addressed separately, if at all.** The initiative is scoped to core; the exposure is not. 4. **Sponsorship concentration is the real constraint on B.** "Contributors sponsored by companies" means a small number of employers decide how much triage capacity exists. ## 📊 Methodology An announcement post, not a study. No data collection, no measurement, no methodology to assess. The evidentiary basis for its central causal claim — frontier AI models caused the report increase — is the security team's direct observation of its own intake queue. That is good evidence for the correlation and reasonable evidence for the cause, but it is unquantified and unshown. The analysis above rests on reading the post's own text against itself (the B/C tension) rather than on outside data. ## ❓ Questions - How many open findings are there? The word "backlog" appears in a pillar name with no number attached. - What was the intake volume before and after? "Substantial increase" is the entire quantification. - What counts as a "finding" for the zero target — reports received, validated vulnerabilities, or unpatched validated vulnerabilities? These differ by orders of magnitude. - Who is funding this? "Companies across the WordPress ecosystem" names nobody. - What AI tooling, run by whom, on what code, with what disclosure path for its output? - Does the AI scanner's output enter the same HackerOne queue, or a separate track? This determines whether C makes B harder or is accounted separately. - Is anything in this initiative scoped beyond core? ## 🔮 Future Research - Compare against how other large open-source projects absorbed the same AI-driven intake shift — curl's Daniel Stenberg has published hard numbers on AI-generated report volume and quality; that is the natural comparison and it has data where this post has adjectives. - Track the WordPress security release cadence for the next two quarters against the "scheduled releases" claim. - Map exploited-in-the-wild WordPress CVEs by component (core vs plugin vs theme) to size the gap the initiative doesn't cover. - Watch whether AI-assisted scanning findings get disclosed differently than human-reported ones. ## 💡 Implications **For the project:** stating the AI-intake problem publicly is the prerequisite to resourcing it. This post is a fundraising and recruiting document as much as an announcement, and it should be read as one. **For site owners:** nothing here changes your exposure this quarter. All three pillars are upstream of you and none touch the plugin surface where you are actually attacked. Landsiedel's comment is more actionable than the post. **For security researchers:** the "report quality matters more than ever" line is a real signal. Volume is now a cost to the project, and low-quality automated submissions are being felt. The reputational math on spraying tool output at HackerOne just got worse. **For the broader ecosystem question:** WordPress is a bellwether because of its size. If the largest CMS project is restructuring around AI-driven disclosure volume, smaller projects with thinner maintainer benches face the same shift without the sponsorship base to answer it. The asymmetry is not "AI finds bugs faster than humans fix them" in general — it is that discovery scales with compute and remediation scales with people. ## 🧠 Learning Styles Assessment Text-only, ~400 words, no diagrams or data. The ABC mnemonic is a genuine aid for verbal/auditory retention and is presumably why it exists — it makes the initiative repeatable in conversation at a WordCamp. That same device costs precision, as the strained "Crush vulnerabilities with AI" shows. Readers who reason from numbers get nothing to work with. Readers who need concrete examples get none. ## 📊 Accessibility Assessment Short, plain-language, clear heading structure, well within reach for non-native English readers and screen-reader navigation. No images, so no alt-text burden or failure. Jargon is minimal and the one acronym-heavy element (ABC) is expanded inline. Anchor links to comments work. The main accessibility criticism is cognitive rather than technical: the post asks readers to accept a causal claim and a program without supplying anything to evaluate either against. ## 🌍 DEIB Assessment The labor model is the DEIB story. Pillar B scales through "more team members and volunteers" plus "contributors sponsored by companies." That splits security triage capacity between people paid by employers to contribute and people donating unpaid time — and the sponsored contributors are concentrated in a small number of well-resourced companies, disproportionately North American and European. Unpaid security triage is time-expensive, high-stress, and invisible; it selects for people who already have slack in their lives. The post asks for volunteers without acknowledging that ask has a distribution. A security backlog cleared by volunteers is cleared by whoever can afford to volunteer, and the resulting team composition then shapes which reports get prioritized. Nothing here is malicious; it is an unexamined default that the post could have named and didn't. ## ✅ Logical Validity **The causal claim** (frontier AI → more reports) is well-supported by the authors' position, though unquantified. Accept provisionally. **The main inference** (more reports → need to scale triage/validate/resolve) is valid and follows. **The internal contradiction:** the argument commits to driving open findings to zero (B) while committing to increase finding generation (C). This is not a formal contradiction — it is satisfiable if remediation rate exceeds combined discovery rate — but the post asserts the goal without asserting the condition that would make it reachable. That is an unsupported step, and it is the load-bearing one for pillar B's headline claim. **Unstated premise:** that volunteer and sponsored capacity can be recruited in proportion to the intake increase. Nothing supports this and the project's own history with under-resourced teams argues against it. **"This is a good problem to have"** is a rhetorical move, not an argument. It reframes a resourcing crisis as a success indicator. It may be true; it is asserted, not shown. **Scope substitution:** the post presents itself as addressing WordPress security. It addresses WordPress *core* security. The words "plugin" and "theme" do not appear. Readers will generalize; the post does not correct them. ## 🛡️ DARVO Analysis **No DARVO present.** This is a straightforward institutional announcement with no accusation to deflect, no attacked party, and no reversal of victim and offender. The project is describing its own operational pressure and asking for help. The nearest thing to a rhetorical defense is "This is a good problem to have" — a reframe that converts a backlog into evidence of health. That is ordinary institutional positive framing, not DARVO. Worth naming so the pattern-match is explicit and the finding is a real negative rather than an unexamined one. ## 🎯 Conclusion The valuable content is the admission: WordPress's security team publicly attributes a substantial rise in incoming vulnerability reports to frontier AI models, and is restructuring around it. Coming from maintainers rather than vendors, that lands. The plan itself is a communications artifact more than an operating plan — three pillars fitted to a mnemonic, zero numbers, and an internal tension between clearing the backlog and adding an automated producer to it that the post never addresses. The honest version of pillar B is a remediation-rate target, not a count-to-zero. And the initiative is scoped to core while the ecosystem's actual exposure sits in unmaintained plugins. It took a commenter to say so. Of the two comments on the post, the one anchored in the link is a bare cross-post request; the one below it proposes the missing piece. --- ## Refactor Appendix **Note type:** Literature note — a primary-source announcement with enough analytical surface to support permanent claims. **Permanent note candidates:** ### A backlog target of zero is incoherent when discovery is being automated > [!quote] "Bringing on more team members and volunteers to work through the queue of open reports and known issues, with the aim of driving open findings down to zero." + "Applying AI-assisted scanning and tooling to find vulnerabilities before they can be exploited" Zero is a count; automated discovery makes the count a function of scanner throughput rather than of code quality. The measurable commitment is time-to-remediate at severity — a rate, which does not degrade because you improved at looking. <!-- atomicity: 1 idea ✓ --> ### A mnemonic that shapes a taxonomy has stopped describing the work > [!quote] "It focuses a coordinated effort under three pillars: ABC." / "Crush vulnerabilities with AI" When the naming strains to fit the device, the categories are a presentation of the work rather than a decomposition of it — and the test is what falls outside: here, the entire plugin ecosystem. <!-- atomicity: 1 idea ✓ --> ### Asking for better reports transfers triage cost to the people generating the volume > [!quote] "please review the reporting guidelines before submitting, as report quality matters more than ever at this volume" Per-report triage cost is near-fixed for the receiver, so the only available lever is the sender — but the senders driving volume are using automation, and automation is what produces low-context reports. The ask is reasonable and structurally unenforceable. <!-- atomicity: 1 idea ✓ --> ### Discovery scales with compute and remediation scales with people > [!quote] "Much of this growth reflects the rapid advancement of frontier AI models and their growing capability to assist with security research" The asymmetry isn't that AI is smarter than maintainers; it's that one side of the ledger buys throughput with money and the other buys it with human attention. Projects without a sponsorship base face the same intake shift with no answer available. <!-- atomicity: 1 idea ✓ --> **Links to existing vault notes:** - [[Exfiltration Needs Three Capabilities Together Not Any One of Them]] — contrasts; both are about decomposing a security claim into its actual mechanism rather than its headline - [[A Capability Demonstration Is Not an Operating Model]] — extends; three pillars announced is a demonstration, a shipped cadence is an operating model - [[Compressing Access Time Hides Friction Rather Than Removing It]] — applies-in; faster releases don't reduce the work, they relocate when it's felt **Template Library:** Announcement/institutional-post variant — heavy on Logical Validity (the internal tension is the finding), light on Methodology (there is none to assess). DARVO recorded as a clean negative rather than skipped. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/The Core Security Initiative.md|The Core Security Initiative by Rudy Faile, WordPress Security Team]] ## Highlights - Much of this growth reflects the rapid advancement of frontier AI models and their growing capability to assist with security research ([View Highlight](https://read.readwise.io/read/01m19py74gy6eywd9r0b84sk3g)) - Note: The project attributing its own intake surge to frontier models — from the maintainers who receive the reports, not from a vendor selling a fix. Harder to dismiss than the same claim in sponsored framing. - Tags: ai-security-research, primary-source - This is a good problem to have: more eyes on WordPress makes WordPress safer ([View Highlight](https://read.readwise.io/read/01m19pym3x8kc938q6c582jz3n)) - Note: Institutional reframe: a resourcing crisis presented as an indicator of health. Not DARVO — no accused party, no reversal — but it is a rhetorical move rather than an argument. It may be true; it is asserted, not shown. - Tags: rhetoric - with the aim of driving open findings down to zero ([View Highlight](https://read.readwise.io/read/01m19py9n51wzn182sx0rc6rpa)) - Note: Pillar B. Read against pillar C below: you cannot converge a queue to zero while deliberately adding an automated producer to it, unless remediation outruns discovery. The post never claims it will. The honest metric is time-to-remediate — a rate, not a count. - Tags: internal-tension, security-backlog - Applying AI-assisted scanning and tooling to find vulnerabilities before they can be exploited, complementing the reports received through responsible disclosure. ([View Highlight](https://read.readwise.io/read/01m19pyc6vyacfj29kheyake0v)) - Note: Pillar C, the other half of the contradiction. Also the pillar whose name is visibly bent to fit the ABC mnemonic — "Crush vulnerabilities with AI" exists because the framework needed a C. A communications device shaped the taxonomy. - Tags: internal-tension, ai-security-research - report quality matters more than ever at this volume ([View Highlight](https://read.readwise.io/read/01m19pyf0eef3ekajwz1rgdzpw)) - Note: A cost transfer. Per-report triage cost is near-fixed for the receiver, so the only lever is the sender — but the senders driving volume are using automation, and automation is what produces low-context reports. Reasonable ask, structurally unenforceable. - Tags: vulnerability-disclosure - but some low-hanging fruits. Hardening recommendations. Integrity checks. Warning on abandoned/closed plugins. ([View Highlight](https://read.readwise.io/read/01m19pyhjcf5bfkhazthzpdqpk)) - Note: Comment #71, Landsiedel. The substantive comment on the post, and the only place the plugin ecosystem gets named. "Warning on abandoned/closed plugins" targets more real-world exposure than the three core-scoped pillars do. Vindicated within 24 hours by the 2026-08-29 five-CVE batch. - Tags: scope-gap, plugin-ecosystem