Fleet exposure
Until a manager is connected, Pharos knows the corpus and nothing about the deployment. Once a manager shares its inventory, the packages its agents report installed, the same corpus gains a second half: which of these records name software the fleet actually runs. This page is that half, and the one distinction it rests on, which is that a name-level match is a hint about where to look and not a verdict.
What turns it on
Exposure is computed from inventory, so it needs a connected manager whose inventory sharing is on. Sharing is on by default and switchable per manager from its page, by an admin. It is the most sensitive thing Pharos asks for, so turning it off is a choice the console respects rather than a fault it reports: a manager that does not share still reports its alert stream and its findings, and its coverage panels say "Inventory not shared". Nothing about it is billed. Connecting a manager and sharing its inventory are free, and the billed signal is defined in Signals.
The exposure table is rebuilt every hour and after each inventory report, so a package installed today appears in it within the hour.
Where it shows
| Surface | What appears |
|---|---|
| Vulnerabilities, the Yours column | A chip saying how many of the connected managers report a package this record names. Hovering it lists the packages. A dash when none does |
| Vulnerabilities, the Affects my fleet filter | Keeps only the records that touch software the connected managers report installed. Disabled, with a note saying why, until a manager is connected |
| The CVE record, badge row | A chip reading "Affects N of your managers" |
| The CVE record, Your exposure | Each matching package with the version the connected managers report installed, the fixed version where a source published one or "no fix published", and a chip per manager |
| Packages, the Installed on column | Which managers report the package, with a checkbox to show only what the connected managers install |
| Overview, the Your fleet card | How many records touch the fleet, how many of those are in the CISA KEV catalog, and how many managers they touch |
| A manager's page, Coverage | The records naming a package that manager shares, worst first |
| An agent's page, Coverage | The same, for the manager the agent belongs to |
The Fleet section of the console gathers all of it: Overview sums the streams across managers, Managers is one row per connected deployment, Agents is every host across every manager, and Activity is what their alert streams produced. The Fleet overview also lists which managers need attention, worst first, from "Not sharing inventory" through "Never synced" to "Offline".
Coverage is a name, a finding is a verdict
Pharos matches by package name. A record names openssl, a connected manager
reports openssl installed, and the record is in the fleet's exposure. The two
versions are printed next to each other as reported, and nothing compares
them. That is deliberate: a version-range verdict computed from distro
package names and upstream ranges would be a false-positive generator, and
Pharos would rather say "the fleet runs this package, look here" than claim an
affected version it cannot prove.
The version-level verdict in the product comes from the fleet's own Wazuh. Its vulnerability detector compares the versions each agent has installed against the advisories it holds, and the sidecar reports what it decided as findings, one per agent and package. Findings are signals, they land in the Signals inbox, and they are the only version-level verdict Pharos shows.
Coverage and findings are never added together and never compared. Coverage says an advisory names a package the fleet runs. A finding says the fleet's own Wazuh compared the version it has and decided it is affected. The Fleet pages label each of them, and an agent's page shows both, as two separate streams.
The fleet watchlist
A watchlist of kind My fleet watches whatever the connected managers report installed, with no target to type: its target is the inventory itself, so it stays correct as the estate changes. It takes the same CVE triggers as any other watchlist, so it can be as quiet as "published and KEV added" or as loud as "any field changes", and when it fires the advisory's reason names the package and how many of the connected managers run it. It is the one subscription a mailing list cannot offer, and like every advisory it is free. The kinds and triggers are in Watchlists and advisories.
What the Agents page adds
Agents lists every host across every manager, with Wazuh's own status words, the operating system, how many packages and files the host reports, and whether anything on it has matched the indicator corpus. Each agent opens onto four streams that come from four different places and are never added together: its inventory, its coverage, which is the manager's since inventory is shared per manager, its findings with a "Triage in Signals" link that opens the inbox filtered to that host, and its indicator sightings. The per-agent breakdown of inventory runs once a day, so a host enrolled this morning may read "not counted yet" until the next one.