Finding vulnerabilities without touching the servers
“No vulnerabilities found” is a reassuring sentence – and one of the most dangerous a tool can produce. It is also true when nothing was really looked for. How LCM checks its servers’ package inventory for known vulnerabilities therefore comes down to three questions: where does the scan run, what is a finding worth, and how fresh is the data?
The scan does not happen on the servers at all
LCM manages servers agentlessly over SSH and already keeps a record of every installed package. For the CVE assessment, an SBOM – a bill of materials for the software – is generated per server from those records and checked against the Trivy vulnerability database locally on the LCM host.
The managed servers are not contacted again for this. Nothing has to be installed, opened or additionally executed; the scan burdens neither the machines nor the maintenance window. By default it runs daily at four in the morning, and the time is configurable.
More important than the schedule, though, is the second trigger: as soon as LCM updates packages – by hand or by rule – the inventory is read in again and the server’s assessment is rebuilt immediately. Otherwise the red label would hang for days on a hole that has long since been closed.
The scanner runs locked in
A vulnerability scanner is third-party code that is updated regularly – and as a child process of LCM it would run with the same privileges. That would give it access to the directory where the database and the master key live, and from those the SSH keys and passwords of every managed server could be decrypted. Supply-chain attacks on developer and admin tooling are not a theoretical concern, and a scanner makes an attractive target.
LCM therefore starts it in a sandbox. Visible to it is only what the scan
genuinely needs: the binary, the system libraries, the generated SBOM, the
database cache and its own empty /tmp. Everything else is not merely
forbidden for that process but simply not there – an attempt to read it
ends in “file not found”, not “permission denied”.
On top of that comes the network separation: the SBOM scan evaluates only the local database and runs entirely without network access. Even a tampered scanner would have no way out.
This is implemented with bubblewrap, falling back to Landlock. If neither is available, the scan runs unconfined – but with a visible notice on the scanner display. A silent fallback would be the worst variant: you would believe yourself protected without being so.
Not every finding weighs the same
The security page shows the raw assessment exactly as the scanner delivers it. For the traffic light and for alerts, however, LCM weights findings by context – otherwise the urgent drowns in background noise:
- CVEs in container images do not count by default. Isolation limits the damage, and the contents of an image are its publisher’s responsibility. Anyone who wants individual containers judged differently marks them as CVE-relevant – then they count at full severity.
- CVEs in exposed packages count one tier higher. Web servers, reverse proxies, mail, DNS and database services. The list is editable, and on top of that LCM detects by itself which packages listen on externally reachable ports.
Independently of individual findings, a server turns red when its distribution no longer receives security updates, or falls out of support in less than a month. And above the green “OK” there is one more tier: “Excellent” – not a single known CVE, SSH hardened, firewall active.
How old is the database?
Trivy downloads its vulnerability database itself. When that fails – no network, a proxy, a rate limit – the scan does not abort; it carries on with the old database. The result is then not called “error” but “no vulnerabilities found”.
A three-week-old database therefore looks exactly like a genuinely clean server in the overview. Which is why LCM makes the state visible:
| Age of the database | Rating | Effect |
|---|---|---|
| under 48 hours | current | no display |
| from 48 hours | stale | warning on the security page, notice per server, alert |
| from 7 days | critical | the same, more prominently |
What counts here is when the vendor built the database, not when this host fetched it. Downloading the same old database every day still leaves you with old data.
The individual servers’ traffic lights stay untouched by this, incidentally. A stale database is a problem of the LCM host; colouring in every server because of it would report a single cause many times over as a server problem.
One special case to close: the running kernel
After a kernel update the new kernel is installed, but only takes over after a reboot. The package list then reports “everything up to date” while the machine keeps running the old kernel – including the holes the new one closes.
LCM keeps the two apart: the running kernel comes from uname -r, the one
source that cannot be mistaken about it. The installed kernels sit next to
it as their own list, each marked as running, waiting for reboot or
fallback – the latter being what saves you when a new kernel refuses to boot.
Further reading
The full description is in the documentation under Security & CVE scans, and the reasoning behind the traffic light under Status calculation. An overview of LCM is on the product page; to try it out, the demo system is at lcm-demo.techeve.de.