Last reviewed:
CVSS helps patch teams triage exposure. Detection priority depends on exploit telemetry, attacker behaviour and whether the affected system sits on a path that matters.
CVSS describes vulnerability severity. It helps teams compare flaws by exploitability and impact. That is valuable patch context, but it is not the same as a detection plan.
A critical vulnerability can be hard to detect if the product emits weak logs. A lower-scored vulnerability can be a better detection candidate if exploitation leaves a clear request, process, audit event or identity change.
Detection priority starts with what the attack leaves behind. For a web application flaw, that may be a path, method, payload shape or WAF event. For a cloud control-plane issue, it may be an API call. For post-exploitation, it may be a new process, account or credential.
If you cannot name the observable event, do not force a weak rule. Use the CVE to drive patching, exposure reduction and hunt notes instead. A bad detection attached to a critical CVE still creates bad alerts.
Known exploitation changes the queue. A vulnerability in CISA KEV, active exploitation reports from a vendor or a recent incident in your sector should move the item up even if the score is not the highest on the board.
Asset context matters too. A flaw on an internet-facing authentication service deserves a different detection decision from the same flaw on an isolated lab host. Severity is global; priority is local.
A CVE should become a Sigma rule only when the rule can detect real exploit telemetry or a meaningful follow-on behaviour. Repeating the product name, version string and CVE id is not enough unless those values appear in logs during exploitation.
CloudSigma is strongest when the advisory points to observable behaviour. If the evidence is too thin, the honest output is a patch-and-monitor note rather than a public rule that pretends to see more than the logs contain.
1. Is exploitation known or likely against our exposed assets?
2. Which log source records the exploit or follow-on behaviour?
3. Can the rule preserve that behaviour after SIEM tuning?
4. If not, route to patching and hunt notes instead of a weak rule.