Vulnetix Detection Rules Skill

Use when

• A CVE has no patch yet and you need detection-only mitigation.
• Augmenting SAST with active runtime detection (Snort/Suricata).
• Feeding the SOC engineering pipeline with rule files.
• Building a Nuclei scan template for an authorised target assessment.
• Hardening a YARA ruleset against a newly-discovered malware family.

Don't use for

• Executing the rules — this skill writes files; the user runs the engine.
• Patching the underlying issue — use fix.
• Single-CVE enrichment — use vulnetix_vuln (MCP) or vulnetix vdb vuln <id>.

Conventions

Follows skills/_lib/contract.md. In short: use the vulnetix_* MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes.

Pulls IDS/IPS, malware-detection, and active-scan content for a CVE. Capability-aware: only fetches rule families the user can actually use.

Step 1: Load capabilities

Read .vulnetix/capabilities.yaml. Capture derived.detection_stack. If empty, prompt:

No detection tooling found (snort, suricata, yara, nuclei, semgrep). I can still fetch the raw rules — proceed?

If the user accepts, treat the stack as [snort, yara, nuclei] for completeness. Otherwise abort with a one-liner pointing at install docs.

Step 2: Fetch each available family

For each family in detection_stack:

# Snort/Suricata
vulnetix vdb snort-rules get "$ARGUMENTS" -o json
vulnetix vdb traffic-filters "$ARGUMENTS" -o json

# YARA
vulnetix vdb yara-rules get "$ARGUMENTS" -o json

# Nuclei
vulnetix vdb nuclei get "$ARGUMENTS" -o json

Skip families absent from detection_stack to avoid wasted API calls.

Step 3: Save rule files (raw form)

Write rule content to .vulnetix/detection/<VULN_ID>/:

• snort.rules (concat of all Snort rule bodies)
• suricata.rules (if family present)
• vuln.yar (concat of YARA rules)
• nuclei-<id>.yaml (one per template)

Use --format rules / --format yaml against the same subcommand:

vulnetix vdb snort-rules list --cve-id "$ARGUMENTS" --format rules > .vulnetix/detection/$ARGUMENTS/snort.rules
vulnetix vdb yara-rules list --cve-id "$ARGUMENTS" --format rules > .vulnetix/detection/$ARGUMENTS/vuln.yar
vulnetix vdb nuclei get "$ARGUMENTS" --format yaml > .vulnetix/detection/$ARGUMENTS/nuclei.yaml

Step 4: Render report

For each family, list:

• Rule count + highest signature severity
• File path on disk
• A copy-pasteable invocation hint based on installed binaries:
  • snort -c snort.conf -A console (only if binaries.snort: true)
  • yara vuln.yar /path/to/scan (only if binaries.yara: true)
  • nuclei -t .vulnetix/detection/$ARGUMENTS/nuclei.yaml -u <target> (only if binaries.nuclei: true)

Step 5: Memory update

Append event: detection-rules with counts per family to the vuln entry.

Notes

• This skill never executes rules. The user (or exploit-test) runs them.
• Filter is honest: if YARA is missing, the YARA section is omitted from the report and from disk writes.

Edge cases & gotchas

• Each family is fetched ONLY if the binary is in derived.detection_stack. Override by passing --force if you want raw rule output regardless.
• vdb snort-rules, vdb yara-rules, vdb nuclei accept --format rules|yaml for non-JSON output (the engine's native format).
• Some CVEs return zero rules across all families — that means no community detection content exists, not that the skill failed.
• YARA rules can have multiple hash-only matchers; if your YARA build was compiled without hash-module support, those rules fail silently.
• Nuclei templates require a target URL/IP at invocation time; the skill produces the template, not the scan.
• vdb traffic-filters <id> returns Snort-format rules tagged for Suricata compatibility — confirm Suricata accepts the rule before deploying to Suricata.