Skip to main content

The corpus

The corpus is the CVE catalog that Wazuh CTI publishes, and Pharos keeps a live mirror of it: over 366,000 CVE records, the vendors, products and packages they affect, the verdict of every source that has ruled on each record, and the advisory activity behind each one.

What a record carries​

Every advisory source that has ruled on a record is normalized into it: the CNA that assigned the CVE, plus each Linux distribution and vendor security tracker that later weighed in. In practice that is around a dozen sources per the corpus as a whole, among them NVD, Red Hat, Canonical for Ubuntu, Debian, SUSE, Fedora, AlmaLinux, Oracle Linux and Rocky Linux. A given record carries only the ones that scored it.

The sources disagree, and Pharos does not pick a winner. NVD can say 10.0 where Red Hat says 5.3, so the CVE page shows every source side by side, each with its own score, CVSS version, vector and verdict, and calls out how far apart they are. Which verdict matters depends on what the fleet actually runs.

The single severity a record shows in the list is derived from those scores, not stored. It is the highest CVSS any source gave the record, mapped to critical at 9 and above, high at 7, medium at 4, and low below that. A record that no source has scored reads Not scored, which is its own state and not a low severity.

On top of what upstream publishes, Pharos adds three enrichments. The first is the EPSS exploit-prediction score published by FIRST, both a score and a percentile. The second is membership in the CISA KEV catalog of known exploited vulnerabilities, which carries a required action and a due date. The third is whether a public exploit is known.

Vendors, products and packages are browsable in their own right, on the three tabs of the Packages page. Vendor and product rows carry CVE, critical and KEV counts. Package rows carry CVE and KEV counts and where in the fleet the package is installed. Every row opens the CVE list filtered down to it. A product is counted per vendor, so openssl/openssl and redhat/openssl are two rows rather than one.

A count on screen is always the real total, never the page size. The CVE list and the three Packages tabs show 20 rows per page, and the pager under each one gives the true number of matches. The number beside a tab's name is the total that tab shows once opened.

Each Packages tab opens on the most affected rows. Clicking a column header sorts the whole tab on that column, highest first, then reversed, then back to the default. Every count sorts, and so does the name. On products the vendor and the date of the last CVE sort too, and on vendors the date of the last CVE. The search box filters by name, and on the products tab by the vendor/product pair, so redhat/ lists one vendor's products. The Filters button keeps only the rows with at least one CVE in the CISA KEV catalog, on every tab. On products and vendors it can also keep only the rows with at least one critical CVE, and on packages only what the managers report installed. The tab, the search, the filters, the sort and the page are part of the page address. Switching tabs keeps the search and clears the rest.

How fresh the mirror is​

Pharos mirrors Wazuh CTI. It is not a mirror of NVD, and it is never ahead of Wazuh CTI: a CVE appears in Pharos once Wazuh CTI carries it, which can be a day or more after the record is published elsewhere.

Upstream publishes its changes as an append-only stream, and Pharos checks that stream every hour. Upstream itself publishes in batches rather than continuously, typically about once a day, so the newest record in the mirror is usually from upstream's last batch rather than from the last hour. A corpus that shows nothing newer than yesterday is normally that, not a stalled sync.

Both facts are on screen, and they are different:

  • the Overview shows how far behind upstream Pharos is once it falls two hours behind, and how long it has been since upstream last published once that is more than two days.
  • the Vulnerabilities page shows, under the result count, when the mirror last synced and how a record reaches the list.

The EPSS scores and the KEV catalog refresh once a day.

If a CVE is missing, checking cti.wazuh.com for the same identifier settles it: while it is absent there, it cannot be in Pharos.

Advisory activity on a record​

The CVE page reconstructs an advisory activity timeline: when the record was first published, when each source that scored it last updated its verdict, and when it entered the CISA KEV catalog. Every timestamp is the one published by the source that owns it, ordered newest first, so the timeline is the record's history as its sources tell it rather than a count Pharos invents.

This means older records can show only a handful of entries. A CVE published in 2019 that lists a single line is not missing data: it is the state the record arrived in, and each new line appears as a source revisits it.

The search box on the Vulnerabilities page reaches identifiers, titles, vendor, product and package names, so libssl3 is a valid query and lands on the package.

Matching is by whole term, and it is tolerant of the punctuation in identifiers and package names. CVE-2021-44228 and cve202144228 reach the same record, and linux-image-amd64 matches whether or not its hyphens are typed. A CVE id can be given in part, so 44228 finds CVE-2021-44228.

The Filters button narrows the results by:

  • severity: critical, high, medium or low.
  • state: published records by default, which leaves out rejected ids. The default shows as a Published chip, and removing it includes rejected ids too.
  • KEV membership: in the CISA KEV catalog, or not.
  • exploit availability: a public exploit is known, or none is.
  • source: only records a chosen source has scored.
  • date window: published in the last week, month, quarter or year.
  • CVSS: a minimum, a maximum or both, from 0 to 10.
  • EPSS: a minimum, a maximum or both, as a percentage.
  • affects my fleet, which keeps only the CVEs that touch software the managers report installed. This one is available once a licensed manager is sharing its inventory.

Each filter in use shows as a chip under the search box, and its X removes it. Several values of one filter widen the results, so Critical and High together match a record that is either. Different filters narrow them, so High with KEV set to Listed matches only records that are both. A record without a CVSS score or an EPSS score falls outside any CVSS or EPSS range. A vendor, product or package reached from a link elsewhere in the console shows as a chip of its own.

Clicking a column header sorts the whole result on that column, newest or highest first. A second click reverses the order and a third returns to the default, newest published first. Severity sorts by CVSS, and the CVE, EPSS, Sources, Published and Updated columns sort on their own values. Records with no score sort last when highest comes first, and first when the order is reversed. The Updated column is hidden by default and Columns shows it.

The list shows 20 records per page. The search, the filters, the sort and the page are part of the page address, so a copied link opens the same view and the browser's Back button undoes the last change.

A search is also the shape of a subscription. Save the filter state on screen as a watchlist and Pharos raises an advisory when a matching record changes in the corpus, so there is no need to return and re-run the query. A watched record counts as changed when a new CVE fits the watch, a score is revised, an exploit is published, or a CVE enters the CISA KEV catalog. The Watch buttons on the vendor and package rows do the same for a single vendor or package.

Advisories come from the catalog, not from the fleet, so they are never metered: watching the corpus costs nothing. Billing is a separate thing, for the signals the sensors raise about the fleet. See Signals for what a signal is and how signals are billed.