fidzu : php

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

Open Source is usually described as a licensing model, a development model, or a production model. All three descriptions are useful, but they leave something out. Every Open Source ecosystem is also a cost-allocation system.

Keeping software relevant and dependable requires people to write code, review contributions, prepare releases, investigate security reports, operate infrastructure, write documentation, answer questions, and support upgrades and migrations. Someone always bears those costs.

A proprietary vendor can tie access to payment: every license or subscription sold helps fund developers, security work, infrastructure, and releases.

Open Source breaks the link between access and payment. Anyone can redistribute the software at any price, including zero. Payment is therefore not a condition of using or redistributing it, and those rights do not themselves provide a durable mechanism for funding production and maintenance.

But separating payment from access does not make the costs disappear. Costs are distributed across maintainers, employers, foundations, sponsors, and users. A maintainer may volunteer their time. An employer may pay a developer to contribute. A foundation may operate infrastructure.

Because these costs are distributed rather than collected through a single transaction, they are harder to see and harder to fund.

Technical choices often shape where those costs fall. That allocation is not always deliberate; it can emerge slowly from decisions that were individually reasonable and become visible only years later.

Drupal's update service recently gave me a good example. Drupal sites periodically contact updates.drupal.org to ask whether new versions of Drupal or any installed add-ons are available. Drupal calls these add-ons "contributed projects", such as modules and themes maintained by members of the community.

The current design sends one request for Drupal itself and one for every contributed project installed on the site. A site with 100 contributed projects therefore makes 101 requests each time it checks for updates, by default, once a day.

There were good reasons for that design. Each project's release history could be stored as a static file and served repeatedly without rebuilding it for every request. The design was straightforward, and it worked.

But Drupal grew. Today, updates.drupal.org serves nearly a billion requests a month. The file containing Drupal Core's release history is roughly half a megabyte by itself. Based on the number of requests for that file, I estimate that Drupal Core update checks alone may account for roughly 50 to 75 TB of data transfer each month. Traffic for contributed projects comes on top of that.

No one chose to make updates.drupal.org transfer tens of terabytes of release data each month. That scale emerged gradually as Drupal grew, from a design that had been reasonable when the ecosystem was smaller.

Part of the challenge is that, in Open Source, the people who benefit, the people who decide, and the people who bear the costs are often different and may have no formal obligations to one another.

Site owners benefit from reliable update notifications, usually without paying the Drupal Association for them. Drupal Association staff operate the update service, while the Association bears its traffic and infrastructure costs. But the code that determines how sites make those requests lives in Drupal Core, where changes require the involvement of Core committers. The Core committers do not report to the Drupal Association, so the Association cannot change that behavior on its own.

In practice, Drupal Association staff and Core committers collaborate closely. That collaboration is important because decision-making authority and cost-bearing sit with different groups.

The people bearing material costs need a way to make those costs visible and influence the decision, even if they do not control it.

This example shows why every Open Source architecture is also a cost-allocation system. Good governance considers that allocation up front, monitors its effects over time, and revisits it when it becomes unsustainable.

Understanding an Open Source system therefore requires more than understanding its code or license. We also need to understand who benefits, who decides, and who bears the costs as the system grows. Once those relationships are visible, a community can decide whether the allocation is sustainable or whether the architecture should change.

27 Aug 2026 7:21pm GMT

Six Small ECA Models That Make Drupal Editors Happy

Jürgen Haas Thu 27 Aug 2026 - 17:30

27 Aug 2026 3:30pm GMT

Reprise was introduced on this blog a few weeks ago, and the pitch has not changed: it is a thin plugin, not a build tool. Vite and Rsbuild do the real work (bundling, hashing, source maps, HMR, the dev server); Reprise only adds the Symfony glue they leave…

26 Aug 2026 2:41pm GMT

On August 17, we announced Symfony Language Tools, the official Symfony language server. Six days and ten releases later, version 0.16 is out. We have added a lot of features: the server now understands applications that look less like Symfony Demo and more…

23 Aug 2026 11:04am GMT

This week, Symfony 6.4.44, Symfony 7.4.17 and Symfony 8.1.5 maintenance versions were released. In addition, we introduced Symfony Language Tools, the official Symfony LSP server. Finally, we started experimenting with issue-first open source contributions.…

23 Aug 2026 7:54am GMT

Last week I helped the folks at ezSystems debug some APC problems they were having. The problems ended up being a 64bit architecture problem (they have uber-fast Opterons) and the bug is now fixed in 2.0.3.

Today I received Python & XML from them (off my Amazon wishlist). Thanks guys!

On a side note, my wishlist seems borked. The list I get when I search on my email address or name is not the same one I can edit when I log into the site.

01 Apr 2004 6:53pm GMT

1st of April 2004 get's to it's end and I guess it's time, to summarize the recent April fools a bit. Not that I think anyone in the world believes in them, but some were quite funny:

1. Changes to case sensitivity in PHP.
Alan Knowles announced that PHP will change to the studlyCase API and therefor will get everything broken by changing established functions.

2. IBM takes over Zend.
Myself hacked a little article about IBM taking over Zend to make PHP a compete of Java.

3. The first PHP virus has been seen.
Wasn't there one last year, too?

4. PHP has been overtaken by Micro$oft.
Mhhh... a little bit unreliable, if they had been taken over by IBM this morning... Maybe one should first look, what others wrote...

5. And finally, PHP4 and 5 showed their real faces...
Take a look at a phpinfo() output!

I guess I missed some, so feel free to comment on this entry, if you found another!

01 Apr 2004 5:49pm GMT

Symantec have a report of the virus here. I've yet to see any of the PHP news sites picking up on it but, using a virtual host account, managed to deliberately expose some PHP scripts to it. From examining the infected scripts, what's disturbing is once infected, every tim...

01 Apr 2004 12:19pm GMT