Get a signed webhook when CISA adds a Known Exploited Vulnerability

The problem

CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities CISA has confirmed are being exploited in the wild. U.S. federal civilian agencies must remediate them under Binding Operational Directive 22-01, and the catalog changes whenever CISA adds or amends an entry, typically several times a week. It is published as one large JSON file; what a security team needs is the difference since yesterday, delivered somewhere a ticket or patch job can start from it.

This guide monitors the whole catalog as one record per CVE and sends every change to your own HTTPS endpoint as a signed webhook.

What the source contains

CISA Known Exploited Vulnerabilities catalog · Cybersecurity and Infrastructure Security Agency

Every CVE in CISA's Known Exploited Vulnerabilities catalog as structured records: vendor, product, vulnerability name, date added, short description, required action, due date, known ransomware use and CWE identifiers. Monitors additions and later edits to any entry.

11 typed fields · 1,739 records in SourceFinch's latest run on October 12, 2026 · publisher updates: whenever CISA adds or amends an entry, typically several times a week · full source page

What a change means

• A new cve_id: CISA added a vulnerability. date_added says when, and due_date the remediation date set for federal agencies.
• A change to required_action, due_date, short_description or known_ransomware_use on a CVE already in the catalog.
• A removed record. CISA does not remove entries from the catalog, so a record leaving the set is itself worth a look.

Set it up in the console

1. Open the Verified recipe. Open the CISA Known Exploited Vulnerabilities catalog recipe in the console. It keeps the reviewed URL, fields and record key (cve_id), and shows the latest captured sample. Open in the console
2. Create the monitor. Name the monitor, keep the daily schedule or pick another (the console shows the monthly run cost), confirm that you have the right to monitor the source, and choose Create monitor.
3. Run the baseline. The first run is the baseline: every record is new. From the second run on, the monitor reports what was added, changed or removed, field by field, with the evidence behind each value.
4. Choose how you hear about changes. In Alerts, choose immediate change emails or a daily or weekly digest; each monitor can override that on its own page. For your own systems, add a signed webhook in Destinations. Alerts and team
5. Add a webhook destination. In Destinations, add a webhook with your HTTPS endpoint, choose to send Changes (added, changed and removed records) and select this monitor. Copy the signing secret when it is shown: it is shown once. Open Destinations
6. Verify every delivery. Deliveries are signed under Standard Webhooks (webhook-id, webhook-timestamp and webhook-signature headers) and retried for 24 hours. Check the signature with your secret, reject stale timestamps and deduplicate on the payload's idempotency_key. Verifying webhooks with the SDK

The same through the REST API, CLI or MCP

Every surface creates the same monitor from the same Verified recipe. You confirm you have the right to collect the source (rights: true).

CISA Known Exploited Vulnerabilities catalog

# the Verified entry (fields, recipe, sample, terms) as JSON
curl https://sourcefinch.com/v1/catalog/cisa-known-exploited-vulnerabilities -H "Authorization: Bearer $SOURCEFINCH_API_KEY"

# create the monitor from source.json (below)
curl -X POST https://sourcefinch.com/v1/sources \
  -H "Authorization: Bearer $SOURCEFINCH_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d @source.json

# then run it now (later runs follow the schedule)
curl -X POST https://sourcefinch.com/v1/sources/$SOURCE_ID/runs \
  -H "Authorization: Bearer $SOURCEFINCH_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)"

sourcefinch login
sourcefinch catalog get cisa-known-exploited-vulnerabilities --source-json > source.json
sourcefinch sources create --file source.json
sourcefinch runs create $SOURCE_ID --wait
sourcefinch records $SOURCE_ID

claude mcp add --transport http sourcefinch https://sourcefinch.com/mcp

# then ask your agent:
"Use SourceFinch to monitor CISA Known Exploited Vulnerabilities catalog: get_catalog_source cisa-known-exploited-vulnerabilities,
then create_source with its create_source_args (dry run first), then run_source."

{
  "name": "CISA Known Exploited Vulnerabilities catalog",
  "url": "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json",
  "recipe": {
    "mode": "http",
    "format": "json",
    "items": "vulnerabilities[*]",
    "fields": {
      "cwes": "cwes",
      "notes": "notes",
      "cve_id": "cveID",
      "vendor": "vendorProject",
      "product": "product",
      "due_date": "dueDate",
      "date_added": "dateAdded",
      "required_action": "requiredAction",
      "short_description": "shortDescription",
      "vulnerability_name": "vulnerabilityName",
      "known_ransomware_use": "knownRansomwareCampaignUse"
    },
    "required": [
      "cve_id",
      "vendor",
      "product",
      "vulnerability_name",
      "date_added"
    ],
    "types": {
      "cwes": "string",
      "due_date": "date",
      "date_added": "date"
    }
  },
  "key_field": "cve_id",
  "schedule": "daily",
  "rights": true,
  "catalog": {
    "slug": "cisa-known-exploited-vulnerabilities",
    "version_id": "bbd80253-b0dd-46bd-a6f8-9f3d7b2a222c"
  }
}

Alerts and evidence

A webhook suits this task: each delivery carries the changed records with links to the evidence they were read from, so the receiving system can cite the exact capture. Email alerts can run alongside it.

Every run keeps the publisher's exact response with its SHA-256 hash and a signed manifest, and every value points back to where it was read. How that works is in the docs:

• Review changes and receipts
• Alerts: change emails and digests
• Evidence and export: what a run keeps, bundles, CSV/JSON/XLSX
• Checking an evidence bundle offline
• Verifying signed webhooks
• Rights and acceptable use

Limitations

• Each run downloads the whole catalog file (about 1.8 MB at review), so the default daily schedule fits how often KEV changes.
• Third-party links in the notes field are carried as text and are never fetched.
• The records describe software products and weaknesses. Matching them to your own systems is up to you.

Usage rights, terms posture and reliability for each source are on its source page. They are our documented understanding of each publisher's stated terms, not legal advice.

Related