# Exploit Dispatch for Tenable

> Turns exploited and in-the-news findings from Tenable Vulnerability Management or Security Center into one ServiceNow ticket per fix, pages PagerDuty only for new urgency, and closes both when Tenable confirms the fix. A person approves every change first.

- Type: Skill
- Author: Lance Duvall
- License: MIT
- Trust tier: contributed (passed automated validation and a baseline maintainer review)
- Last reviewed: 2026-11-09
- Source repository: https://github.com/lanz/exploit-dispatch
- Repo state: not archived
- Last push: 2026-11-06T04:58:11Z
- Stars: 0 (a popularity signal, not a safety signal)
- Forks: 0 (a popularity signal, not a safety signal)
- Open issues: 0
- Language: Python
- Health checked at: 2026-11-10T17:11:48.374Z
- Integrations: PagerDuty, ServiceNow, Tenable
- Domains: vulnerability-management, security-operations
- Tags: tenable, tenable-vm, security-center, servicenow, pagerduty, cisa-kev, exploited-vulnerabilities, remediation-tracking, on-call, claude-code
- Date added: 2026-11-06
- Compatible platforms: Claude Code
- Invocation: `/exploit-dispatch`
- Listing page: https://exchange.tenable.com/skills/exploit-dispatch
- Source file: https://github.com/tenable/cyberagents-exchange/blob/main/skills/exploit-dispatch.md

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.

This is the Markdown version of one of 145 listings on CyberAgents Exchange. The same listing as JSON: https://exchange.tenable.com/api/skills/exploit-dispatch.json. The full index and how to read it: https://exchange.tenable.com/llms.txt