Last reviewed:
A CVE is not a detection. To produce a useful Sigma rule, first identify the exploit path, the observable telemetry and the attacker action worth catching.
A vulnerability advisory tells you what product is affected and how severe the flaw may be. It rarely tells you exactly what your SIEM should query. Detection work starts after the CVE triage: read the exploit conditions, then decide which logs would show exploitation or post-exploitation activity.
CVSS can help with urgency, but it is not detection priority. A critical vulnerability with no useful telemetry may need patching and exposure control rather than a weak rule. A medium vulnerability with a clear log trail may produce an excellent detection.
Useful CVE-led rules separate product metadata, exploit telemetry and attacker behaviour. Product metadata says what is vulnerable. Exploit telemetry says what the attack does on the wire or in logs. Attacker behaviour says what happens next: command execution, account creation, credential access or data access.
That separation keeps the rule honest. If the only observable event is a suspicious HTTP path, the rule should not claim to detect full compromise. If the logs show a spawned shell or a new privileged account, the ATT&CK mapping can move beyond Exploit Public-Facing Application.
The best log source depends on where exploitation becomes visible. A web CVE may show in WAF or reverse-proxy logs. A cloud control-plane issue may show in CloudTrail, Azure Activity logs or GCP Cloud Audit Logs. A post-exploitation action may show in Sysmon, Linux auditd or the SIEM's identity tables.
Avoid rules that look for the CVE id in log text unless the product really emits it. Most systems do not write the CVE number during exploitation. They write paths, methods, process names, API calls and errors.
A reviewable CVE rule explains why each selected field matters. The title names the behaviour, the description ties it to the advisory, and the false-positive notes explain legitimate traffic that can look similar.
CloudSigma uses that structure for CVE-led Sigma generation. The customer-facing rule should still be treated as a starting point for SIEM tuning, not a substitute for patching the affected product.
def cve_rule_path(cve):
if cve.exploit_has_http_ioc:
return 'waf-or-proxy-rule'
if cve.exploit_changes_cloud_control_plane:
return 'cloud-audit-rule'
if cve.post_exploit_process_event:
return 'endpoint-rule'
return 'patch-and-monitor-no-showcase-rule'