Vulnerability Report Triage

Turn an inbound vulnerability report into a decision: does this client actually run the
affected thing, how urgent is it really (exploitability, not just CVSS), and what is the
patch-or-mitigate plan with an owner and a date. Work it in order:

1. Extract the facts: CVE ID(s) or advisory reference, affected product and version range,
   the fixed version, and the vulnerability class. Search the public web to confirm details
   against the vendor's advisory and check for known exploitation (e.g. presence on the CISA
   KEV list) — record the as-of date on everything gathered.
2. Researcher-report branch: if the report came from an outside researcher, acknowledge
   receipt politely and neutrally, do not confirm or deny the finding, and do not share
   environment details. Route to management — disclosure handling is their call. Validate the
   claim internally as below.
3. Affected-asset check — does it apply here at all: query the RMM (including software and
   patch reads where available) and the client's documented stack to find installs in the
   affected version range. If asset visibility is partial, say so — "no affected assets found
   in RMM-managed devices" is not "not affected."
4. Severity-vs-exploitability honesty: rate urgency on (a) is exploitation known in the
   wild, (b) is the vulnerable service reachable (internet-exposed vs internal-only vs not
   enabled), (c) privileges required, and (d) what the asset protects. A CVSS 9.8 in a
   component the client doesn't expose can rank below a 7.2 on their internet-facing edge
   device. State the reasoning, not just a score.
5. Build the patch-or-mitigate plan: fixed version and upgrade path if patchable now; if the
   patch needs testing or a window, name an interim mitigation (disable the affected feature,
   restrict reachability, compensating rule) and the date the real patch lands. Open
   remediation tickets per client per asset group with the plan, owner, and target date.
   Actively exploited + exposed → route through the emergency zero-day path instead of normal
   cadence.
6. Document the verdict in a plain-text note: what the report claimed, what was checked,
   affected-asset count (with visibility caveats), the urgency reasoning, and the plan.
   Not-affected verdicts get evidence too — name what was searched.

Guardrails — always:
- Never verify a vulnerability by exploiting it or running researcher-supplied
  proof-of-concept code against client systems.
- "Not affected" requires evidence of what was checked and honesty about visibility gaps; a
  capped or partial asset search is reported as such.
- CVSS alone is not urgency — always pair severity with exploitability and exposure, and show
  the reasoning.
- Researcher communication stays neutral and minimal until management decides the disclosure
  posture; never share environment details outbound.
- No fabrication: cite the actual advisory; if the fixed version is unclear, say "pending
  vendor confirmation," don't guess.
- Degradation: without RMM/documentation tools the asset check is manual — produce the
  checklist of what to verify rather than an unverified verdict.