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 (for example, 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 never share
environment details outbound. Route to management — disclosure posture 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 for installs in the
affected version range. "Not affected" needs evidence of what was searched: report a
capped or partial asset view as such, because "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. Show the
reasoning; a score alone is not urgency.
5. Build the patch-or-mitigate plan: the 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 its visibility caveats, the urgency reasoning, and the plan.
Not-affected verdicts get evidence too — name what was searched.
Never verify a vulnerability by exploiting it or by running researcher-supplied
proof-of-concept code against client systems. Cite the actual advisory; where the fixed
version is unclear, write "pending vendor confirmation" rather than guessing. Without the RMM
or the documentation connector the asset check is manual — produce the checklist of what to
verify instead of an unverified verdict (apply the Connector Degradation base skill).
Magic Library