Drupal contributed module supply chain risk

Why Drupal contributed module supply chain risk needs a review before installation

Every contributed module your regulated site installs is code the site inherits, and it must be judged before adoption, not after it reaches production. Drupal core and the contributed projects derived from it are licensed under GPL-2.0-or-later, according to the Drupal.org licensing page, which means your team can use them freely but also carries full responsibility for what they do inside your environment. The license grants no vendor warranty, so the due diligence has to come from your own process. DeployOpen prepares, reviews and supports these choices with your team, but it does not issue audit reports or attestations, so the evidence you collect must still satisfy your own assessors and any independent auditor you use.

The review matters most in three situations. The first is a new feature request, such as a payment, identity or search requirement, where a module looks like the quickest route and is installed before anyone checks its maintenance history. The second is an inherited site, where modules were added by people who have since left, and the current team does not know which code is still supported or which advisories apply. The third is a module supported by only one maintainer. Such projects can be useful, but a single person's availability becomes a delivery risk, and a security fix may arrive late or not at all. Ask your DeployOpen contact to list each module's maintainers, release history and open advisories before you add it to the build plan.

What to check on a module's project page before adoption

Start by confirming that the project is covered by the Drupal Security Team process. Security advisories for contributed projects are published by the Drupal Security Team, with CVE identifiers and risk scores, and fixes are released in the Wednesday security windows. A module that has no security release history is not automatically safe, but you cannot rely on the team's process for it until you confirm its coverage on the project page.

Security advisory history: Review past advisories for the project and check how quickly the maintainers shipped fixes and whether the fixed releases are the ones you would install.
Security team coverage: Confirm the project is listed as covered and has a documented way to report vulnerabilities.
Fixed release availability: Check that the current stable release includes every fix published for the branch you will run.
Advisory response for your core version: Verify that advisories apply to the release line you use, not only to the newest branch.
Dependencies: Note third-party libraries the module bundles or requires, since their advisories also affect your site.

Before adoption, record the advisory history, the security coverage statement and the date of the last fixed release, and set an owner to watch the project for future advisories.",

Module adoption options and when each fits

This table compares the four ways a team can handle a contributed module it wants, from adopting it as published to deferring the feature. Read each row against your own maintenance capacity and how much the feature matters to the business. The main takeaway is that adopting a module is only low-cost if someone on your side owns its advisories, updates and upgrade testing.

Option	When it fits	What it commits the team to	Ongoing review cost
Adopt a maintained contributed module as published	The module has an active maintainer, a stable release for your Drupal version, and a security coverage record you can check on Drupal.org	Tracking its security advisories, applying updates in your patch window, and testing each release against your site before deployment	Recurring: reviewing each advisory and release notes, plus regression testing on every update
Adopt with a patch or fork in your repository	The module fits the need but has a gap, a bug or a pending fix that matters to you and the upstream project is responsive	Maintaining the diff, re-applying it on every upstream release, and documenting why the divergence exists	Recurring and growing: each upstream update may conflict with your changes, and the patch needs its own review
Replace with custom code	No suitable contributed module exists, or the required behavior is narrow and the module would bring far more code than you use	Writing, testing and documenting the code, owning its security review, and keeping it compatible with each Drupal core upgrade	Recurring and internal: code review, unit and functional tests, and upgrade work sit with your team or partner
Defer the feature	The module is unmaintained, has open critical advisories without a fix, or lacks support for your target Drupal version	Accepting the gap in the business process and revisiting the decision when the module or your upgrade plan changes	Low in the short term, but the deferred need may return as a more urgent request during an upgrade

How to run a contributed module review before installing new code

This sequence turns a wish for new functionality into a documented decision to install, reject or defer a contributed module. Each step leaves a check or record behind, so the reviewer can show later why the module was accepted and how it will be kept current.

