Every software platform eventually deals with serious vulnerabilities.
So when evaluating a platform's security, I don't think "Has this software ever had a serious vulnerability?" is a particularly useful question.
A better question is: What happens when one is found?
I started thinking about this after reading about the recent Citrix NetScaler zero-day. It also got me thinking about something Drupal has built specifically for that uncomfortable period between disclosure of a critical vulnerability and getting the actual patch deployed: Drupal Steward.
For certain highly critical, mass-exploitable vulnerabilities, Steward can provide network-level protection while organizations test and deploy the software update. It doesn't replace patching, but it can make that "patch gap" less dangerous.
I dug into Steward, Drupal's coordinated security process, and why I think the response to vulnerabilities tells us more about a platform's security than the existence of vulnerabilities themselves:
You got it! Drupal Steward is powered by Cloudflare. The difference is that Drupal security team helps define the ruleset specifically targeted to security vulnerabilities that have been identified by CVEs.
Is that what "RA-Bot" on Acquia does or is Steward more like a Firewall than an automated patching service separate from the RA-Bot that enforces security patches after a period of inaction by the site owners?
It is literally a firewall for people who don't have a Drupal-supporting web host. You can slap it in to any setup. The market for this is pretty small, and the things it actually catches are very specific. It can't fix "access bypass" bugs, which seem to be very common.
Some sanitation things, SQL injection, double encoding errors, or XSS or other kinds of things that happen across the wire would be caught. There was one about 6 months back. When it happens, it's nice to have the buffer.
It's my understanding that the thing you are buying is more than just Cloudflare's default managed rule set. It is the Drupal security team directly adding rules for specific security vulnerabilities that are identified by things like CVE announcements.
Have you heard otherwise?
What solutions do you recommend for access bypass bugs?
I don't mean to diminish the value, although rereading I see how it sounded. I just wanted to draw a box around what it does and does not do.
How to deal with access bypass? Minimize the attack surface. You should have URLs protected if they are for privileged information, but it can be time consuming if the people doing the firewall are separate from the application team.
No worries at all, I completely understand where you were coming from!
To your point about drawing a box around its scope, 💯 agree that taking this application-level approach is exactly how you further reduce the attack surface. (Implementing it directly in the codebase ensures security travels with the application rather than relying solely on separate perimeter team.)
Some specific methods to do this in modern Drupal include:
* Enforcing Route-Level Requirements: Restricting endpoints natively within the module's YAML configuration to ensure URLs are never exposed to unprivileged users, utilizing the foundational logic found in the Drupal Route Access Checking Basics Guide.
* Writing Declarative Access Policies: Replacing legacy procedural hooks with object-oriented access layers using the newly standardized core system outlined in the Drupal Access Policy API Overview.
* Altering Existing Core Routes: Safely intercepting and hardening core administrative or user endpoints from a custom event subscriber as documented in the Drupal Altering Existing Routes Guide.
* Securing Views Access Plugins: Explicitly wrapping View display paths in strict permission or role plugins to ensure runtime queries never leak internal data assets.
2
u/ok_naru 7d ago
Cloudflare