How the server security score is calculated
SecAI scores a Linux server out of 100 from a free, read-only assessment. Every check that ran puts a published number of points at stake: a check that passed earns all of them, a weakness earns half, and something serious earns none. The score is the earned points as a percentage of the points at stake. A check that did not run is in neither total, and any serious finding holds the score at 49 or below. The whole table is below. Rules version 1.0.0, last reviewed 23 September 2026.
The rules, in full
- Every check that ran puts its points at stake.
- A check that passed earns all of them.
- A check that found a weakness (AMBER) earns half.
- A check that found something serious (RED) earns none.
- The score is those earned points as a percentage of the points at stake, rounded.
- Any RED finding holds the score at 49 or below, however much else passed.
- A check that did not run is in neither total. An unknown is not a pass.
That last rule is the one people ask about. The assessment reads what a server will tell a read-only script in one pass. If SSH was not running, no SSH check ran, and the server is neither rewarded nor punished for a question it was never asked. It also means two servers' scores are not strictly comparable: they may have answered different numbers of questions. The number of checks behind a score is shown with it.
What each check is worth
The weights are judgements about how much each thing matters on a Linux server facing the internet, not measurements. They are set once, published here, and versioned: changing one changes every future score, so the version a server was scored under is stored with its result.
The column adds up to 165, but no server puts all of it at stake. 3 of these checks appear in a result only when they find something. They are marked below, and they are never a pass. A server where none of them applies has 135 points at stake, less any check that did not run at all.
| Check | Points | What it asks |
|---|---|---|
| Web shells | 15 | Known web shell signatures in web roots (sampled). |
| Library preload | 12 | /etc/ld.so.preload is set. A classic rootkit technique. |
| Suspicious processes | 12 | Processes running from temp directories, or matching known miner names. |
| Scheduled tasks | 12 | Cron entries running interpreters or downloaders from hidden or temporary directories. |
| Root-equivalent accounts | 12 | An account other than root with user id 0. Appears only when it finds something, so these points are at stake only on a server where it already has. |
| Accounts | 12 | Accounts with an empty password. |
| Setuid binaries | 8 | Setuid files in user or temporary directories. |
| Locked system files | 8 | The immutable attribute set on system files. A way to survive cleanup. Appears only when it finds something, so these points are at stake only on a server where it already has. |
| SSH passwords | 10 | Whether SSH accepts passwords as well as keys. |
| Host firewall | 10 | Whether a host firewall is active. |
| Security updates | 10 | Security updates waiting to be installed. |
| Operating system support | 10 | Whether the distribution still receives security updates from its vendor. Appears only when it finds something, so these points are at stake only on a server where it already has. |
| SSH root login | 8 | Whether root may log in over SSH directly. |
| Exposed data services | 8 | Database or cache ports listening on all interfaces. |
| Web files | 6 | World-writable files under web roots (sampled). |
| Backups | 5 | Whether a backup tool or scheduled backup job exists. |
| Firewall tooling | 4 | Whether nftables or iptables is present, so blocking is possible at all. |
| Disk space | 3 | Whether the root filesystem has room for logs and updates. |
What the assessment checks but does not score
These appear in your result and are worth reading. They carry no points, for a reason given against each. A number that moves on things you cannot act on, or on SecAI's own requirements, is a number that tells you nothing.
| Check | Why it carries no points |
|---|---|
| Operating system | Whether SecAI’s installer accepts this release. That is a fact about SecAI, not about your security. |
| Service manager | Whether systemd is present for the agent to run as a unit. Same reason. |
| Reach SecAI | That the server reached this endpoint. It is how the assessment ran at all. |
| Control panel | cPanel, Plesk or DirectAdmin detected. Context, not a grade. |
| Clock | Time synchronisation. Reported as context; it does not move the number. |
| Automatic updates | Whether unattended security updates are on. Context: the score already counts the updates actually waiting. |
| Brute-force protection | fail2ban, CrowdSec or CSF. Context, because SecAI provides this itself once installed, so scoring it would be marking our own homework. |
| Updated services | Processes still running a binary that was updated on disk. Reported as context. |
What it does not look at
One read-only script, running for about a minute, cannot see everything. These four are the honest gaps; a server can score 100 and still have a problem in any of them.
| Not measured | What that means |
|---|---|
| Logging | Whether logs are kept, shipped or complete. |
| Kernel | The running kernel against known kernel vulnerabilities. |
| Known vulnerable packages | Installed packages against CVE data. The agent does this once installed; one pass of a read-only script does not. |
| Web server | Web server software, its version and its configuration. |
What the score is not
- Not a probability. It does not say how likely a break-in is. It is a weighted count of what one look found.
- Not a compliance result. No framework awards points this way. SecAI's compliance reporting is control-by-control and says "not assessed" where it cannot see, rather than averaging it into a figure.
- Not a verdict. GREEN, AMBER and RED still answer "can SecAI be switched on here". The score is what tells one AMBER server from another, and what shows a month of work.
- Not the dashboard's risk score. That one comes from an AI security audit of a monitored server and runs the other way: 0 is clean, 100 is critically compromised.
- Not a promise. A server that scores 100 passed every check that ran. It was not proven secure.
Where the number comes from
You run one command on your own server. It downloads a signed, read-only collector, which reads how the server is set up (whether SSH accepts passwords, whether a firewall is active, how many security updates are waiting, and the rest of the table above) and sends back about thirty yes/no signals. It changes nothing and installs nothing. The scoring rules run on SecAI's side, which is why they are published here rather than shipped in the script. Your result, including the score, is emailed to you with a link that opens it for thirty days.
The score is worked out once, when the assessment is scored, and stored with the rules version above. A later change to a weight does not silently rewrite a result you were already given.
Questions
A server with nothing to fix scores 100, because every check that ran passed. Most servers that have never been hardened land between 60 and 85: password logins, pending security updates and no firewall are the usual reasons. Any RED finding -- a sign that something has already happened on the server -- holds the score at 49 or below however much else passed.
Every check that ran puts a published number of points at stake. A check that passed earns all of them, a check that found a weakness earns half, and a check that found something serious earns none. The score is the earned points as a percentage of the points at stake, rounded. A check that did not run is in neither total. The full table of weights is on this page.
Yes. The score comes from one read-only pass that takes about a minute, and it does not look at logging, the kernel against known vulnerabilities, installed packages against CVE data, or web server software and configuration. It is a measure of what was checked, not a guarantee.
No, and they run in opposite directions. This score is 0 to 100 where 100 is good, from the one-off assessment. The dashboard’s risk score comes from an AI security audit of a server the agent is already monitoring, and runs 0 to 100 where 100 is worst.
Read next
Score your own server
One read-only command, no account, no card. You get the verdict, the score, and the reasons behind both.