The fleet CVE index, and versions withdrawn upstream

This page holds the detail behind the trust page’s promise of a fleet CVE index.

Why a CVE index at all

Ingest and an index answer different questions. The front-line control is the ingest gate; a CVE that surfaces after an artifact is already running is a confession, not a defence. But not everything on a real fleet came through the gate. Software predates it, arrives outside it, or sits there as a plain uninstall entry no package manager placed. When a named CVE breaks, you still have to answer which endpoints run the affected version, and whether they are patched. The index answers that retrospective question about the software already there.

Sources, and what is stored

The index matches the cvelistV5 stream and the CISA KEV catalog against the inventory your endpoints report: managed packages and unmanaged uninstall entries alike. The full corpus is streamed, never stored. The store keeps:

• records that match something your fleet has reported, including matches since cleared;
• every KEV-listed record;
• records that hit a component of a bundled SBOM;
• records that map a product in your catalog, even one installed nowhere.

Confident, possible, can’t tell

Every match lands in one of three classes:

• Confident. An operator pin, or the shipped alias list, maps the product, and the record’s affected data places the installed version inside.
• Possible. A hedged mapping, from name tokens, a normalized vendor and product, the record’s CPE names, a GitHub owner/repo in the package’s URLs, or the winget manifest’s publisher and name. It is shown and labelled possible, and never fires. Possible matches count toward the exposure page’s hit totals, never toward a version’s affected count.
• Can’t tell. The record cannot place the installed version, or the version itself cannot be read: no version data, a version scheme it cannot compare, or a version newer than every listed one with no fix named.

You can pin a mapping either way, including a negative pin that suppresses a wrong match. On the exposure page, confident matches rank first, then KEV-listed ones.

When it cannot be sure

It says which kind of unsure. A winget version’s page reads 0 only when every CVE record keyed to its product places the version outside: “0 known CVEs affect this version”. Otherwise it shows possible and can’t-tell matches, neither counted; “No CVE record names this product: coverage unknown”; or “Evaluation pending”, until the record store is complete.

A matcher-rule change never records a false fix. A match it drops clears as mapping-retracted or evaluation-revised, never as remediated. A stalled sync or blocked egress raises a “CVE sync degraded” banner. An air-gapped deployment can import the same data as an offline bundle at startup; point the platform at a public key, and it requires a valid signature on the bundle.

What can raise an alarm

Firing takes more than confidence. Only a confident match on a managed copy, for a CVE that is KEV-listed or Critical, is meant to raise a rollback proposal or an update-pipeline CVE halt. Both ship off, and neither fires today: the step that ties a CVE record to the catalog’s package ids does not resolve yet (platform issue #3493). A proposal an operator confirms would only withhold the version from new installs and later rings, and confirmation is refused by default. An unmanaged copy, seen only as an uninstall entry, never fires; the page suggests adopting it first.

Responding to a CVE

Home lists each confident match as a decision, with the response it suggests: Deploy fix when a fixed version is in the catalog, Withhold when the newest catalog version is itself affected, and Respond when the software is not in the catalog at all, so a fixed version has to be ingested first. The card opens the CVE’s page; it does not act. On that page, Deploy fix promotes the fixed version one ring at a time, each step behind a typed confirmation. Withholding an affected version is done from that version’s own page. Nothing in this path runs on its own.

Versions withdrawn upstream

The upstream monitor ships off, behind two switches: egress you allow when you deploy, and a runtime setting an admin turns on. Once on, it notices a winget version disappearing from its public source. It confirms the withdrawal is real, not a transient fetch failure: the version must be gone from the listing on a later sweep, and from the raw manifest too. It then records per-version withdrawal evidence.

• A version you only observed, or one held in quarantine, is tombstoned against new admission.
• A version you already attested keeps its status and keeps serving: upstream withdrawing it does not retract a decision you made. Where your server holds its bytes (detonated with the byte store on), a rollout carries on untouched. A version served from the vendor URL installs only for as long as the vendor still hosts that file.

Every attested version withdrawn upstream gets a badge. You also get an inbox alert when it is your newest attested version or is live in a ring.