Watchlists and advisories
A watchlist is a standing question against the corpus, and an advisory is what Pharos raises when the answer changes. A CVE record changes constantly and most of it is noise, so what counts as a change is the analyst's choice, trigger by trigger. Advisories come from the catalog, not from the fleet, and they are never billed: the analyst asked to be told, so being told is free. The billed unit, the signal, is defined in Signals.
What a watchlist can watch
| Kind | What it matches |
|---|---|
| Vendor | Every CVE affecting one vendor, across all of their products |
| Package | One distro package name. The narrowest, quietest option |
| Saved query | Anything the filter bar on the Vulnerabilities page can express, saved and re-evaluated as records change |
| My fleet | Whatever the connected managers report installed, so it stays correct as the estate changes. It needs no target |
| Malware family | Every new indicator attributed to one malware family |
| Target brand | Every new indicator impersonating one brand, phishing for the most part |
| Indicator type | A whole class of indicator: every new URL, or every new domain |
The first four watch CVE records. The last three watch the indicator corpus described in Investigate. A watch on a single indicator value is deliberately not a kind: that is a lookup, and Investigate answers it for free.
The quickest way to create one is the Watch link at the end of a package or vendor row on the Packages page, which opens the builder with the target filled in. New watchlist on the Watchlists page opens it empty. Products cannot be watched directly today: watch the vendor or the package instead.
A saved query is the search, serialised
A saved query is the filter state of the Vulnerabilities page written as
key:value terms, the same search the list runs rather than a second query
language. severity, vendor, product, package, source and state
take the values the filters take. score:7 and epss:0.5 are floors.
kev:listed or kev:not-listed and exploit:public or exploit:none are
the two flags. cwe: names a weakness. A term that is not a known filter is
searched as text, and the builder reads the query back as it understood it.
At least one filter or search term is required.
What counts as a change
Every watchlist carries one or more triggers, and choosing them is the whole point: a record that is merely revised is rarely worth a message, a record that enters the CISA KEV catalog usually is.
| Trigger | It fires when | Worth knowing |
|---|---|---|
| published | A new CVE that matches the watch is published | The default, with KEV added |
| revised | Any field of a matching record changes | Very noisy. Analysts only |
| score changed | The worst CVSS score across sources moves between two values | A first score on a record already held counts. One arriving with the record does not |
| KEV added | The record enters the CISA Known Exploited Vulnerabilities catalog | The one worth a page: confirmed exploited in the wild |
| exploit published | A matching record changed and now carries a reference tagged as an exploit | Upstream does not date reference additions, so the advisory says exactly that |
| affected expanded | The record's affected list gained entries in a revision | The dangerous update to a CVE already dismissed |
| indicator published | A new indicator matching the watch enters the corpus | About the corpus, never about the fleet observing one |
| confidence raised | A second source corroborates an indicator already in the corpus | Indicator kinds only |
CVE kinds take the first six triggers and indicator kinds the last two. A CVE watchlist also carries a noise floor, a CVSS score below which nothing fires. Each trigger fires at most once per record per watchlist, so a record revised a hundred times produces one "revised" advisory, not a hundred.
The reason on an advisory says only what the data supports: "worst CVSS 5.3 to 9.8" or "entered CISA KEV" name the change, and "this record changed and carries a reference tagged exploit" is the honest wording for a trigger that upstream does not date.
Where an advisory lands
Every advisory is written to the in-app inbox, whatever else the watchlist asks for, and the Advisories page is where they are read: each one with its severity, the record or indicator, why it fired, the watchlist that fired it, its status and its delivery record, opening onto the CVE or sending the indicator to Investigate. Advisories carry the same statuses as signals and the same bulk triage, but they are a separate page from the Signals inbox on purpose: one is what the watchlists reported, the other is what the sensors sent, and the Overview counts them as two figures that are never added together.
A watchlist chooses its own delivery: instantly, or as a daily or weekly digest, to the in-app inbox and to any of email, a webhook, Slack or Jira. Destinations are configured once, in Notifications, and each watchlist picks from them. External delivery, and more than one watchlist, are available once the workspace has been switched on as described in Signals.
Watchlists can be grouped into projects, so production can page a webhook while the lab collects a weekly digest. Each row on the Watchlists page shows its triggers, its destinations and how many advisories it raised in the last 30 days, and can be muted or deleted.