Exploit Dispatch for Tenable

When a vulnerability is exploited in the wild, its fix needs an owner today, not a slot in next week’s review, and on-call needs to hear about it only if it just became urgent. Exploit Dispatch handles that short list: findings whose plugins Tenable flags as exploited (CISA KEV or exploited by malware) or in the news. Each fix gets one ticket for its owner, on-call is paged only for new urgency, and the tickets are closed once Tenable sees the fix.

What it does

• One ticket per fix and owner. Findings that the same patch fixes are grouped into one ServiceNow incident, or optionally a change request, for the assignment group that owns the assets. Tenable tags pick the group. The ticket lists why the findings are urgent, the fix, the CVEs, and every affected asset. When more assets turn up later, they’re added to the same ticket as a work note instead of opening a new ticket.
• Pages for new urgency, not the backlog. By default, PagerDuty is paged only for an exploited finding on a critical (ACR 9+) or internet-facing asset that was first found, or added to CISA KEV, in the last 7 days. Older exploited findings get tickets but don’t page, so pointing the skill at an existing backlog doesn’t page anyone at 3 a.m. Each page links to its ServiceNow ticket.
• Closes the loop. After rescans, reconcile resolves incidents and their pages once every affected asset is fixed, and adds a progress note when only some are. It flags a ticket for a person, rather than closing it silently, when assets have disappeared from Tenable or when a closed ticket’s findings are still there.
• Works with Tenable Vulnerability Management or Tenable Security Center. Security Center has no asset tags, so its findings are routed by repository, and they carry only the CISA KEV signal.

How it works

The skill drives a deterministic Python CLI. Claude runs the commands, explains each plan in plain language, and answers questions about it. The script makes every decision about tickets and pages, from a policy file you control: routes from Tenable tags to assignment groups and PagerDuty services, paging rules, severity mapping, and per-run limits.

1. Collect the exploited and in-the-news findings from Tenable, fixed ones included.
2. Plan the tickets and pages. Planning only reads, and writes a plan file.
3. Approve the plan. The skill never sends anything without your approval of that exact plan.
4. Apply it. apply refuses a plan that was edited, made with a different policy, more than 24 hours old, or applied before. Just before sending, it checks ServiceNow again, so a ticket opened since the plan was made isn’t duplicated.
5. Reconcile after rescans, approve again, and apply.

Requirements

• Claude Code, and Python 3.11+ (uv installs the dependencies from the script’s metadata).
• Tenable Vulnerability Management or Security Center API keys.
• A ServiceNow user with the itil role, through the standard Table API. No ServiceNow Store app or Vulnerability Response module is needed.
• A PagerDuty Events API v2 integration key for each service you page.

A three-day demo, with real vulnerabilities on made-up hosts, runs the whole flow against a ServiceNow developer instance and a PagerDuty developer account before you connect real data.

Data and safety

• It only talks to Tenable, your ServiceNow instance, and PagerDuty’s Events API. It sends nothing anywhere else.
• Credentials come only from environment variables.
• Plugin output is never requested or stored.
• Every change is written to a local audit log.

Limitations

• The record of open tickets and pages is local. Run the skill from one place, or share its home folder, so runs see the same history.
• Change requests are never resolved automatically; they get a note and a flag.
• A finding without a first-found or KEV date can’t be shown to be new, so it doesn’t page.