Understanding findings
Types, ratings, lifecycle – and what you can do with a finding.
A finding is a concrete observation on a concrete device: "SSH allows root login", "openssl has a known vulnerability", "/etc/hosts has changed".
The six types #
| Type | What it means |
|---|---|
| Vulnerability (CVE) | An installed package is affected by a known security hole |
| Update available | A newer version exists, without a known hole |
| Hardening | A setting makes the system more attackable than necessary |
| Recommendation | No acute risk, but better solved – updates, time sync, disk space |
| Integrity | A monitored file has changed |
| Change | Something shifted on the system: new packages, new ports, new accounts – or a log signal jumped sharply |
The five ratings #
Critical – something is open and actively exploited or trivially exploitable. High – serious, should be done this week. Medium – belongs on the list. Low – polish. Info – an observation, no action needed.
The rating is not fixed. The same open database port weighs more heavily once you have confirmed the system is reachable from the internet – and less if a firewall sits in front. That is exactly what the questions on the device are for.
Why there is no overall grade #
Until mid-2026 a score stood here: 100 points, a deduction per finding, one number per device. It has been abolished.
The reason is simple: the number was invented. Why a critical finding should cost 40 points and a high one 20 – rather than 50 and 10 – could not be argued, only decreed. An invented weighting looks like a measurement, and that is exactly the problem: two devices with the same number could be in entirely different shape, and a device climbing from 70 to 75 had gained nothing but five points.
What stands there instead is countable: how many findings are open, at which severity, since when, and what has changed since the last run. That can be recalculated and refuted – a grade cannot.
Accepted and postponed findings still stand on their own, with a reason and a deadline – more on that below.
The lifecycle #
A finding appears when a condition holds and disappears when it no longer does. In between there are a few states:
| Status | Meaning |
|---|---|
| Open | holds, nothing decided |
| Fixed | no longer observed on the last run |
| Reopened | was fixed, is back (a regression) |
| Risk accepted | you know about it and leave it |
| Postponed | deferred, returns on the due date |
The scan is the truth, not the click. You do not have to mark anything as done. Apply the fix, and the next run closes the finding by itself – with a timestamp. If it comes back, it is reopened.
And if data is missing? Then the finding is not counted as fixed. If a check could not run for lack of data – because a requested configuration output was missing, say – its finding stays open. A finding that disappears because data is missing would look like success.
What you can do with a finding #
Fix it. The commands are right there. Where several sensible paths exist, all are listed and one is marked as recommended. See Fixing findings.
Postpone it. "Not now." You choose a deadline between a week and half a year. Until then the finding rests, does not count as open and triggers no alert. After that it is back – without a reminder it would be a deletion with a nicer name.
Accept the risk. "I know about this and I am leaving it." This only works with a reason. Not out of formality: in three months nobody could otherwise say whether the decision was sound – including you. Reason, name and timestamp are stored.
Both are reversible at any time. And neither holds against a new situation: if the rating of the same finding rises to high or critical, it is reopened and wants a fresh decision. Whoever accepted a low risk did not accept a high one.
For integrity findings: confirm as intended. If the change was yours, the new state becomes the reference point. See Integrity and changes.