Why a patched server becomes vulnerable while sitting still
Vulnerability is a relationship between your software and public knowledge, and only one side of that is under your control. You install a current version, and months later a researcher publishes a flaw in it. Nothing on the server changed. Its risk did.
This is why point-in-time scanning underserves servers. A quarterly scan means an exposure window measured in months, and the interesting CVEs are the ones disclosed the day after the scan ran.
The problem with reading CVE feeds instead
The alternative most teams try is following security feeds and mailing lists. It fails for a practical reason: the feed describes the whole world of software, and you need the intersection with the specific versions on your specific machines.
Working that out by hand across a handful of servers is a job nobody keeps up for long, and the answer changes daily. It is a matching problem, which is a thing computers are good at and humans are not.
How SecAI does it
The agent inventories installed packages using the system package manager, so the list reflects what is genuinely on the machine rather than what a build manifest claims. Debian and Ubuntu servers are read through dpkg and apt, and RHEL-compatible systems through rpm and the dnf or yum stack.
That inventory is matched against public vulnerability data in the platform rather than on your server, so the matching work costs your machine nothing and the data is current without you updating a local database.
Findings are reported per server by severity, so the question you can answer is the useful one: which vulnerabilities affect this machine right now, and which of them are serious.
What a finding carries, per server
Every vulnerability finding is tied to one server and one installed package: the package and the version actually on the machine, the CVE, its severity, the fixed version where the distribution has published one, and a summary of the flaw. Matching runs every twelve hours against OSV.dev, and vulnerability data is cached for a day, so a CVE published this morning is on the affected server's page by tomorrow without anyone starting a scan.
The inventory is reconciled, not only appended. A package that was removed stops being a vulnerability, and its CVEs go with it; an earlier version of the inventory only ever added packages, which produced findings for software that was no longer installed, and that is the kind of defect this page would rather admit than repeat.
Know when the software on your servers becomes vulnerable
New vulnerabilities are disclosed every day, and the useful question is never "what was published?" but "does this affect software installed in my environment, and what should I do about it?". Matching the installed inventory against the vulnerability database answers the first half continuously; the fixed version and the pending updates answer the second.
The matching is only as good as the database's knowledge of the distribution. SecAI matches Ubuntu, Debian, Alpine, Rocky Linux and AlmaLinux, each against its own advisories and by the exact release. OSV.dev's Red Hat data is organised by Red Hat product stream rather than by release, and SecAI does not map it yet, so on a Red Hat Enterprise Linux server SecAI skips rather than guesses, and says so, instead of matching against a neighbour's data and calling it coverage.
Combine vulnerability and runtime context
Vulnerability data becomes more useful when it is read next to what the same agent already knows about the server:
- Exposed services: whether the vulnerable package is listening on an address the internet can reach.
- Server role: a web server, a database, a control panel host, a build box.
- Observed activity: whether the process is running at all, and whether anything unusual has happened around it.
- Package state: whether an update is pending and what else it drags in.
- Configuration and posture: whether the exposure is mitigated by the settings around it.
Severity is a starting point, not the answer
A CVSS score describes a vulnerability in the abstract. It does not know whether the affected package is exposed to the internet on your server, whether the vulnerable code path is reachable in your configuration, or whether the service is even running.
A critical CVE in a package installed but never started is less urgent than a medium one in your internet-facing web server. SecAI reports severity alongside the context of the server, and the AI audits weigh exposure when prioritising, which is where judgement helps more than a raw score.
Patching is still your decision
SecAI reports vulnerabilities and can queue package installation as a remediation action. Whether that runs automatically depends on the protection mode you chose for the server, and package upgrades that could disrupt a running service stay behind human approval by default.
This is deliberate. Unattended upgrades are a good default for security updates on many servers and a bad idea on some, and a monitoring tool should not quietly make that call for a production database.