Define the functionality the module must provide
The business owner and the lead developer write down the exact feature, the content or users it affects, and what the site will do without the module. Ask whether core, an existing module or custom code within the current project could meet the need. The step is complete when the requirement is written as a short, testable statement that the team agrees to in writing.
Shortlist candidate modules on Drupal.org
The developer searches Drupal.org for projects that meet the requirement and records two or three candidates with their project URLs. For each candidate, note the maintainer, the last release date, the supported core versions and how many sites report using it. The output is a shortlist table that the reviewer can compare line by line.
Check advisory history and coverage
The security reviewer reads each candidate's security advisories and confirms whether the project is covered by the Drupal Security Team process. Look at how quickly past advisories were followed by fixed releases, and whether any open issue affects the version you plan to run. The step is done when each candidate has a recorded advisory summary and a yes or no on whether it is covered.
Confirm maintenance and compatibility with the platform
Confirm that the module declares support for the Drupal core version the project runs, and that it works with the PHP version set in the target environment. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so a module that has not been updated for the planned core line is a blocker. Record the core and PHP versions checked and the maintainer's latest activity, and reject any candidate that cannot support the target versions.
Review code and third-party dependencies
A developer reads the module's code for risky patterns, such as unescaped output, unchecked file uploads, raw database queries and access checks missing from routes or APIs. The reviewer also lists every Composer dependency and external library the module pulls in, then checks each one against the same advisory and maintenance criteria. The output is a short review note with findings, their severity and whether each is accepted, fixed or blocking.
Test the module in a non-production environment
Install the module in a staging copy of the site built from the same codebase, database engine and web server as production. Test the required feature with real permissions for each role, run the existing automated tests, and check the logs for errors and deprecation notices. The step is complete when the test results and any configuration changes are recorded, and the team agrees the module behaves as the requirement states.
Record the decision and approve the installation
The project lead writes a decision record that names the module, the version, the requirement it meets, the review findings and the approver. Regulated organizations usually route this record through their change or architecture board before the code is merged into the main repository. Keep the record with the project documentation so auditors and future maintainers can trace why the module is present.
Set an update and monitoring routine
Assign an owner for the module who watches for new releases and advisories, and add the module to the site's regular update routine. Confirm the update path against the Drupal core release schedule, including the first Wednesday bugfix releases and third Wednesday security releases. The step closes when the owner, review cadence and removal criteria are written into the operations runbook, including the condition that triggers replacing or removing the module.

Security risks a contributed module can add to a Drupal site

A contributed module runs with the same privileges as Drupal core, so its maintenance state, dependencies, access logic and ownership all become your risk. The cards below cover six distinct ways a module can widen exposure and the control that keeps each one visible and bounded.

Unmaintained code misses advisories

A module with no active maintainer may never receive a fix when the Drupal Security Team publishes an advisory for it. Advisories for contributed projects arrive with CVE identifiers and risk scores, so a stale module can stay vulnerable long after the fix exists. Check the project page for maintenance status, recent releases and open security coverage before adoption. Control: keep a written inventory of every contributed project, its version and its advisory subscription, and review it on the monthly bugfix cycle. Confirm the module's current status with the project page rather than assuming it.

Large dependency trees

A module can pull in Composer packages, libraries and other contributed modules, and each one inherits the trust placed in the module. A small feature can therefore add a large set of code you did not review. Compare the full dependency graph before install, not only the top-level module. Control: pin versions in composer.lock, review new transitive packages in every merge request, and run a dependency audit as part of the release check.

File upload and access control logic

Modules that handle file uploads, custom permissions, entity access or API endpoints sit closest to the data and the users. A flaw in this code can expose private content or allow writes that bypass Drupal's access checks. Read the code paths that touch hook_entity_access or file validation, and confirm which roles can reach them. Control: restrict these modules to a named reviewer, test them in the penetration test scope, and limit permissions granted by the module to the minimum needed.

Forks that drift from upstream

A site-specific fork of a contributed module stops receiving upstream fixes unless someone merges them by hand. Over time the fork diverges, and the security patch on the original project no longer applies cleanly. Ask whether a fork is necessary, or whether a patch file or configuration option would do the same job. Control: record each fork and its upstream base version, track upstream advisories against it, and schedule a periodic rebase or retirement review.

Secrets stored in configuration

Some modules save API keys, OAuth client secrets or SMTP passwords in site configuration. Those values then appear in configuration exports, backups and version control, where more people can read them than should. Search module settings and exported YAML for credential fields before approving the module. Control: move credentials into the Key module or environment storage, and exclude secret values from exported configuration.

