Security findings
Find the Craft sites that need attention first
Every report a site sends is run through a set of rules. Each one that matches opens a finding with a severity attached, and each finding closes on its own the moment the next report shows the problem is gone.
Fourteen days, no card. Craft CMS 5 and later.
Forty sites produce more signal than anyone reads
Given enough sites, the information you need is always technically available somewhere. Dev mode is on in production. A certificate renewal did not happen. PHP 8.1 went end of life and one site did not move.
None of it announces itself. It sits in a control panel nobody opened this month, and it is found either by looking deliberately or by an incident.
How findings work
-
A site reports
Inventory hourly, updates daily, runtime every six hours, failed sign-ins every thirty minutes. All of it initiated by the site, outbound only.
-
Every rule runs against the report
Eighteen rules, each one a small readable class in the public repository.
-
Matching rules open a finding
With a severity from low to critical, the site it belongs to, and when it was first seen.
-
You are told about the ones that matter
A new finding can raise an email or a webhook, filtered by severity, so a low-severity notice does not wake anyone.
-
Fixing the site closes the finding
No one has to remember to tick it off. The next report that no longer matches the rule resolves it automatically.
Every rule, and what it opens
All of them run on every report, on both editions. Each one is a small readable class in the public repository, so you can check what opens a finding before you rely on it.
| Finding | Severity |
|---|---|
| Craft security release outstanding | Critical |
| Disk almost full | High, rising to critical |
| Plugin security release outstanding | High |
| Dev mode on in production | High |
| PHP version past end of life | High |
| Site not reporting | High |
| HTTPS not enforced | High in production |
| Invalid or mismatched licence | High |
| Repeated failed sign-ins | High if an administrator |
| TLS certificate expiring or expired | High inside 7 days |
| Schema changes permitted in production | Medium |
| Pending migrations | Medium |
| Abandoned plugin installed | Medium |
| Accounts locked out | Medium |
| Slow response times | Medium |
| Failed queue jobs | Low |
| Updater enabled in production | Low |
| OPcache disabled in production | Low |
A finding closes automatically when the next report no longer matches its rule.
The eighteen rules
Severity is weighted, not counted
Twelve routine plugin updates never outrank one outstanding security release in the fleet ordering.
Certificates are checked from outside
The one thing Manager goes and looks at itself. It opens a TLS connection to the site's own hostname once a day, reads the certificate and closes. Nothing is sent and no response body is read, because TLS terminates at the edge and the connector cannot see what a visitor validates.
Acknowledging is deliberate
You can acknowledge a finding you have decided to live with, and it takes a recent password confirmation. Reopening does too. Both are recorded.
Environment is respected
HTTPS not enforced is high on a production site and low on a development one. A staging site does not generate production urgency.
Failed sign-ins are counts, never identities
Four numbers and a timestamp: attempts in the last day, accounts affected, accounts locked out, and how many of those are administrators. No username, email address or IP exists in the schema.
The outcome
You open one list, ordered by what actually matters, and it is shorter than you expect because everything already fixed has closed itself. You find out about a renewal that did not happen four weeks before a visitor does.
Read how it works
The documentation lives in the public repository, next to the code it describes, and every page carries a link to edit it.
Related
-
Craft and plugin updates across every site
See what is outstanding on every site, and which of it is a security release, without opening a single control panel.
-
Alerts for the issues that need a person
Four events, by email or webhook, filtered by severity. Queued, so a slow endpoint never delays a site report.
-
Know within fifteen minutes when a site stops reporting
Heartbeats every five minutes, TLS certificate expiry, disk space, response times and queue health.
See your whole fleet in about ten minutes
Add a site, install the connector with Composer, paste the one-time code. The first report arrives on the next run. Fourteen days free, no card, and nothing on your sites changes.
Craft CMS 5 and later. Read-only by default. AGPL-3.0-or-later.