fidzu : cms

It's time to prepare your Drupal modules for Admin's dark mode mherchel Fri, 08/28/2026 - 12:04

28 Aug 2026 4:04pm GMT

WebMCP is an emerging proposal for cooperation between a web page and a browser agent. It is not a new name for MCP and it is not a replacement. A practical rule is simple: MCP belongs near servers and data; WebMCP belongs near the live page and the workflow the user can see. At the end of August 2026, WebMCP is not something every production website should rush into every form. But it is worth understanding now, because the direction is right: an AI agent should not have to guess buttons and click through a website like a brittle automation script. A web application can declare which actions an agent may use and what structured inputs those actions expect. That distinction matters. A normal browser agent sees a page roughly as a user or automation tool sees it: headings, form fields,…

28 Aug 2026 6:00am GMT

Today we are talking about Security, Vulnerabilities, and how to avoid exposure with guest Dave Welch. We'll also cover Security Scanner as our module of the week.

For show notes visit: https://www.talkingDrupal.com/567

Topics

• What Are CVEs
• CVE Lifecycle and Disclosure
• AI Era Security Challenges
• What CVE Program Excludes
• Patch Fast Reality
• Global Security Signals
• CVE Timing Judgment
• KEV Flags Explained
• CVE Updates Link Rot
• Who Decides CVE
• Sneaky Patch Dangers
• ADP Program Fixes
• Small Team Triage
• Vulnerability Tsunami AI
• Autonomous Security Future
• Legal Pressure Budgets

Resources

• Psalm PHP Static Analysis Tool
• SARIF format
• PHP ecosystem
• Council of roots
• How AI Broke Open Source Security: End-of-Life Software Is the Most Exposed
• CVE podcast
• Vulncon
• PSIRT

Guests

David Welch - github: dwelch2344 dwelch2344

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi JD Flynn - dorficus

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted a fast way to catch the security mistakes that slip into custom Drupal code - especially the code your AI assistant just wrote - before it ships? There's a module for that.
• Module name/project name:
  • Security Scanner
• Brief history
  • How old: created in July 2026 by Mayank Gupta (mayankguptadotcom) of Acquia
  • Versions available: 1.0.0, which works with Drupal 10.3 and 11
• Maintainership
  • Actively maintained - created and shipped its first stable this summer, with steady development right through late July
  • Security coverage
  • Test coverage - and it's strong: unit and kernel tests, including a regression corpus built from real Drupal core advisories
  • Documentation? In-depth README with a full check table and CI recipes, plus a CHANGELOG
  • Number of open issues: 1 issue, not a bug
• Usage stats:
  • 2 sites (it's brand new)
• Module features and usage
  • Provide a Drush command, has no UI - you point drush security:scan at a module or any path, it reads the code statically, and prints a prioritized, OWASP-mapped list of things to review
  • It's built for the age of AI-written code - the checks target the classes AI assistants keep reintroducing: routes with no access check, #markup and |raw XSS, missing CSRF tokens, unserialize() on untrusted data, hardcoded secrets
  • Then there's an optional deep pass: with the Psalm static analysis scanning engine installed, it'll trace untrusted input across functions and files to catch cross-function issues. And it's honest about state - the report always says whether that deep pass ran, was skipped, or failed, so a failure never gets mistaken for a clean scan
  • One nice detail under the hood: a tokenizer-backed "code map" that knows whether a match is real code, a comment, or a string - so it won't flag the word "unserialize" sitting in a doc comment. That kills the single biggest source of false positives
  • The checks are regression-tested against real Drupal advisories (Drupalgeddon, Drupalgeddon2, the 2019 unserialize bug, etc) so a pattern that caused an actual CVE can't quietly come back in your custom code
  • Output comes in three flavors: a readable table, JSON for CI and AI agents, and SARIF - which means findings show up as annotations right on your GitHub or GitLab merge-request diff instead of buried in a job log
  • For adopting it on an existing codebase there's a baseline file - you fingerprint the findings you've reviewed, with a required reason on each, and they stop failing the build but never go invisible; every run still counts them
  • It exits non-zero on error-level findings, so it drops straight into CI or a pre-commit hook
  • And it's extensible - checks are Drupal plugins with a #[SecurityCheck] attribute, so any module can add its own or alter the ones that ship
  • Big caveat, and the module says this itself: a finding means "review this," not "this is broken." Static analysis has false positives, and a clean scan doesn't prove the code is secure - access-control logic especially still needs human review
  • I first heard about this module over beverages at Drupalcamp Asheville, so I know that this module was largely vibe-coded, after having an AI agent ingest every single Drupal security team CVE. So I like to think of this module as security pattern recognition tool, but of course it does even more

27 Aug 2026 8:00pm GMT