Inherited modules with no owner

Modules inherited from a previous build or agency often have no named person who knows why they are installed or how to update them. When an advisory arrives, nobody can decide quickly whether the site is affected or who should patch it. Control: assign each contributed module an owner and a business purpose in the inventory, and remove modules that have no owner after a documented review.

What a regulated site should record for each module

A regulated site should be able to show, for every contributed module, why it is installed and what was checked before it went live. An auditor or internal risk team will usually ask for a dated record per module that states the business justification, the review date, the security advisory history checked, the exact version approved, the named owner and the update route. Keep the record in the same repository as the Composer manifest and lock file so that the approved version and the documented version cannot drift apart. The record should also name the person who accepted the residual risk when a module is abandoned or has no advisory coverage at the time of review.

The justification should describe the requirement the module serves, such as SAML sign-in through the SAML Authentication module, and why core or an existing approved module could not meet it. Record the advisory check as a list of the advisory identifiers reviewed and the date of the search, not a general statement that the module is secure. For the update route, record who receives Drupal Security Team notices, which Wednesday security window the team uses to apply patches, and the internal deadline for applying a critical or highly critical fix. The approved version field should match the lock file entry, and the record should be updated whenever that entry changes.

DeployOpen prepares this record as part of an implementation or a security review, and it can set up the template, fill in the evidence from the project and hand it over for your own review. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies decide whether your controls meet the requirements that apply to you, so confirm with them early which fields and retention periods they expect. Ask your assessor whether they want the record in a particular format and how long old approvals must be kept after a module is removed.

Limits to confirm in your own environment

Several limits decide whether a contributed module is safe to keep, and most of them depend on your own core version, upgrade calendar and patch process rather than on the module alone. The cards below cover the items to confirm before you approve a module, and each one maps to a point where a supply chain decision can quietly become a support gap.

Core version support window

Confirm which Drupal core line your site runs and when it stops receiving security coverage. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. A module that works today on Drupal 10 may have no maintained release line for Drupal 12, so check each contributed module's compatibility against the upgrade target now, not at the point of upgrade.

Drupal 7 modules that cannot move

If any part of the estate is still on Drupal 7, list every contributed module and check whether a Drupal 10 or later equivalent exists. Drupal 7 security support has ended, and the Drupal Association's extended support program lists certified vendors for sites that cannot migrate yet. Modules with no successor create a permanent exception that needs a named owner, a compensating control and a funded exit date.

Version coverage on the project page

For each module, open its Drupal.org project page and confirm that a release line supports your exact core version, including the minimum PHP version that core requires. A module can list Drupal 11 in its metadata while its latest stable release only targets an older minor version. Record the release you intend to install, the core versions it declares and the date of its last commit, and treat anything else as unsupported until it is confirmed.

Patch deadlines against the Wednesday window

Compare your internal patch deadlines with the security release cadence. Drupal security releases come out on the third Wednesday of the month, and bugfix releases on the first Wednesday. Confirm that your change process can approve, test and deploy a contributed module update inside your deadline, including the time needed for staging tests and a rollback plan. A deadline shorter than your full change cycle means the process, not the module, is the real risk.

PHP runtime alignment

Confirm that the PHP version on your application servers matches what the core line and each contributed module require. Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, and no supported Drupal version runs on PHP 7. A module that declares compatibility with your core version may still fail on an older PHP runtime, so check the runtime in every environment, including build and staging hosts.

Ownership of abandoned code

Identify who will maintain each contributed module once the original maintainers move on. Ask whether the project has more than one maintainer, whether it has recent releases, and whether your organization has the skills to patch the code itself. If nobody on your side can take over, budget a support arrangement with an implementation partner or a commercial extended support provider before the module becomes a blocker.

Questions teams ask before reviewing contributed modules

What does a contributed module review cost, and what drives the effort up?

The cost depends on how many modules are in scope, how much custom code depends on them, and how much history the review must reconstruct. Each module needs a check of its advisory history on Drupal.org, its maintenance status, its declared compatibility with your Drupal version, and the modules it depends on. Costs recur whenever you add new code, so ask any quote to separate a one-time baseline review from the ongoing intake check your team will run later. Ask the provider to price each module group separately so you can see which modules drive the total.

