Drupal Security: How the Advisory Process Actually Works, and the Checklist We Run on Every Site

Drupal’s security reputation is the reason it runs government portals and university systems. That reputation is earned — and routinely misunderstood. The platform’s security process is excellent; a specific Drupal site is only as secure as the team operating it. I’ve inherited enough compromised sites to know exactly where the gap between those two sentences lives.

So here’s the whole picture: how Drupal security actually works, the history lesson everyone in this ecosystem carries, and the operational checklist we run on every site under our care.

How the Drupal security process works

Drupal has a formal security team — funded, staffed, with a documented process. Researchers report vulnerabilities privately; the team validates, coordinates a fix with maintainers, and publishes a Security Advisory (SA) with a severity rating, typically on a Wednesday so operations teams can plan around it. Core and thousands of vetted contributed modules are covered. Critical advisories are announced ahead of release, so serious teams are standing by when the patch drops.

This is genuinely better than most of the CMS world, and it’s citable in compliance reviews. But read the fine print of what it promises: a patch will exist, promptly. Whether it gets applied to your site — that’s the part no one in the Drupal Association can do for you.

The history lesson: Drupalgeddon

In 2014, a critical SQL-injection vulnerability in Drupal core (“Drupalgeddon”) was patched — and within hours of the advisory, automated attacks were compromising unpatched sites at scale. The security team’s follow-up announcement was blunt: if you hadn’t patched within about seven hours, you should assume compromise. A second wave (“Drupalgeddon 2,” 2018) repeated the pattern.

The lesson wasn’t “Drupal is insecure” — the process worked exactly as designed, and patched sites were fine. The lesson was that the window between advisory and exploitation is now measured in hours, which makes “we apply updates during our monthly maintenance window” an unacceptable answer. Ask your current vendor what happens when a critical advisory drops on a Friday afternoon. The answer names a process, or it names your exposure.

The special case: you’re still on Drupal 7

Everything above describes supported Drupal. Drupal 7 is past end of life — no more official advisories, no more patches. Every D7 site is accumulating unpatched risk monthly, silently, with the polished exterior of a perfectly working website. If that’s you, security is now your migration business case: the details are in the D7 end-of-life guide and the migration cost breakdown.

The hardening checklist we run

This is the operational baseline for every site we support. None of it is exotic; all of it is regularly missing from sites we inherit.

• Same-day patching for critical advisories. Monitoring on the security feed, a staging pipeline that can test-and-deploy in hours, and an SLA in writing. This one item outweighs everything else on the list combined.
• Module hygiene. Every installed module is attack surface. We audit quarterly: uninstall what’s unused (disabled isn’t enough — the code must go), replace abandoned modules, and check that everything installed is covered by the security team’s advisory policy.
• Least-privilege accounts. The classic finding: seventeen people with full admin because it was easier that day. Editorial roles get editorial permissions. Admin accounts get strong authentication and a review cadence. Former staff get offboarded the week they leave, not the year.
• Two-factor authentication on every privileged account. Credential stuffing is the boring way sites actually fall. TFA on admin and editor accounts closes it.
• HTTPS everywhere, headers configured. TLS on every page, secure cookies, and sane security headers. Ten minutes of configuration that shows up in every scan you’ll ever be subjected to.
• A WAF or edge layer. Cloudflare or similar in front of the site buys response time when the next hours-matter advisory lands — automated exploit traffic gets filtered while you patch.
• Tested backups. Not “backups configured” — backups restored, on a schedule, as a drill. A backup you’ve never restored is a hope, not a plan.
• File-permission and update-path hardening. Web server can’t write where it shouldn’t; no update through the browser; deployments flow through Git, so an attacker’s file change is also a visible diff.

What this costs, honestly

Everything on that checklist is included in a competent maintenance plan — which is precisely the argument for having one. A support retainer that covers monitoring, same-day critical patching, quarterly module audits, and tested backups runs a few hundred to a few thousand dollars monthly depending on complexity; the full price map is in what Drupal maintenance costs. Enterprise and government sites layer compliance reporting on top — how that’s structured is in the enterprise support piece.

Against that number, weigh the incident: forensics, rebuild, disclosure obligations, and the reputational cost of your domain serving malware for a weekend. I’ve quoted both kinds of project. The retainer is cheaper by an order of magnitude.

If you don’t know your site’s current posture — when it was last patched, what’s installed, who has admin — that’s itself the finding. Request a free security review and a senior engineer will audit exactly that and send you a written report. No scare tactics; just the list, in priority order. Ongoing coverage lives under our Drupal support plans.