Last reviewed:
Before a CVE detection is published, check that the rule matches real exploit telemetry, converts cleanly and says plainly what it does not cover.
Start with the advisory. Confirm the CVE id, affected product, affected versions, exploit preconditions and vendor fix. A detection built on a misread advisory will fail even if the YAML is tidy.
Then check the detection premise. The rule should match exploitation or meaningful follow-on behaviour. It should not rely on fields that appear only in vulnerability scanners or asset inventories unless the output is explicitly posture context.
A publishable rule has a specific log source, clear selections, a readable condition and false-positive notes the SIEM operator can act on. Conversion must work for the target dialects the audience uses.
Keep the level honest. A high-severity CVE does not automatically mean a high-confidence alert. The rule level should reflect detection quality, likely noise and operational impact.
Publication copy should not oversell the detector. Say what the rule looks for, what log source it needs and what it misses. If correlation is required, say that instead of presenting a single rule as complete coverage.
Private review notes stay private. Public readers need the detection logic and operating caveats, not internal scoring, reviewer names or pipeline details.
advisory_checked: yes
rule_converts: yes
log_source_named: yes
false_positives_written: yes
known_limits_written: yes
private_review_metadata_removed: yes
If the rule passes, publish it with its limits. If it fails, hold it and file the blocker where the engineering team can fix the source problem.
A held detection is not wasted work. It protects the public library from weak rules and gives the next reviewer a concrete reason to revisit the item.