Ask most people responsible for a Drupal site what needs to be kept up to date, and they'll say "Drupal." That's a reasonable answer. It's just not the complete one.

A Drupal site isn't a single piece of software. It's Drupal core — the main Drupal software that everything runs on — plus a collection of contrib modules — the add-ons and extra features your site uses on top of Drupal itself. These might include things like a contact form handler, an SEO tool, a media library, a newsletter integration, a payments component, or a WYSIWYG editor. Often many more.

Each of those contrib modules is a separate piece of software, maintained by a separate developer or team, with its own release cycle — and its own security vulnerabilities.

What contrib modules actually are

Drupal core is what you get when you download Drupal. It handles the fundamentals: content management, user accounts, permissions, page routing, the admin interface. It's well-maintained and widely scrutinised.

But very few Drupal sites run on core alone. The features that make a site actually useful — the specific functionality your organisation needs — typically come from contrib modules. "Contrib" is short for "contributed," meaning they're built and shared by the wider Drupal community rather than by the Drupal project itself.

There are thousands of contrib modules. Some are maintained by large organisations with dedicated engineering teams. Some are maintained by one person in their spare time. Most fall somewhere in between. They vary widely in how actively they're developed and how quickly security issues get resolved.

The difference between core updates and module updates

Core updates come from the Drupal project itself and cover the central software every Drupal site shares. When a core security advisory — an official announcement that a vulnerability has been found and a fix is available — is published, it potentially affects every Drupal site on the internet.

Module updates come from individual module maintainers and cover specific functionality. They're tracked separately, published independently, and only affect sites that have that particular module installed. Each one requires its own attention.

Core updates get more attention because they make bigger news. Module updates are quieter, more numerous, and easier to miss — which is part of why they're also a more common route for exploitation.

The maths of module security

A typical Drupal site might have anywhere from 20 to 60 contrib modules installed. Some will be major functional components. Others will be small utilities that someone installed years ago and nobody thinks about anymore.

Each one is a potential source of security advisories. Each one needs to be tracked. When a security issue is found in a module you're running, it needs to be updated — with the same urgency as a core update, because the exploitability is often comparable.

The challenge is that there's no single dashboard where this happens automatically. Without a systematic process, module security updates accumulate in the background until something prompts a check — which is often not often enough.

Modules you've forgotten about

There's a particular category worth mentioning: modules that are installed and enabled but no longer actively used.

Drupal sites are often built over time, with features added and sometimes effectively abandoned without being properly removed. A module might have been installed to handle a feature that was later replaced. It's enabled, sitting quietly, doing nothing visible — but it's still part of the site's software inventory, which means it still receives security advisories that apply to your site.

Unused modules that are no longer needed should be uninstalled. Not just disabled — properly removed. This shrinks the attack surface and reduces the number of things that need to be tracked.

What good module security looks like

Keeping on top of module security isn't complicated in principle. It requires:

  • Knowing which contrib modules are installed on your site
  • Monitoring for security advisories affecting those modules
  • Testing updates before applying them to a live site
  • Applying updates promptly once tested
  • Periodically reviewing whether every installed module is still needed

In practice, the difficulty is that this is ongoing, recurring work. It's not something you do once — it continues for as long as the site is live.

How Nodely handles this

When we take on a site, we audit the full module stack — not just core. We track security advisories for every contrib module on your site, not just the ones you know about. When an update is available, we test it in a staging environment before deploying it to the live site. We report clearly on what was updated and why.

Core gets the headlines. Contrib modules are where sites quietly drift behind. We cover both.

If you'd like to know which advisories currently apply to your site — core and contrib — get in touch for a free security check. You might be surprised how many open items there are.