The Ratio That Procurement Overlooks
Enterprise platform assessments typically evaluate security and community health as separate line items. Drupal has 1,376 CVEs — notable, but manageable for a platform with two decades of deployment history. Drupal has 50 active contributors — low, but not unprecedented for a mature open-source project. Evaluated separately, each metric tells a partial story. Evaluated together, they define a maintenance ratio that enterprise risk frameworks should treat as a first-order concern.
The ratio: 27.5 CVEs per active contributor. Each person in Drupal's contributor base is notionally responsible for the security history, patching obligations, and ongoing monitoring associated with 27.5 known vulnerabilities. For comparison, Next.js assigns 0.2 CVEs per contributor — 427 contributors maintaining a surface of 92 CVEs. The two frameworks operate at different orders of magnitude on this metric.
What the CVE-to-Contributor Ratio Measures
The ratio does not measure quality of contributors or severity of individual CVEs. It measures capacity — specifically, the capacity of a contributor base to monitor, triage, patch, and verify fixes across a known vulnerability surface. A ratio of 27.5 means that if every Drupal contributor dedicated equal time to vulnerability management (which they do not — contributors also build features, review pull requests, write documentation, and manage releases), each would be responsible for nearly 28 historical vulnerability patterns.
In practice, security work concentrates among a subset of any project's contributors. If ten of Drupal's 50 contributors focus on security — a generous estimate — the effective ratio rises to 137.6 CVEs per security-focused contributor. The arithmetic is unfavorable at every reasonable assumption about security team size.
Drupal's 662 commits per year from those 50 contributors yields approximately 13 commits per contributor. This is functional output, but it must cover feature development, bug fixes, security patches, and infrastructure maintenance simultaneously. The bandwidth available for proactive security work — auditing old code, hardening APIs, reducing attack surface — competes with every other development priority.
The CMS Landscape Comparison
Drupal is not alone in carrying a high CVE-to-contributor ratio, but it represents the acute end of the spectrum among actively maintained platforms. WordPress has 89 contributors and 18,321 CVEs — a ratio of 205.9. Joomla has 283 contributors and 1,313 CVEs — a ratio of 4.6. The three major legacy CMS platforms span a wide range, with Joomla's larger contributor base providing measurably better coverage relative to its vulnerability surface.
Joomla's ratio merits attention. With 283 contributors, 644 commits per year, and a WebPulse score of 63, Joomla is not typically positioned as a security leader. But its CVE-to-contributor ratio of 4.6 indicates a contributor base that is proportioned more reasonably to its security obligations. Joomla also ships 50 GitHub releases per year — transparency that enables external verification of patch deployment.
Modern frameworks operate at ratios below 1.0. Next.js: 0.2. SvelteKit and Astro carry minimal CVE histories against contributor bases exceeding 300. The structural difference is not just fewer CVEs — it is architectures that produce fewer CVEs combined with communities that provide dense coverage of the codebase.
Drupal's Specific Risk Profile
Drupal occupies a particular niche: government agencies, higher education institutions, and large nonprofits. The platform powers sites for the White House, the European Commission, and numerous university systems. These are high-value targets for adversaries. A platform serving government infrastructure with 50 active contributors and 1,376 CVEs presents a different risk calculus than the same platform serving low-traffic blogs.
Drupal's WebPulse score of 70 reflects its strengths — a mature module system, solid architectural foundations, and a dedicated core team. But the score also incorporates the contributor and security data. At 4,270 GitHub stars, Drupal trails not just modern frameworks but also its CMS peers in community attention metrics. Stars do not determine quality, but they correlate with the broader developer attention that drives contributor recruitment.
What This Means for Platform Governance
The CVE-to-contributor ratio is not a standard metric in most procurement frameworks, but it should be. Existing assessments evaluate vulnerability counts and community size independently. The ratio captures something neither metric shows alone: whether a project's maintenance capacity is proportioned to its security obligations.
For organizations currently running Drupal, the data does not demand immediate migration. It demands honest assessment of operational risk. If your Drupal deployment is a static content site with limited dynamic functionality, the effective attack surface is narrower than the CVE count implies. If your Drupal deployment runs authenticated sessions, processes form submissions, manages user data, and integrates with backend systems, the full CVE surface is relevant, and the 50-contributor maintenance base is your first line of defense.
The comparison with Next.js is not an argument that every Drupal site should migrate to Next.js. It is an argument that the maintenance ratio — 27.5 versus 0.2 — belongs in every platform risk assessment. The difference is two orders of magnitude. Procurement decisions should reflect that.
Organizations that choose to remain on Drupal should quantify their compensating controls. Dedicated security staffing, contracted vulnerability response, Web Application Firewall coverage, and automated patch verification pipelines can offset contributor scarcity — but each adds cost that the ratio predicts. A platform with 0.2 CVEs per contributor requires fewer compensating controls than a platform with 27.5. The delta between those ratios is, in financial terms, the operational premium for running Drupal in 2026.
