Scores and findings

Severities

Every finding is one of four severities:

How the score is calculated

Each area starts at 100 and loses the cost of every problem found in it, floored at zero. The overall score is the mean of the areas that actually ran.

Subtracting is deliberate. Averaging the checks would mean a plugin that adds twenty passing checks raises everybody’s score without changing a single thing about the site — and a critical finding could be diluted into invisibility by enough passes around it. Under subtraction, a pass is worth exactly nothing, which is the honest value.

Scores map to a grade: A from 90, B from 80, C from 70, D from 60, and F below that.

Skipped checks

A check that couldn’t run is recorded as skipped, with the reason, and excluded from the score entirely. Every check is asked whether it can produce a meaningful result in this environment before it is run.

That distinction matters more than it looks. A shared host that won’t report its innodb_buffer_pool_size hasn’t got a small buffer pool — it has an unknown one, and scoring it down would be inventing a measurement. Common reasons a check skips:

• The site runs on PostgreSQL, so the database area has nothing to measure.
• The host disallows shell_exec, or shell probes are switched off, so CPU and memory can’t be read.
• The scan came from the CLI, where there is no HTTP request to inspect for compression or protocol version.
• The database user lacks the privilege to read a status variable.

Skipped is not the same as disabled. A disabled check never runs and never appears; a skipped one ran its availability test, could not proceed, and says so in the report.

Comparing scans

Findings carry a stable fingerprint, which is what makes “new since the last scan” possible — the same problem reported twice is recognised as the same problem, and a scan can be compared with its predecessor to see what appeared, what got worse and what was fixed.

This is also what the default notification setting is built on: email only when something new appears. Keeping some scan history is therefore worth doing; the retention setting defaults to 50.

What a score is for

The number is a way to see movement, not a target to optimise. A site that scores 74 because it runs on a small shared host with three notices and one warning is not in trouble. The findings are the substance; the score just tells you whether last month’s work helped.