Know within minutes whether a disclosure affects you
Plugin vulnerability monitoring across every connected site, matched continuously against published disclosures rather than on a scan schedule, and ranked by the consequence to your specific portfolio.
Free during early access. No credit card required.
Periodic scanning is too slow for disclosure timelines
Vulnerability scanning on a weekly or nightly schedule made sense when disclosure and exploitation were separated by weeks. For widely deployed WordPress plugins, mass scanning for a newly disclosed flaw now frequently begins within hours of the advisory going public.
A scan that runs tonight tells you tomorrow morning about something attackers started probing yesterday afternoon. The scan is not wrong; the cadence is. And on a portfolio, the delay is multiplied by the number of sites carrying the same component.
The second problem is ranking. Scanners report per site and rank by CVSS score, which has no knowledge of your business. A critical flaw on a staging copy outranks a medium one on a store taking a thousand orders a week, and a human has to correct that judgement every single morning.
What continuous matching changes
- Notification within minutes of a disclosure, not at the next scan
- One issue affecting eleven sites shown as one item, not eleven rows
- Ranking by affected sites and what those sites do
- Exposure window measured from disclosure, not from detection
- Patch status tracked across the portfolio in one view
- Evidence retained for client reporting and audit
Inventory first, then matching, then ranking
The inventory is what makes this possible. Everything else is a query against it.
Live component inventory
Every connected site reports its WordPress core version, every plugin and theme with its exact version, and its PHP version. The inventory updates when a site changes rather than when a scan runs, so it is never more than minutes stale.
Continuous disclosure matching
Published vulnerability data is matched against that inventory as it arrives. Version ranges are matched precisely, because being on 4.2.1 when only 4.2.0 is affected is the difference between an incident and a non-event.
Consequence ranking
Severity is combined with how many sites are affected, whether those sites take payments or hold personal data, whether exploitation requires authentication, and whether a public proof of concept exists.
Patched through safe updates
Patching runs through the same verified workflow as any other update: restore point, patch, health and visual checks, automatic rollback on failure. Speed and caution stop being a trade-off.
What is monitored
Plugin and theme vulnerabilities
Continuous matching against published disclosures for every component on every connected site.
Core and PHP versions
Sites behind on WordPress core or running end-of-life PHP, surfaced before a host forces the upgrade.
Portfolio grouping
A single vulnerable component across many clients presented as one item with one action, not scattered across site views.
Exposure windows
Time from public disclosure to patch applied, per issue and as a portfolio average. The number that actually measures your risk.
Payment path weighting
Disclosures affecting checkout or payment extensions ranked higher, because the consequence is direct revenue loss.
Client evidence
Every detection and patch recorded with timestamps, ready for the monthly report or a client asking how long they were exposed.
Why this and security scanning are different things
Vulnerability monitoring answers whether the software you run has publicly known flaws. It is an inventory problem: match what is installed against what has been disclosed. It requires no access to file contents and produces no false positives beyond version ambiguity.
Security scanning answers whether a site has already been compromised: modified core files, injected content, unfamiliar files in uploads, unexpected administrator accounts. It is a forensic problem, and it is inherently noisier.
Both matter and they catch different things. Vulnerability monitoring is preventive and cheap to act on. Security scanning is detective and usually means something has already gone wrong. An agency running only the second is finding out too late.
What this does not do
- Runtime firewalling or request blocking
- Hands-on malware removal, which is a specialist service
- Detecting zero-day flaws with no published disclosure
- Custom or bespoke plugin code with no public advisory
- Server hardening, which sits with your host
Questions about vulnerability monitoring
Vulnerability monitoring is preventive: it matches what you run against what has been publicly disclosed as flawed. Security scanning is detective: it looks for signs a site has already been compromised. Both are worth having, and running only the second means finding out too late.
No, and nothing that works from public disclosure data can. It catches known flaws with published advisories, which is the overwhelming majority of what actually compromises WordPress sites. Zero-days exist but are not the common case for small business sites.
Bespoke code has no public advisory to match against, so it is not covered here. Code review and secure development practice are the answer for custom components, and it is worth knowing which of your sites carry them.
Minutes rather than weeks, because patching runs through the safe-update workflow with a restore point and automatic rollback. The thing that normally slows agencies down is fear of breakage, and that is exactly what verification removes.
Close the gap between disclosure and patch
Continuous inventory matching across every site, ranked by real exposure, patched through a workflow that verifies itself.
Free during early access. No credit card required.