Drupal security updates — why they cannot be postponed

Drupal has one of the more mature security processes among open-source CMS platforms. But applying a security update is not simple — it is technical work that requires planning.

Many website owners assume that "updating" means pressing a button. In Drupal projects, that is not how it works — and for good reason. Understanding how security updates work helps explain why regular maintenance is technical work, not an automated process.

The Drupal Security Team

Drupal has a dedicated volunteer security team responsible for evaluating vulnerabilities and publishing security advisories. The process works as follows:

Someone reports a vulnerability privately to the Security Team.
The team assesses severity and coordinates a fix with the module maintainer.
On a scheduled date, the fix and the security advisory are published simultaneously.
Vulnerability details become public — what the issue is, which versions are affected and what the recommended action is.

This process means that once a fix is published, the vulnerability details are public. From that point, attackers know exactly what to look for on unpatched sites.

What applying a security update actually involves

Drupal uses Composer for dependency management. An update runs through the command line:

`` composer update drupal/core --with-dependencies ``

This sounds straightforward, but in practice it can trigger a chain of steps:

dependency conflicts — a module may not yet be compatible with the new core version;
custom code changes — if the site uses APIs that have changed;
database updates — core updates often include schema changes;
theme updates — the theme may need adjustments;
testing — the update should pass through a test environment before going to production.

On a simple site this process takes an hour or two. On a heavily customised site, testing alone may take a day.

Three environments

In professional Drupal work, there are typically three environments: development, staging and production. An update is applied in the development environment first, verified, then moved to staging, and only then to production.

This staged approach is necessary to ensure the update does not break the live site. But it also means that applying a security fix "quickly" does not really mean quickly — even for a critical vulnerability, the minimum safe update time is several hours.

Why some sites remain unpatched

The most common reasons:

No one to do it. The site was built and the developer contract was not renewed.
Fear of breaking things. Previous updates broke something, so updating has been stopped.
No awareness of the need. The site owner does not know Drupal updates are required.
Technical debt has accumulated. Updating would require so much work that it has been postponed.

In all these cases, risk grows over time — every unapplied update is a potential entry point.

Regular maintenance resolves this

Drupal maintenance applies security updates regularly — typically monthly, or sooner for critical updates. Maintenance includes environment management, testing and documentation.

The Drupal platform assessment shows publicly visible Drupal and PHP version traces — a useful starting point for assessing how far the current state is from ideal.

Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.