How the CVE data is made
SecAI’s vulnerability findings come from four outside feeds and one fact SecAI collects itself: the packages installed on each server it watches. Every stored fact carries the name of the source that stated it, a weaker source never overwrites a stronger one, and where no source has stated a fact it stays empty and the page says so. Last reviewed 5 October 2026.
The one fact SecAI collects itself
The agent sends the server’s installed package list, read from the system package manager (dpkg on Debian and Ubuntu, rpm on Rocky Linux and AlmaLinux), with its ordinary reports. Every 12 hours the platform matches that list against OSV, asking by the distribution release the server runs, because the same package version is vulnerable on one release and patched on another.
Two details decide whether the answer is true. OSV keys Ubuntu records by source package while dpkg reports binary packages, so a retired source package that shares a binary’s name matches the wrong record; SecAI therefore checks the advisory’s own list of binaries and compares versions the way dpkg orders them. A server was once reported exposed to a resolver flaw while running a build twenty-one point releases past the fix, and that is the check that came out of it. And a package the advisory says is already past the fixed version is recorded as patched, which closes any finding an earlier scan had opened for it.
Only what the package manager knows is matched. Software installed from source, through a language package manager, or inside a container is not in that list and is not scanned, with one exception: WordPress plugins and themes, which have a feed of their own.
The four feeds, and what each is allowed to say
| Source | What it states | How often SecAI reads it | Note |
|---|---|---|---|
| OSV.dev (Google) | Which advisories affect a package at a version, per distribution release; the fixed version where one exists | Each scan cycle, every 12 hours, with answers cached for 24 hours | Up to 1,000 package lookups in one request |
| NVD (NIST) | The CVSS score and vector and the CWE weakness class, which no other source states as the assigning authority | Every 6 hours, 120 CVEs a pass, one request every 1.2 seconds, and only when SecAI has an API key | A CVE NVD had nothing on is asked about again after 30 days |
| CISA KEV | Whether somebody has been observed exploiting the CVE | For each CVE, at the first 12-hour scan cycle after its last check is 24 hours old | An observation, not an estimate |
| FIRST EPSS | The probability the CVE is exploited in the wild in the next 30 days | Same as KEV: each CVE once its last check is 24 hours old, including the CVEs with a page of their own | A probability about the world, not about your server |
| Wordfence | Vulnerabilities in WordPress plugins and themes | Daily | The one feed for software outside the package manager |
OSV is asked in bulk: the fleet’s packages are collected into one request of up to 1,000 lookups, and each distinct advisory is fetched once and kept, refetched only when its modification time moves. Two cases deliberately leave work undone rather than write something wrong: a batch whose results do not line up with its queries is discarded whole, because a misaligned batch files one package’s vulnerabilities under another’s name, and a lookup one of whose advisories could not be fetched is not cached at all, because a short answer reads as “fewer vulnerabilities than there are” and would be believed for a day.
Which source wins
Sources disagree, and some are better witnesses than others. NVD is the assigning authority for a CVSS score and a CWE. A distribution advisory is authoritative about its own packages and is relaying somebody else’s score for the CVE itself. So each fact is stored with its source, and the rule is simple:
- A weaker source never overwrites what a stronger one stated. NVD ranks 3; OSV and Wordfence rank 2; a fact with no named source ranks below both.
- An empty field is always writable. An absent fact belongs to nobody.
- A source of equal standing may refresh its own field. Advisories get corrected.
What a severity means on a finding
The severity word on a package finding (critical, high, medium, low) is the distribution’s own rating from the advisory, where it gives one. SecAI does not turn a CVSS vector into a tier itself; a vector without a stated number is left as a vector, and a finding with no rating from any source is shown as unknown, not rounded to medium.
CISA’s Known Exploited Vulnerabilities list is an observation that somebody has exploited the CVE, and it may raise a finding to high. EPSS is a probability about the CVE in the world and says nothing about whether this server exposes the software, so it never raises a rating; it decides which finding you are told to look at first, named with its package and with whether a fix exists. The first version of this logic did let EPSS raise ratings; previewed against the live fleet it would have moved six of eight servers from medium to high on an estimate, and it was not shipped.
A distribution advisory such as a USN or an ALSA is not a CVE id and neither exploitation feed indexes it. It is read through the CVEs its record names: on CISA’s list if any of them is, as likely to be attacked as the likeliest of them. An advisory that names no CVE is counted as not indexed, never as “not exploited”, which nobody established.
Why a CVE can stay unscored
Because nobody has scored it. NVD stopped enriching most CVEs published before March 2026 and moved them to a “not scheduled” state, so “no score” is a common and honest answer. SecAI records that NVD was asked and leaves the CVE alone for 30 days, however empty the answer; a lookup that failed is not an answer and is retried on the next pass. The pages SecAI publishes are asked about first, because a fleet backlog of several hundred would otherwise keep twenty pages waiting for ever.
Noticing when a feed goes quiet
The worst failure a security product can have is not being wrong; it is being stale and silent. Every pull from every feed is recorded, with how many records it returned, and kept for 90 days. Two questions are asked of that record:
- Stale: has the feed been heard from inside about three times its own period? One missed pass is not an alarm; three are.
- Quiet: did the last pull succeed and return less than a quarter of what this feed usually returns? That is what a feed looks like when it has been switched off at the other end. It is only asked where there is enough history to know what normal is.
| Feed | Counted as stale after |
|---|---|
| OSV package scan | 36 hours |
| CISA KEV and EPSS | 36 hours |
| NVD | 24 hours |
| Advisory facts behind the public pages | 72 hours |
| Wordfence | 96 hours |
A feed that stops answering does not stop the findings. They keep going out carrying what was last known, which is exactly why the silence has to be visible to the people running SecAI.
The public vulnerability pages
The vulnerability pages answer one question per package and release: which version fixes it, and what do I type to check my own box. They cover 12 pieces of software on 6 releases (Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Debian 12 (bookworm), Debian 13 (trixie), Rocky Linux 9, AlmaLinux 9) and 20 individual CVEs, with the advisory facts re-read daily from the same OSV data the scan uses. They are written by hand from public advisory data and touch no customer: a page can say which version fixes a flaw, never who has it.
- No page per CVE. Tens of thousands of CVEs are published a year and six sites already mirror that database; a page per row would be a worse copy of theirs.
- No upstream advisory text. The version data is cited as what it is; every sentence of writing is SecAI’s.
- No per-CVE kernel page. Debian alone carries thousands of kernel advisories, and “which version fixes it” has a different answer for every flavour.
- The free assessment does not check packages against CVE data. It is one read-only pass that does not look at the package list; the matching described on this page is what the installed agent does.
Questions people ask
| Where does SecAI get its CVE data? | From four outside feeds and one fact it collects itself. The agent reports the packages installed on each server; OSV.dev says which advisories affect each package and version on that distribution; NVD supplies the CVSS score and the CWE; CISA's Known Exploited Vulnerabilities list says whether a CVE has been seen exploited; FIRST's EPSS gives the probability it will be; Wordfence covers WordPress plugins and themes. Every stored fact carries the name of the source that stated it. |
|---|---|
| How often does SecAI check my packages against new CVEs? | Every 12 hours. The agent sends the package list with its reports, and the platform matches it against OSV, with answers cached for 24 hours so the same package at the same version is looked up once a day across the whole fleet rather than once per server. |
| Why does a CVE page say nobody has scored it? | Because nobody has. SecAI only shows a CVSS score a source actually stated, and NVD, the assigning authority, stopped enriching most CVEs published before March 2026. A distribution advisory often carries a vector with no number, and a vector cannot honestly be printed as a score. Where the fact is absent the page says so rather than guessing. |
| Does SecAI raise a finding to critical because EPSS is high? | No. A high EPSS score would have moved most of the fleet from medium to high on an estimate about packages that may not even be listening. Being on CISA’s Known Exploited Vulnerabilities list may raise a finding to high; EPSS only decides which finding you are told to look at first, named with its package and whether a fix exists. |
Read next
See what your own server runs
One read-only command, no account. It reports what an attacker would find, and changes nothing.