How long does a review take for a site with many modules?

Duration grows with module count, dependency depth and inherited code, not with the size of the site's content. A site with a handful of contributed modules and clean history is quicker to review than one with dozens of projects, forked patches and custom modules that override contributed behavior. Ask for the timeline to be tied to a written module inventory, because the inventory is the first thing that changes the estimate. No duration is given here; confirm it against your own inventory and your internal patch deadlines before you commit.

What does the review need from our team?

The review needs named owners, a staging environment that matches production, and read access to your code repositories, Composer lock files and configuration exports. You also need one person who can decide whether a module stays, goes or gets forked. Without a business owner for each module, findings sit unresolved. Access should be granted through least privilege accounts, with a record of who approved them. Plan for staging time to test updates and for a contact who can answer questions about how the site uses each module.

Can our own team run the review without a partner?

Yes, if you have engineers who know Drupal, can read advisories and can run a test environment. The core checks are the same whether you do them internally or with a partner: review the Drupal Security Team advisories for each project, confirm the project is actively maintained, check compatibility with your Drupal core version, and review the code you install. Teams often struggle with consistency rather than skill, so write a checklist, record decisions and repeat the same intake steps for every new module. A partner adds the most value when the inventory is large or when deadlines are tight.

What should we do with a contributed module that has no active maintainer?

First, confirm the situation on the project page: look for recent commits, open security issues, and whether any maintainer has responded. If the module is unmaintained but still used, your options are to keep it with a documented risk acceptance, fork it under your control, or replace it with a maintained alternative or custom code. Each option carries a recurring cost, because someone must watch advisories and apply fixes. Record the decision, the owner and the date you will revisit it.

When should we fork a module instead of replacing it?

Fork when the module provides behavior your site depends on, no maintained alternative covers it, and the change you need is small enough to carry. Replace when a maintained project or core functionality offers the same outcome and migration is manageable. Forks take on ongoing maintenance, including rebasing onto new releases and tracking advisories for the fork, so the decision should include who will do that work. Keep local changes as small and documented as possible so future upgrades stay manageable.

Can DeployOpen certify a contributed module as safe?

No. DeployOpen does not issue certifications, attestations or audit reports for software. It can review modules against the criteria above, test them in your environment, document findings and help you prepare evidence for an assessment. Independent auditors and certification bodies make their own determinations. Ask any provider to state in writing what the review covers and what it does not, so your compliance team knows what the output can support.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Drupal contributed module supply chain risk, we turn your module review requirements into a written scope, build the review workflow and records in your environment, and hand over a process your team can repeat for every new module.

How we scope

Inventory every contributed module in use and list which ones hold authentication, file handling or data access
Agree in writing which modules the review covers, the criteria each must pass and who signs off
Confirm your patch deadlines and how advisory notices reach the people who approve changes
Define deliverables, exclusions and timelines in a fixed-scope document before any work starts
Ask for a quote that separates one-time review work from any recurring monitoring you want

How we build

Set up an intake form and checklist covering maintenance status, release history and advisory coverage
Check each candidate module against the Drupal Security Team advisory record before installation
Test candidate modules in a staging copy of your site, with custom code and configuration as deployed
Record the decision, the version approved and the reviewer for every module in your change system
Review composer lock files and dependency changes so new code cannot enter production unseen

How we hand over

Deliver the written review procedure, checklist templates and the list of approved modules and versions
Walk your engineers and approvers through the review on a real candidate module from your own backlog
Document how to remove or replace an abandoned module, including data and configuration dependencies
Provide evidence of each review in a form your internal audit or assessor can sample
Agree which items your team owns after handover and which parts you may want to retain DeployOpen for

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, priced from the written scope
Re-review approved modules when new Drupal core versions or security releases change their risk
Track module abandonment and unsupported projects so replacement planning starts before a forced change
Run security testing against contributed code paths as part of scheduled assessments, where scoped
Keep review records current through core and module upgrades, so each change has a traceable approval