WordPress, Drupal, Steldris.
The same website, four very different answers to one question: who is accountable for the code that runs on it?
| WordPress self-hosted | WordPress Fruition-hosted | Drupal | Steldris™ | |
|---|---|---|---|---|
| Who can push code to your site | Plugin authors you have never met — often anonymous, rarely accountable. | The same third-party plugin supply chain, with Fruition scanning every dependency for provenance. | Contrib maintainers, vetted through the community queue. | One named team. Every line of code on your site is ours. |
| Third-party plugin / module supply chain | Tens of thousands of plugins of wildly varying provenance. | The same plugins, scored by our provenance scanner the day they ship. | A curated queue with a dedicated security team. | None. Authoring, forms, documents, and accessibility are built in. |
| Core updates | You schedule, test, and deploy them. | Handled by our team for managed-care clients. | You schedule, test, and deploy them. | Handled for you, continuously. |
| Security patching | Your team, against a moving advisory feed. | We patch the infrastructure and the stack; your plugin updates stay on your calendar. | Your team, with strong upstream advisories. | Continuous. Patching is part of the service, not part of your job. |
| Web application firewall | Bring your own, configure it yourself. | Shield WAF in front of every site, tuned by us. | Bring your own, configure it yourself. | Shield WAF in front of every site, tuned by us. |
| Accessibility | Theme- and plugin-dependent. Retrofits are common and expensive. | Theme- and plugin-dependent. The plugins are still third-party. | Strong core accessibility; themes still vary. | WCAG 2.2 AA at the platform level, plus PDF Accessibility for documents. |
| Compliance posture | Whatever your hosting and configuration make of it. | Audited infrastructure underneath; the CMS configuration is still yours. | Whatever your hosting and configuration make of it. | SOC 2 Type II, ISO 27001, HIPAA-compliant hosting available. |
| Maintenance windows | On your calendar, on your weekends. | Ours for the platform; yours for plugin updates. | On your calendar, on your weekends. | Zero. We own the infrastructure. |
| AI content tooling | Third-party plugins of varying quality and provenance. | Third-party plugins we can help you choose, but do not control. | Modules and integrations you evaluate yourself. | Built in. Claude-powered authoring and alt text. |
| Who answers when something breaks | Whoever built it — if they are still around. | Our team, around a codebase we did not write. | Your internal team or your agency. | The team that runs the platform. That is the whole model. |
Self-managed WordPress and Drupal, as most organizations run them. A well-staffed platform team can close some of this gap on any CMS; moving an existing WordPress site onto Fruition infrastructure closes a different part of it, without changing CMSs.
Less code. Less surface.
Every line an attacker can reach is a line that has to be patched forever. The numbers below are measured, not estimated — methodology in the footnote.
~550,000
lines of PHP in WordPress core alone (421,720 in wp-includes + 128,204 in wp-admin) — the surface an attacker studies before a single plugin is installed
~70,000
lines in the entire Steldris platform — public site, publishing application, and API combined
0
lines of PHP reachable from the internet on a Steldris site — public pages are static files
60,000+
plugins in the WordPress ecosystem, largely anonymous authorship — each one a supply-chain decision you now own
WordPress core measured on a 6.9.x install, 2026-08-10; Steldris from the platform repository. Full methodology, including source line counts, is published in our research notes.
The target moves. Constantly.
Every WordPress release is a public diff and a change to the code your visitors execute. Twelve months, measured — with our own release cadence next to it.
There is no one WordPress.
Sites update on their own schedule, so every release above stays in circulation. A site is one core version plus one version of each plugin, chosen independently and never tested together. Count only the last twelve months, only these six plugins, and only one version per core branch, and the possible combinations are still:
- 24core branches kept patched
- 106WooCommerce
- 48Elementor
- 28Yoast SEO
- 9Wordfence
- 6Contact Form 7
- 4Akismet
738,533,376possible WordPress version combinations
1build serves every Steldris site. 187 deploys replaced it in place — every site, at once.
How a moving target gets hit
- A release ships. Core, or any of 60,000+ plugins. The diff is public the moment it lands. Attackers read it for free.
- The diff is the map. Mass-compromise campaigns are automated diff-watchers. They read the change, find the exploitable delta, and weaponize it.
- Spray. Every site running that code gets the same payload. Drupalgeddon2 ran this play at platform scale: one deserialization flaw, roughly a million sites, automated scanners within hours of the first public exploit.
Why it matters more every year
WordPress core is 549,924 lines of PHP before a single plugin is installed. Each release above rewrites a slice of it, and each one hands attackers a fresh diff to read. What a defender audited last quarter is different code today.
The attacker has to win once. The defender has to win every time — against code that changes every release.
Release dates from wordpress.org and plugins.svn.wordpress.org (tag creation dates, stable versions only); Steldris deploys from the platform's CI history; all counted 2026-09-16. The combination count is exact for its assumptions and deliberately conservative: one version per supported core branch (counting all 106 core versions gives 3,261,855,744), all six plugins installed, one version of each. It ignores plugins' minimum-WordPress-version rules, which rule some pairs out, and the other 60,000 plugins, which multiply the rest. Core line counts measured on a WordPress 6.9.x install, 2026-08-10.
Hardened by default, not by effort.
The first requests an attacker sends, against two live sites we operate. WordPress ships with a login page, an admin panel, a REST API and a PHP runtime facing the internet: it has to be hardened against its own natural state, then re-hardened after every release above. A Steldris site's natural state is the hardened one. Nothing runs.
| WordPress Fruition-hosted & hardened | Steldris™ as shipped | |
|---|---|---|
| Server-side runtime exposed to the internet | Live PHP + MySQL behind a cache layer. | None. Public pages are static files served from the edge. |
| Login endpoint on the public site | /wp-login.php — a 1,650-line PHP file dispatching eleven auth flows, with 76 superglobal reads and 46 plugin-mutable hooks. | None (403). Authentication lives on a separate app behind Auth0. |
| Admin panel reachable | Yes, /wp-admin/ on the public site. | No. The admin is a separate application behind enterprise SSO. |
| REST API / user enumeration | Yes — the REST API leaks real usernames. | None (403). There is no public API surface. |
| XML-RPC pingback | Present by default (blockable, but it exists). | Does not exist. |
| Version fingerprinting | Core and plugin versions leak into the HTML. | None. |
| Security headers by default | HSTS only; the rest is per-site plugin/nginx work. | Full A-grade set, applied uniformly at the platform level. |
| Code an attacker can reach | ~550,000 core lines + every installed plugin. | Zero lines. Nothing executes for anonymous visitors. |
Measured 2026-08-10 against live production sites Fruition operates: a hardened, Fruition-hosted WordPress site (the WordPress column is the architecture, not a misconfiguration) and a Steldris site. Full methodology is in our research notes.
03 — WHO HOLDS THE PEN
Every update hands a stranger the keys.
On a typical WordPress site, a plugin update puts code from an anonymous author onto your server with full access to your database, your visitors, and your content. No profile, no history, no one accountable. In 2026, websites are real-time, AI-integrated surfaces that adversaries actively target. The model that was fine in 2003 is not built for that.
WordPress, self-hosted
The plugin model: anyone can publish, updates flow straight to your site, and the person who wrote the code is usually a username. Accountability ends at the download button.
WordPress, Fruition-hosted
The same plugins, on infrastructure we run. Every dependency gets a provenance score and we watch the updates for you — but the code still comes from outside.
Drupal
Better governance, same model. Drupal's security team and vetted contribution queue raise the floor, but the modules still come from outside your organization, and the updates are still yours to chase.
Steldris
No third-party plugin layer at all. One accountable team writes, reviews, and deploys every change, and you can ask any of us by name what changed and why. That is what provenance means when it is actually enforced.
7,612
third-party WordPress plugins provenance-scanned across our managed fleet
234
installed by our clients but maintained by an anonymous author — no one to hold accountable
48 / 100
median provenance score of a random WordPress.org plugin (1,964-plugin random sample) — and none of the 1,964 earned an A or B
0
third-party plugin-layer dependencies on a Steldris site
From the dependency provenance scanner we run across our managed fleet, September 2026: every WordPress plugin and Drupal module is scored 0-100 on source origin, maintainer identity and verifiability, security coverage, and maintenance activity. An anonymous maintainer caps the grade at D automatically — no amount of popularity offsets an accountability failure. The WordPress.org baseline is a uniform random sample of the public plugin directory (random offsets over the popularity ranking), scored with the same rules — note that commercially-sold plugins (the anonymous-maintainer ones) do not even appear in the public directory, so the ecosystem's real floor is lower than the median suggests.
Ask your current vendor the question that matters: who typed the code that runs on your site, and can you call them? On Steldris the answer is a name.
Measured, not marketed
The scorecard.
A sample set of the sites we manage, scored by the same scanners and averaged by platform — including the column where Steldris is behind.
| Platform | Performance | Accessibility | SEO | Security headers |
|---|---|---|---|---|
WordPress | 64D | 87B | 86B | 27F |
Drupal | 54F | 77C | 80B | 49F |
Steldris | 97A | 92A | 84B | 94A |
Fruition Control Plane, CMS comparison, pulled 2026-09-16: a sample set of the sites we manage — the latest desktop Lighthouse score and the latest security-headers scan (0–100) for each site, averaged by platform. Letter grades are the scanner's own bands (A 90+, B 80+, C 70+, D 60+). Steldris trails on SEO because steldris.com serves a noindex header until its public launch, and that one check pulls the small Steldris sample down. Raw vulnerability-scanner finding counts are not shown: the feed does not split them by severity, so a static site's "technology detected" matches would read like exploitable findings. We score ourselves with the same scanners, weekly.
The trade-off.
WordPress and Drupal are mature platforms with enormous ecosystems, and neither is inherently insecure. Hosting them on Fruition's infrastructure closes a real part of the gap: the Shield WAF, managed patching of the platform, monitoring, and backups all become ours. What stays yours is the plugin ecosystem and the accessibility retrofit. Steldris removes that layer entirely. If your team has the people and loves the work, keep what you have. If you would rather spend that time on your mission, that is what we do.
Tell us where your site lives today.
We handle the move and run the platform for you. No re-platforming project, no plugins to babysit.
- We migrate your content off WordPress or Drupal.
- We run hosting, security, and accessibility from day one.
- You get a calm dashboard and a team that owns the infrastructure.