Docs · Security score
The score is a single number so that a fleet can be sorted and a trend can be read at a glance. A single number is only useful if you know what moved it, so here is the whole method — the weights, the grouping, the discounts and the caps — as it runs in the product. None of it is secret, and it is calibrated against real servers rather than a benchmark: the aim is that the number keeps separating “bad” from “worse” instead of collapsing to zero the moment a host has a few problems.
In one paragraph
Open findings cost a weight by severity. Findings about the same package share a bucket with diminishing returns, and the kernel family is one bucket. CVEs that cannot be patched in place cost 40%. The total maps to 0–100 on a decaying curve. On servers, the libraries inside hosted sites are scored as a separate layer that caps the headline at 85 or 70 rather than driving it down, and a confirmed compromise caps everything at 15.
Resolved, acknowledged and false-positive findings are ignored. Two categories never move the score at all: a scanner that could not run (SRV_SCAN_ERROR) and an agent that is offline. Those are reported loudly as findings — an uncheckable server is not a safe server — but they describe our visibility, not your exposure, so they are kept out of the number.
Critical 30, High 16, Medium 7, Low 3. CVEs in compiled system binaries (Go and Rust programs, Java archives) cost a flat 6 regardless of severity: they are real, but they are not something apt or dnf can fix and they rarely represent a reachable attack path on a server.
A bucket is one package or one component. Within a bucket the heaviest finding counts in full, the next at half, the next at a quarter, and so on. The whole kernel family — kernel, kernel-core, kernel-modules, kernel-tools, kernel-devel — collapses into one bucket, because one kernel is not four separate disasters. Twenty distinct vulnerable packages, on the other hand, are twenty buckets and score accordingly.
Two kinds of CVE are discounted to 40% of their weight. First, findings where no fix exists anywhere — the tail of an end-of-life distribution, or a package the upstream has abandoned. These are real risk but not the operator's immediate, in-place fix; on an end-of-life system the action offered is an OS upgrade, and the finding stays open rather than being acknowledged away. Second, CVEs in an installed but not running kernel: an old kernel left on disk by the package manager is not executing, so it is discounted and shown separately until it is removed or ages out. Kernel packages that never execute at all (headers, devel) are ignored.
The weights are summed into a damage figure and mapped to 0–100 with a decaying curve (100 × e^(−damage / 115)). A single critical CVE on an otherwise clean host lands in the high 70s; a handful of serious problems is visibly amber; it takes a genuinely neglected estate to reach the floor. The curve exists so that the score keeps discriminating between bad and worse instead of saturating at zero.
Everything about the box itself — OS packages, kernel, SSH and firewall configuration, malware and rootkit scanners, web-server and TLS checks — is the host layer, scored exactly as above. Vulnerable libraries inside the applications the box hosts — Composer packages under a WordPress plugin, a Rails app's gems, a Node app's node_modules — are the hosted-sites layer. In that layer every dependency finding under one site's document root shares one bucket, so a site with twelve vulnerable libraries is one problem with diminishing returns, not twelve. Libraries bundled inside a WordPress plugin or theme are discounted to 40% in the same way as no-fix CVEs, because only the plugin's author can ship the update; a site's own dependencies count in full, because the site owner can run composer update or npm audit fix today.
The headline score is the host score, limited by a ceiling from the hosted-sites layer: sites scoring 85 or above impose no ceiling; 60 to 84 caps the server at 85; below 60 caps it at 70. Bad sites therefore always show on the server — a spotless host full of neglected WordPress installs cannot read 100 — but a shared host with fifty sites is no longer pinned to zero by other people's plugins, and the number still tells you whether the host itself is patched. The server page shows both layers and the cap under the score.
Unambiguous detections — malware found by ClamAV or maldet, a confirmed rootkit detection (not rkhunter's advisory warnings), search-engine blacklisting, database injection, defacement — mark the host or site as compromised and cap the score at 15. That is a floor on the truth, not a penalty: a fully patched server with a webshell on it is owned, and the score should say so. Signals consistent with tampering but not conclusive (SEO cloaking, a script served from a raw IP) show a Suspicious badge without changing the score.
It is not a probability of breach, and it is not comparable between two servers with different roles — a database host with no web surface and a shared WordPress host are measured on the same scale because that is what a fleet view needs, not because their risk is equivalent. Read the score with the findings beneath it: the score tells you where to look first, the findings tell you what to do.
Acknowledging a finding removes it from the score but keeps it in view, marked as reviewed with your note — you are recording an accepted risk, and the same status is what the automatic acknowledgements (backport-patched, live-patched, no fix available) use. Marking a finding as a false positive removes it from the score and from view. Either way the server re-scores immediately, and Reopen puts it back.
Related