Run an incident

Something lands in your feed and the room wants an answer in the next ten minutes. This is the sequence.

1. Confirm it is real

Confirm urgency for CVE-XXXX-XXXXX: KEV status, EPSS, exploitation maturity, and whether it is being seen in the wild right now.

vulnetix_vuln gives KEV, EPSS, SSVC and exploitation maturity in one call. vulnetix_sightings answers the current-versus-historical question:

{ "count": 2568, "firstObservation": "2024-05-01", "lastObservation": "2026-08-08", "daysSinceLastSeen": 2 }

Half the incidents that start this way stop here. Vendor advisories and news coverage routinely describe exploitable as exploited, and the difference is the whole meeting.

2. Are you exposed

Which of our dependencies are affected, and at which versions?

vulnetix_package_vulns for the mapping. Then locally, where the real answer is:

/mcp__vulnetix__vulnetix_vuln CVE-XXXX-XXXXX

With the CLI installed this includes a tree-sitter reachability scan, a real AST pass over your project. reachability.direct is authoritative; absent it, affectedRoutines gives you what to grep for.

3. Pull the indicators

Give me IOCs and threat-actor attribution for this CVE.

vulnetix_iocs gives attacking IPs, ASNs, geography and Shadowserver scan counts. vulnetix_threat_actors gives actors and campaigns. vulnetix_attack_techniques gives the ATT&CK chain, so you know which of your existing controls should have caught it.

On Community the counts come back and the records are withheld, and the tool says so explicitly. count: 200 with an empty list means 200 indicators exist that your plan does not include. It does not mean there are none.

4. Detect while you are exposed

What detection content exists, and which should I deploy first on Suricata 7?

vulnetix_detection_rules returns whole Snort, YARA and Nuclei rules, complete, because you cannot deploy a summary. With stack supplied, the analysis ranks them, says what each matches, flags likely false positives, and states what the content does not cover.

That last part matters most during an incident: knowing your detection has a hole is more useful than believing it does not.

5. Decide the patch path

What is the remediation plan, and if we cannot patch today, what mitigates it?

vulnetix_remediation gives ranked actions, distribution patches, registry fixes and workarounds, each with effort and impact. vulnetix_workarounds gives mitigations that need no patch.

6. Record the position

/mcp__vulnetix__vulnetix_vex_publish

Generates OpenVEX or CycloneDX attestations from your triage decisions, optionally cosign-signed. Whether the answer was “patched”, “not affected because the vulnerable path is unreachable”, or “mitigated and monitored”, it is now a recorded position with a justification.

Three months later, when someone asks why this was closed, the answer exists.

The whole sequence as one prompt

/mcp__vulnetix__vulnetix_incident_respond CVE-XXXX-XXXXX

Confirms urgency, pulls IOCs and the ATT&CK chain in parallel, fetches detection rules for the families you run, evaluates patch paths and workarounds, generates a VEX attestation and posts a consolidated report. It is the only prompt with an unbounded output budget, because an incident report legitimately needs the room.

Afterwards

  • vulnetix_verify_fix proves the fix landed, and you can gate on the result
  • vulnetix_timeline shows how fast this class moves, for the retro
  • vulnetix_threat_feed shows whether it is part of a wider campaign
Note The tools are the fastest part of an incident and never the slowest. They answer “is this real, does it reach us, what do we do” in a couple of minutes. What takes hours is the deploy, the change window and the people. Knowing within five minutes that you are not exposed is worth as much as any fix.