How it works
Vulnerability matching
Matching answers one question per installed package: is this exact version affected by this CVE, and what is the first version that is not? Getting that right is what separates real findings from noise.
Sources
SEK Systems reads public sources continuously and only processes what changed:
| Source | For | Checked every |
|---|---|---|
| Debian security tracker, Debian ELTS | Debian | 10 minutes, 1 hour |
| Ubuntu security data | Ubuntu | 30 minutes |
| Red Hat security data (CSAF) | RHEL and rebuilds | 15 minutes |
| AlmaLinux, Rocky Linux, Oracle Linux, SUSE, Alpine, Arch Linux | those distributions | 30 minutes |
| Fedora | Fedora | 1 hour |
| Microsoft Security Response Center | Windows and Microsoft products | 1 hour |
| CVE List (CVE records, CVSS from the CNA, CISA's SSVC assessment) | all | 15 minutes |
| CISA Known Exploited Vulnerabilities (KEV) | exploitation in the wild | 5 minutes |
| FIRST EPSS | probability of exploitation | 1 hour |
| NCSC-NL security advisories (signature-checked) | likelihood and impact | 15 minutes |
| OSV | language packages: npm, PyPI, Maven, Go, Cargo, RubyGems, NuGet, Packagist | 1 hour |
| NVD product data (CPE) | software outside a distribution | scheduled |
| DirectAdmin CustomBuild releases | control-panel software | scheduled |
| End-of-life data | whether an OS or product version still gets updates | scheduled |
No customer information is sent to these sources: SEK Systems downloads the public data and matches it locally.
New vulnerabilities, without waiting for a scan
The inventory of every host is stored. When a source publishes something new or changed, only the affected records are queued and matched against the stored inventory, within about a minute after the source was read. So a new CVE that affects your hosts shows up within minutes of its publication in the source, without a new scan. The other way round, a changed inventory (for example a new package) is matched as soon as it arrives.
The distribution decides for distribution packages
Linux distributions often fix a vulnerability by backporting the patch into the version they ship, without
changing the upstream version number. OpenSSH 8.9p1-3ubuntu0.10 can contain fixes that upstream only has in a much
newer version. A tool that compares against the upstream version reports such packages as vulnerable: a false positive.
SEK Systems therefore uses the distribution's own statement for distribution packages: "fixed in version X of our package", "not affected", "will not fix". That statement wins over generic data. The key is the source package and the release of the distribution, so binary packages built from the same source share the verdict.
Version comparison per package format
Version strings are compared with the exact rules of each package manager, implemented in SEK Systems itself:
| Format | Rules include |
|---|---|
| dpkg (Debian, Ubuntu) | epochs, ~ sorts before everything, upstream version and Debian revision |
| rpm (RHEL, SUSE, Fedora…) | epochs, the rpmvercmp segment rules, tilde and caret |
| apk (Alpine) | suffixes such as _alpha, _rc, _p, and the -r revision |
| pacman (Arch) | epochs and the pkgrel |
| portage (Gentoo) | suffixes and revisions |
| Language ecosystems | semver, PEP 440 (Python), Maven and others |
| Windows | build number and update revision (UBR), and which update supersedes which |
The comparators are tested against the real tools of each distribution with automatically generated version pairs (differential fuzzing), so they agree with what the package manager itself would decide.
Software outside a distribution
For software from third-party repositories or installed by hand, there is no distribution statement. SEK Systems then matches the upstream version against OSV or the NVD product data. These matches carry a lower confidence, and when the version cannot be determined reliably the finding is Unknown rather than a guess.
CustomBuild backports
DirectAdmin's CustomBuild compiles PHP and other components itself and can apply security patches to an older version. A CVE then counts as fixed only when both are true: the patch file for that CVE is in CustomBuild's patch directory for that version, and the running program is proven to be built with exactly that patch set. Such findings show Fixed by backport. This requires agent version 0.3.62 or later.
Kernels: only the running kernel
A host often has several kernels installed, but only one runs. SEK Systems matches kernel vulnerabilities only against the running kernel, at its exact version. Older kernels that are installed but not running produce no CVE findings; instead there is one hardening recommendation to remove them.
The consequence: after a kernel update, the findings of the old kernel stay open until the host is rebooted into the new kernel. That is correct: the old kernel is still the one that runs. See Why is this still open?.
Minimum safe version
For each vulnerable package, SEK Systems calculates the minimum safe version: the lowest version above the installed one that is affected by none of the open CVEs, across all of them at once. Fixing CVE by CVE could otherwise lead to several upgrades in a row.
- If the installed branch gets no more fixes (end of life), the advice moves to the next supported branch, with the note "No fix in the installed branch (EOL)". For example PHP 7.4 to a supported 8.x version.
- Versions that are only available with a paid support contract are skipped.
Coverage
A package for which no authoritative source exists cannot be judged, and never produces a finding. The Coverage figures (Overview, Agents, host Summary) show what share of your packages SEK Systems can assess, so you know where it is blind.