CISA KEV Priority Delta Monitor

Durable, informational monitor of the official CISA Known Exploited Vulnerabilities (KEV) catalog — the free, public JSON feed the U.S. Cybersecurity and Infrastructure Security Agency publishes at https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json. No API key, no account, no proxy, no browser.

This is a mirror-with-diff of a public government catalog, not a security assessment or a compliance decision. It does not evaluate your exposure, does not tell you whether a CVE applies to your systems, and is not a substitute for a vulnerability management program. It tells you, reliably and cheaply, when CISA's own catalog gains or changes an entry you asked to watch.

Why

CISA already publishes the whole catalog for free. What it doesn't give you is a durable, per-organization "what's new for me since I last looked" — you either poll the whole feed yourself and diff it client-side, or you don't watch at all. This actor keeps that diff for you: a watchlist of vendors/products/CVEs (or the whole catalog), a durable memory of every entry's content between runs, and a bill only for entries that are genuinely new or have genuinely changed.

How it works

1. Every run fetches the entire CISA KEV catalog in one request (it's one JSON file, no pagination).
2. The first run for a monitorId establishes a baseline: every entry's content hash is stored, nothing is billed or delivered — you start monitoring from "now", not from the catalog's entire history.
3. Every later run compares the fresh catalog against the stored hashes:
   • an entry whose CVE ID was never seen before is new;
   • an entry whose CVE ID was seen before but whose content (due date, ransomware flag, required action, notes, vendor/product, description) differs is changed;
   • anything else is skipped entirely — no row, no charge, no claim.
4. Your watchlist (vendor/product/CVE, or empty for the whole catalog) and includeRansomware filter are applied to that new/changed set. Matching rows are written to the dataset and billed once each.
5. A hard per-run cap (maxResultsPerRun) protects you from a single run billing an unbounded backlog if CISA adds hundreds of entries at once — anything over the cap is picked up cleanly on the next run, nothing is lost or double-billed.

Input

{
  "monitorId": "my-kev-watchlist",
  "watchlist": [
    { "vendorProject": "Microsoft" },
    { "cveId": "CVE-2021-44228" }
  ],
  "includeRansomware": false,
  "maxResultsPerRun": 200,
  "notifyOn": "new_alerts",
  "webhookUrl": "https://example.com/webhook"
}

• watchlist — 0-100 objects, each {vendorProject?, product?, cveId?}. All fields set inside ONE object must match (AND); objects themselves are OR'd. Leave empty (or omit) to watch every new/changed entry in the whole catalog.
• includeRansomware — when true, narrows every match down to entries CISA flags knownRansomwareCampaignUse: Known. When false (default), that flag is reported on every row but does not filter anything out.
• maxResultsPerRun — 1-2000, default 200.

Add or change the watchlist any time under the same monitorId — the durable hash index covers the whole catalog regardless of what the watchlist currently says, so widening the watchlist later correctly compares against real prior state instead of treating everything as brand new.

Output

One row per new/changed KEV entry: cveID, status (new/changed), vendorProject, product, vulnerabilityName, dateAdded, dueDate, knownRansomwareCampaignUse (bool), requiredAction, notes, shortDescription, sourceUrl (link to the official CISA KEV catalog page). A run that finds nothing new still writes an honest run_summary row to the default dataset (never silently empty).

Billing

Pay-per-event: kev-record-new-or-changed — charged once per CVE per distinct content state (the same CVE can be billed again later if CISA genuinely changes that record, but never twice for the same content). The baseline run establishes history without charging. Failed/blocked runs (source fetch failed, run timed out) are never charged.

Delivery guarantee: at-most-once (not exactly-once)

The right to write a row and to charge for it is granted by a single atomic primitive — one addRequest(uniqueKey) into a dedicated, named claim-journal Request Queue (<prefix>-<monitorId>-claims). Exactly one run ever wins that key. Claim requests are never deleted and never handled: the queue is a permanent journal of irreversible attempts, not a work list.

• You will never be charged twice for the same record state. That is the guarantee.
• It is not exactly-once. If a run wins the claim and then dies before the row reaches the dataset (or before the charge completes), that change is lost: it closes as dataset_unknown / charge_unknown and is never re-delivered. We deliberately prefer losing a delivery over double-charging you.
• Boundary of the guarantee: it holds for as long as the named claim-journal queue exists. Anyone with account access can delete or re-create that queue through the Apify Console/API; a fresh journal starts empty, and previously delivered changes could then be delivered and billed again. That is an inherent limit of any durable storage, not a defect of the protocol.
• Migration boundary: the guarantee applies from the build that introduced the claim gate onward. Older builds of this actor must not keep running against the same monitorId. That same build also had to shorten the durable storage name prefix (the old one, the full actor name, could not fit Apify's 63-character storage-name limit together with a 40-character monitorId), so a monitor that ran on an older build starts from a fresh baseline once. A baseline is never charged.
• coverage.claimJournalSize reports the journal's size each run (best-effort; null if the queue's metadata could not be read, and the value lags a few seconds because Apify's totalRequestCount is eventually consistent). Use it to watch growth, not to make decisions.

Honest limits

• We fetch CISA's feed as published; we do not second-guess or enrich it with our own risk scoring — that would misrepresent what this tool is (see the disclaimer above).
• If the feed is temporarily unavailable or its shape changes, the run reports that honestly (sourceStatus/FAILED with a reason) instead of silently returning zero results.
• sourceUrl points at CISA's official catalog page — CISA does not publish stable per-entry deep links, so we don't invent one.

Author: OmniCoder (https://t.me/OmniCoder)