28 Oct 2026
Drupal.org aggregator
Stuart Clark (Deciphered): Vale 1.0.0; prose linting for Drupal
Drupal is 25 this year, and its code has had linters for a long time. Its words haven't, and with Drupal AI writing straight into the node form, more of them now come from a model. A search of drupal.org turns up readability scores and spellcheckers, but nothing that holds a save to your own style guide.
Vale (for Drupal) does that with the Vale prose linter. Break an error-level rule and the save is refused, or only the publish if drafts should save freely. 1.0.0 is out now for Drupal 10.3, 11 and 12, and needs the Vale binary on your server.
Vale in CI is the right tool for Markdown in a repository. Content in Drupal arrives through a save instead: the node form, a Fully Decoupled frontend over JSON:API, a workspace being published. The module checks there, on the server, whatever editor the author used.
28 Oct 2026 5:20am GMT
Drupal Association blog: In the Open with Tiffany Farriss: What it takes to sustain the Drupal commons
In the Open is a weekly series from Drupal Association Interim CEO Tiffany Farriss, sharing what she is hearing across the Drupal community and where the Association is headed. In this episode: why Drupal's commons is under pressure, how the Drupal Certified Partner program is evolving, and what it takes to keep free software running for the next 25 years.
"Drupal is free. The code of Drupal is free forever. But those of us who run Drupal know that running Drupal has never been free."
The following is a transcript of Tiffany's remarks, lightly edited for readability.
What I'm hearing from the community
The thing that's top of mind for me this week is reflection. I've spent a lot of time listening to folks, talking to folks, asking a lot of questions. I wanted to take a few minutes to share back some of the things I'm hearing, because these are the things motivating the changes in how I'm thinking about existing programs, and about how we might want to do things differently for the next 25 years of Drupal.
Whether it was the ecosystem survey, the business community survey, or conversations with the core release maintainers and other parts of the community, it's very clear to me that our commons is fragile. The technology of Drupal itself is a brick. It is solid. We are super proud of our security team. But the people and the funding sustaining it aren't yet in a sustainable place, and there's a lot of pressure.
That pressure is echoed in the business community. The businesses that have been very supportive of Drupal through the years, and I'm thinking not just of those 126 Drupal Certified Partners but of all of us, everyone is getting squeezed. The business survey data showed that the average deal size was down, and that pipeline expectations had gone negative for the first time in the Drupal business survey.
That creates a real impetus for us to make sure that people who aren't in our community are hearing about Drupal, because right now we don't think they are. We think the visibility and the curb appeal of Drupal is weak. It was one of the weakest scores in the business survey. And yet where Drupal is already in the mix, it continues to do really well. This is where you see our advocacy program trying to address this: getting the word out to people who may have a very dated view of Drupal, who haven't looked at us in a while. Because when people actually know Drupal, we succeed.
Rethinking the Drupal Certified Partner program
I take all that feedback, and I've been thinking a lot about the Drupal Certified Partner program. One thing that stood out in conversations across the ecosystem is that calling it the Drupal Certified Partner program has created misimpressions that aren't serving us well. It lets some folks opt out: "Oh, that's not really for me, that's just for small agencies, just for the folks who are already there, who are already contributing." That's not true. It also creates the idea that we're some sort of trade association, and we're not. We're a 501(c)(3). We are a not-for-profit with a charitable and educational mission around the Drupal project itself, which has been recognised as a digital public good. So we need to reinvent what that message is and how we address it.
Free code was never free to run
There are things that always have to be true. Drupal is free. The code of Drupal is free forever. But those of us who run Drupal know that running Drupal has never been free. It requires security coordination. It requires testing and packaging and releases, and those cost real time and money. A small group has paid for that for a really long time, and I think this is the time when the wider world is waking up and realising that's not such a good idea.
Last week's security incident with PHP brought a lot of light to that. The PHP Foundation has one full-time staff person, my equivalent, Elizabeth Barron. She's amazing. But just one person, and 70% of the internet runs on that. She has twelve people she's able to fund part-time to do security and maintenance work on PHP. So I'm hopeful that the broader conversation about what it takes, about this open source technology that everyone depends on, that's in everything and everywhere, creates an opportunity for us to have that conversation.
What every Drupal site receives
A lot of what I've done is extend the work I did a few years ago on what the Drupal Association itself puts into supporting Drupal. It's about $10 a year per site, and $7.50 of that we're actually able to raise. Then when we consider the things that aren't scratching your own itch, like core release management or the security work, things done by the community, I think the community itself puts in another $30 a year. So every year, every site receives $40 of services that are simply donated to it.
And when we come back to that volunteer time, those 126 companies who are Drupal Certified are shouldering that burden today. That isn't fair to them, and it's not safe for Drupal.
Making contribution visible, expected, and recognised
What I want to do is make it easy and expected for everybody in the ecosystem, everyone who receives value from Drupal, everyone who uses it, to understand what it means to be a net neutral citizen of Drupal, and to give that back easily in ways that are appropriate. We have asked people to give back for a long time. That's gotten us here, but I don't think it gets us where we need to go. The next step is to make that contribution visible, expected, and recognised.
That's how I'm thinking about the Drupal Certified Partner program becoming the Drupal Certified program. What we can do is be a certified trust registry. What does the Drupal Association uniquely have to offer? We can reflect how you're giving: in what ways you are a maker, in what ways you are a patron, in what ways you are an advocate. And we can calibrate those so they're appropriate to the sector you're in and the ways you would naturally want to contribute to Drupal.
Certified organisations will be those who agree to a set of shared good practices: contributing fixes upstream, responding to our security team, tending the issue queues you maintain, and keeping sites current. Any organisation with a developer can meet those maintenance commitments in-house. And if not, we're going to set up a maintainers fund. Drupal has a lot of maintainers who would appreciate a little support, so if your organisation has modules you maintain, or that you need maintained, we can be a conduit for that. We can help you be a good Drupal citizen.
What will always be true
Drupal is GPL, and Drupal is always going to be free for everyone. Security patches and advisories will be available to everyone. No one can pay for that. You can join the security team, and I really encourage people to do that, because we know the volume of security issues is up tremendously. AI is both the culprit and the solution to that.
What you'll start to see over the next six months is a real evolution in how we take that responsibility as a public ledger very seriously, and make sure it's clear to people both inside and outside our community how you're engaging with this ecosystem. So that we can continue to have a really nice commons, a digital one at that, for the next 25 years.
Follow the conversation
New episodes of In the Open publish each week. Subscribe on the Drupal Association YouTube channel to follow along.
With thanks to Stephen Cross of Second Signal Media for producing this series.
28 Oct 2026 12:38am GMT
27 Oct 2026
Drupal.org aggregator
Aten Design Group: Supply Chain Security for Drupal Projects
Supply Chain Security for Drupal Projects admin Drupal Security
A developer needs a fix from a contrib module, so they open a terminal inside DDEV and run composer update. The container can reach an SSH agent and a hosting token. Composer downloads a few packages and writes a new lock file.
Nothing about that looks unusual. That is the problem.
The recent wave of supply chain attacks did not exploit Drupal. It exploited the moment a developer or a build changes dependencies with credentials in reach. The Drupal Security Team has been clear about the boundary. Its remit is code hosted on Drupal.org, and site owners are responsible for third-party libraries.
The rest of the dependency tree is ours.
We develop locally in DDEV and use Dependabot in GitHub for update pull requests. Here is how we think about protecting a Composer-based Drupal project.
The risk arrives when dependencies change
These attacks arrive with a dependency change, and a Drupal project gives them three places to run.
The first is Composer plugins. In April 2026, an attacker moved an existing intercom/intercom-php tag to a malicious commit. The malicious commit turned the library into a Composer plugin that stole credentials during install.
The second is autoload.files. In May 2026, attackers rewrote historical tags on four laravel-lang packages. The payload was registered in autoload.files, so it ran on every PHP request.
The third is npm lifecycle scripts. The Shai-Hulud worm spread through npm install scripts and the npm tokens it stole. A later campaign hid a postinstall hook in the package.json of PHP packages, aimed at projects that also run JavaScript tooling. Many Drupal themes run npm tooling, so the theme's package.json belongs in the same review.
Each vector needs its own control.
Allow plugins by name and treat the lock file as code
Commit composer.lock, and have builds and deploys run composer install rather than composer update. An install reproduces the commits already recorded in the lock file. The same behavior protected laravel-lang users whose lock files predated the attack.
Keep drupal/core-recommended as the core requirement, because it pins core's own dependencies tightly.
A common piece of generic advice is to install with --no-plugins, but on Drupal that breaks the build. Both composer/installers and the core scaffold plugin are Composer plugins. Without them, modules do not land in web/modules/contrib and scaffold files are never placed.
The control that fits Drupal is allow-plugins. By default it allows no plugins, and the drupal/recommended-project template already ships a short list of named packages. Keep that list explicit, and never set it to true.
Then review lock file diffs as carefully as code. Three changes deserve a second look:
- a package whose
typebecomescomposer-plugin - a new plugin appearing at all
- a changed source reference on an unchanged version number
An unexpected plugin prompt is a code review event, not a formality.
Let Composer and npm block what they already know is bad
Newer package managers now do much of this work by default. Composer 2.9 blocks updates to versions with known security advisories. Composer 2.10 adds malware blocking that also applies to composer install, so a malicious version that slipped into a lock file fails the next build instead of installing quietly.
That malware data comes from a Packagist.org feed, so it covers core and its dependencies but not contrib from packages.drupal.org.
Versions with advisories can still be installed from an existing lock file, though. The audit therefore belongs in the build:
composer install --no-dev --no-interaction --no-progress composer audit --locked
Drupal advisories reach composer audit because packages.drupal.org publishes advisory data for the projects it hosts. When an advisory does not apply to a site, record an exception with a reason in Composer's policy configuration instead of removing the audit step.
That also retires two older tools. Drush 12.3.0 removed pm:security in favor of composer audit, and Composer's built-in blocking replaces roave/security-advisories.
On the theme side, npm 12 blocks dependency lifecycle scripts unless the root package explicitly allows them. Treat that allowScripts list like allow-plugins, and install with npm ci against a committed package-lock.json.
Teams that want a review step on every dependency change can watch Laravel Vet. Despite the name, it works with any Composer project. It is still in beta and requires PHP 8.4, and we have not tested it with Drupal.
Wait a week, except for security releases
We recommend a 7-day waiting period for routine Composer and npm updates, with security releases exempt and applied the same day.
The timing supports it. The malicious intercom-php tag was live for under two hours, and Packagist says malicious versions are typically pulled or detected within hours. The first Shai-Hulud worm kept publishing new malicious versions for about two days in September 2025, so a week leaves margin. For a long-lived Drupal site, a week of delay on routine updates costs little.
The exemption matters just as much.
Drupal shipped core security releases rated highly critical in May 2026 and critical in October 2026. Both times, the Security Team warned that exploits might be developed within hours or days. A waiting period must never delay those updates.
For Composer packages from Packagist.org, Dependabot already waits 3 days by default. In dependabot.yml, a 7-day cooldown looks like this:
version: 2 updates: - package-ecosystem: "composer" directory: "/" schedule: interval: "weekly" cooldown: default-days: 7
The cooldown applies only to version updates, never to security updates. That exemption only helps when Dependabot recognizes the advisory. GitHub's reviewed advisories cover Drupal core, often late, but not contrib modules from packages.drupal.org.
Contrib security releases therefore arrive as ordinary version updates. The cooldown does not hold them back either. Dependabot's code reads release dates from a field that packages.drupal.org does not publish, so the 7-day window covers core and other Packagist.org packages, not contrib.
Contrib needs a manual path. Watch the Drupal security advisories and apply those releases directly, and check release dates on routine contrib updates.
The package managers can enforce the same window. npm 11.10 added min-release-age, so min-release-age=7 in the theme's .npmrc sets that window for npm.
Composer's native cooldown is merged but unreleased, and it is planned for Composer 2.11 as policy.cooldown.period set to "7 days". Its documentation measures age from published-time, which packages.drupal.org publishes, so it should cover contrib too. Neither npm nor Composer recognizes security fixes, so urgent fixes need a per-package exemption.
Install-time code can read whatever is in reach
Assume anything running composer update or npm install can read everything in that environment. The payloads above went looking for cloud credentials, .env files, SSH keys, and CI secrets.
Run npm inside the DDEV container rather than on the host, so a script sees the container and not a developer's home directory. Then review what the container and the build runner can actually see, including forwarded SSH agents, hosting tokens, and local settings files with real credentials.
Keep long-lived credentials out of jobs that change dependencies, and give build tokens the narrowest permissions the job needs. Shai-Hulud used the GitHub tokens it found to push workflows into every repository it could reach.
Finally, protect the accounts that publish code. Anyone who maintains packages should turn on two-factor authentication for Drupal.org, GitHub, Packagist, and npm.
Supply chain security is a maintenance habit
None of these controls is exotic. Commit the lock file and install from it. Allow plugins by name, and gate builds on composer audit. Wait a week for routine releases, and apply security releases the same day. Keep credentials away from the moment dependencies change.
Supply chain security is not a scanner we add to a project once. It is how we treat every dependency change.
27 Oct 2026 8:38pm GMT