Twelve thousand criticals and two audiences

Never reconcile by picking the number you prefer. Enumerate the filters that differ:

1. Scope. The dashboard may be unscoped across repositories while the report chapter is scoped to one repository, or vice versa. Repository scope changes the population before any severity filter applies.
2. Asset scope. "All Assets" is not the same as the asset list the report chapter uses; a dynamic list resolving differently on the report date moves the count.
3. Accepted risk. Findings under an accept-risk rule are suppressed from analysis by default. The dashboard may include them, the report chapter may not - or the rules were applied between the two queries. 400 findings is the right order of magnitude to explain part of the gap.
4. Counting unit. Vulnerability instances (per host per plugin) versus unique plugin families or per-host rollups produce different totals by design.
5. Time window. "Last seen" / "first seen" filters in the chapter can exclude findings that the live component includes.
6. Refresh timing. Components and report chapters refresh on their own schedules.

Judgement: publish one definition of "open Critical" in a footnote and make both artifacts use it. A number nobody can reproduce is worse than a smaller number that reconciles.

With VPR and asset criticality: rank on the combination, not on severity. VPR folds in exploit availability, threat context, and exploit maturity, and asset criticality reflects business value - so a CVSS 7.5 with a public exploit on a criticality-10 POS database should outrank a 10.0 on a criticality-1 test VM.

Practical recipe:

• Filter to findings that matter: exploit available, VPR at or above a threshold you can defend, excluding accepted-risk items.
• Sort by asset criticality, then VPR, then age. Age matters because a 90-day-old high-VPR finding is a process failure, not a backlog item.
• Deliver host-level rollups with the top three findings per host so a technician can act in one visit.

Without VPR/ACR: build proxies from what you have - exploit availability, whether the service is externally reachable, and a hand-maintained asset importance tag applied to the small set of business-critical hosts. It is weaker and more manual, but it still beats CVSS-only ordering. Do not silently present severity ordering as prioritization; say what the ranking is based on.

Monthly PDF (CISO): one page, so it must be a small fixed set of chapters - trend of open findings by severity over time, top movements, mean time to remediate by business unit, and the handful of highest-priority items with owner. Roll up per host, not per instance, or the page becomes a wall of duplicates. Schedule delivery, but include the as-of timestamp and the filter definitions, because the first question will be "why did this change".

Traps: PDF size limits truncate large chapters silently; trends computed against a repository that changed scope mid-period create fake movements; a "top 10" chapter with no tie-breaking rule changes contents every month and destroys the sense of progress.

Weekly worklist (patch team): host-level, sorted by asset criticality then VPR, with the top findings per host, delivered in a machine-consumable form (CSV) as well as readable form. Include the remediation owner and the finding's age.

Traps: accepted-risk items reappearing as new work; the same CVE listed under multiple plugins inflating the list; findings on hosts that were rescanned and no longer present. Filter to currently observed results before delivering, and keep the delivery cadence aligned to the scan cadence - a Monday worklist built on Friday's data build is stale by the time anyone acts.