Troubleshooting
Why is this still open?
I updated, but the finding is still open
| Situation | Why | What to do |
|---|---|---|
| Kernel updated | Only the running kernel counts. Until the host boots the new kernel, the old one is still the one that runs, and still vulnerable. | Reboot the host (in a maintenance window). The finding closes with the next report after the reboot. |
| Windows update installed | The update is installed but needs a restart to take effect. The finding shows Fixed restart pending. | Restart the host. |
| A library was updated (for example OpenSSL), but services were not restarted | Running services still use the old library in memory. The host shows that a restart is needed. | Restart the affected services, or the host. |
| The update was a different branch | The installed branch gets no more fixes (end of life). The finding says "No fix in the installed branch (EOL)". | Move to the minimum safe version shown on the finding. |
| Not yet reported | The agent reports every 5 or 15 minutes. | Wait for the next report, or check that the agent is online. |
| CustomBuild (DirectAdmin) component patched | A backport only counts when the patch file is present and the running program is proven to be built with it. Agents before version 0.3.62 do not report this. | Rebuild the component with CustomBuild; update the agent. |
| A temporary fix is active | The finding is Mitigated, not fixed: the vulnerable version is still installed. | Apply the real update when it is available. |
| An exception expired | Accepted risks have an expiry date; afterwards the finding opens again. | Fix it, or accept it again with a new reason. |
Another scanner says it is vulnerable, SEK Systems does not
Usually backports. Linux distributions fix vulnerabilities in the version they ship, without changing the upstream version number. A scanner that compares upstream versions reports these as vulnerable. SEK Systems uses the distribution's own security data: when Debian, Ubuntu, Red Hat or another distribution states that your package version is fixed or not affected, SEK Systems follows that. See Vulnerability matching.
Other reasons:
- Not the running kernel: an installed but unused kernel produces no CVE findings (it gets a hardening recommendation to remove it).
- Not your platform: a CVE that only applies to another operating system.
- No authoritative source: packages that SEK Systems cannot assess produce no findings at all; the Coverage figure shows how much of a host is covered.
SEK Systems says it is vulnerable, but I think it is a false positive
- Open the finding and read Evidence: the source statement, the installed version and the fixed version, and the version comparison.
- For software outside the package manager (installed by hand, from a third-party repository, or by a control panel), SEK Systems compares upstream versions and cannot know about a backport by the vendor. The confidence is lower, and sometimes the status is Unknown instead.
- If you are sure it does not apply, an admin can Accept risk… with the reason and an expiry date, so it is documented and comes back for review.
- Tell SEK Systems support: wrong matches are fixed for everyone.
Why is the score so high (or low)?
Every finding has Why <score>?: the base (CVSS), the exploitation signal (KEV, EPSS, SSVC), NCSC advice, and the exposure (L×R) of the software on this host. The same CVE can therefore score differently on two hosts. See Risk and priority.
Why is a fix "coming" or manual?
Not every vulnerability has an automatic fix: the vendor may not have released one yet, the software may be outside the package manager, or the fix needs a step SEK Systems does not automate (for example a firmware update or a change on network equipment). The finding then shows the manual steps, and temporary fixes from the catalogue where available.