Features
Not a generic scanner with a Drupal label stuck on it — nine features, each built around how Drupal advisories, modules, and configuration actually work.
01 — Security matching
Drubix polls Drupal.org's security advisory feed continuously and cross-references it against each site's actual installed modules. Once the connector module is installed, this is a confirmed version match — not a guess based on what's publicly exposed.
$ checking 34 modules against 1,842 advisories
HIGHWebform — SA-CONTRIB-2026-014
Installed: 6.2.1 · Fixed: 6.2.3
02 — Multi-site dashboard
See every site in one place, sorted by what actually needs attention — not fifty separate admin logins to check one at a time. Each site shows its open findings, last scan time, and whether the connector module is reporting confirmed data.
03 — Remediation included
"Module X is vulnerable" is table stakes. Every finding in Drubix includes the exact command to resolve it — a Composer version bump, ready to run — so you spend time fixing things, not researching them.
HIGHWebform — XSS — SA-CONTRIB-2026-014
04 — Real-time alerts
A weekly PDF nobody reads isn't a monitoring tool. When a new advisory affects a site you manage, Drubix pushes an alert to Slack, email, or a webhook of your choice immediately — filtered by the severity threshold you set, so you're not paged for every low-priority finding.
composer require drupal/webform:^6.2.305 — White-label reports
Generate a branded PDF summary for any site, under your agency's name, showing exactly what their retainer is paying for — findings, severity, and what was fixed.
06 — Historical trends
A point-in-time scan tells you today's status. Drubix records a daily snapshot of open findings by severity, so you can show a client — or yourself — whether a site's health is actually improving over time, not just what it looks like right now.
07 — Cross-site benchmarking
Once enough sites are being monitored, see how any given site's security posture ranks against every other Drupal site on the platform — not just whether it's improved since last month, but how it compares more broadly. Requires a minimum sample size before showing a number, rather than a misleading percentile from a handful of sites.
of monitored Drupal sites for open critical findings
08 — Config drift detection
Config changed directly on a live site but never exported to your repository is a classic source of "it worked on staging" surprises. The connector module compares active configuration against the last exported config and flags exactly which objects have drifted.
09 — CI/CD integration
Gate a deploy pipeline on open findings — fail the build automatically if a known vulnerability is present, before it ever reaches production. Drops straight into GitHub Actions or any CI system that can run a script.
# .github/workflows/monitor-gate.yml
Fetched 1 open finding(s) for site.
[high] Webform — SA-CONTRIB-2026-014
Build gate FAILED: severity ≥ high found.
10 — Attack surface scanning
Checks for a publicly reachable .git/ directory, .env file, or database backup left in the webroot — and audits standard security headers (HSTS, CSP, X-Frame-Options). No connector needed; this runs on every passive scan.
CRITICALPublicly exposed: /.git/config
A readable .git directory can expose your entire commit history.
MODERATEMissing security header: content-security-policy
11 — Permissions & hardening audit
Flags the anonymous or authenticated role holding a permission dangerous enough to hand over site control — "administer permissions," "execute PHP code" — plus writable settings.php and a missing files .htaccess. No generic scanner can check this; it requires understanding Drupal's role model specifically.
12 — Unmaintained module flagging
Most contrib modules aren't covered by Drupal.org's security advisory policy at all. Drubix flags known-unmaintained or inherently risky modules — like the deprecated PHP filter — proactively, rather than only reacting once an advisory eventually gets published.
13 — Blast-radius incidents
When an advisory hits many sites in your portfolio at once, Drubix groups it into a single incident instead of forcing you to click through fifteen separate findings one at a time. Only possible because the platform is multi-site-aware — no single-site tool can do this by definition.
14 — Mean time to patch
Computed automatically from data Drubix already has — the average days between a finding being detected and resolved. "We patch in an average of 3.2 days" is a concrete, retainer-justifying claim, not a vague promise.
average time to patch, last 90 days
15 — Known-exploited prioritization
Cross-references matched advisories against CISA's Known Exploited Vulnerabilities catalog — reordering "fix this first" by real-world attacker activity, not just a severity label. A moderate finding that's actively being exploited jumps ahead of a critical one that isn't.
HIGHWebform — SA-CONTRIB-2026-014
Start with a free scan — no credit card, no commitment.