SI-2 on Splunk

What this finds

An asset still reports an active finding for a CVE in CISA's Known Exploited Vulnerabilities catalogue, after the remediation date CISA published for that entry.

The requirement

The organization must identify, report, and correct information system flaws, and install security-relevant updates within an organization-defined time period of their release.

NIST SP 800-53 Rev. 5 — SI-2 (Flaw Remediation).

NIST requires flaws to be corrected within a period the organization defines. This pack does not attempt to judge every CVE. It narrows to CISA's Known Exploited Vulnerabilities catalogue — the subset with confirmed exploitation in the wild — and reports the ones still present after the remediation date CISA published. Which asset population is in scope, and whether a compensating control justifies an exception, remain organization-defined.

How this maps to the CISA performance goals

The Cross-Sector Cybersecurity Performance Goals are a voluntary baseline published by CISA — the U.S. federal agency for critical-infrastructure cybersecurity — written for organizations too small to employ security staff. This control speaks to:

• 2.B — Mitigate known vulnerabilities
  The goal is mitigating known vulnerabilities; the pack finds entries from CISA's own Known Exploited Vulnerabilities catalogue still active past the remediation date CISA published for them.
• 2.A — Manage organizational assets (partial — see note)
  Reaches the asset inventory only through whatever the vulnerability scanner already covers. An asset the scanner never sees produces no row here, so CM-8 rather than this pack is what evidences inventory completeness.

See the full coverage map, including the goals no query can answer →

Evidence this query needs

The query

Published as si-2-kev-overdue.splunk.spl. Reads index=vuln sourcetype=vulnerability:findings, kev_catalog.csv (lookup). Requires: Search access to the vulnerability index; Read on the lookup.

Before this returns anything, index=vuln sourcetype=vulnerability:findings has to be reaching Splunk Enterprise / Enterprise Security, and kev_catalog.csv (lookup) has to be landed there. If not, the query reports nothing found — which looks exactly like nothing wrong. What has to be switched on first →

index=vuln sourcetype=vulnerability:findings status=active
| eval kev_cve=upper(cve_id)
| dedup resource_id, kev_cve
| lookup kev_catalog.csv cve_id AS kev_cve
    OUTPUT due_date, product AS kev_product
| where isnotnull(due_date) AND due_date!=""
| eval due_epoch=strptime(due_date,"%Y-%m-%d")
| where due_epoch < now()
| eval days_overdue=round((now()-due_epoch)/86400)
| table resource_id, resource_type, kev_cve, kev_product,
        severity, due_date, days_overdue
| sort - days_overdue, resource_id

Open this pack on Splunk to adjust the settings and download it →

The interactive version opens on Splunk — the platform on this page — even if your environment profile does not list it.

Settings you decide

NIST states the objective and leaves these to your organization. The interactive version of this pack applies them to the query for you.

Grace period after the due date (days) (default 0)

Findings are only reported once this many days have passed beyond CISA's published remediation date.

Limit to specific assets (optional)

Paste resource identifiers, one per line.

What this query returned when it was run

Executed against Splunk Enterprise 10.4.2 on 2026-08-07 against purpose-built test data. The software examined 3 records and returned 2 results in 0.10300000000000001 seconds.

Test data, not a real organization. It shows the query executes and returns the intended shape of result.

Running it continuously

Correlation search → notable event

Search type:      Correlation search (Enterprise Security)
Cron schedule:    0 */12 * * *   (twice daily)
Time range:       -7d to now
Trigger:          Number of results > 0
Alert action:     Create notable event
Urgency:          Critical
Security domain:  Threat
Drill-down:       index=vuln resource_id="$resource_id$"
Throttling:       Suppress 24h on resource_id and kev_cve

vulnerability:findings is a vendor-neutral sourcetype. Forward Tenable, Qualys, Rapid7, or Defender findings with resource_id, cve_id, and status and this published search covers them with no new query written.

Before you act on a result

• Is the KEV catalogue copy current? CISA adds entries continuously, and a stale file narrows this query silently.
• Has the vulnerability been mitigated in a way the scanner cannot see, such as removing the affected component from the network path?
• Is the asset in scope for patching at all, or is it a decommissioned system still reporting?
• Does a documented compensating control with an expiry cover this, and has that expiry passed?
• Is the scanner's coverage complete for this asset population, or would an unscanned host show nothing here regardless?

Common questions

How do I check for known-exploited vulnerability past its remediation date in Splunk?

Run the published SPL query on this page against Splunk Enterprise / Enterprise Security. It reads index=vuln sourcetype=vulnerability:findings, kev_catalog.csv (lookup) and reports: An asset still reports an active finding for a CVE in CISA's Known Exploited Vulnerabilities catalogue, after the remediation date CISA published for that entry.

What permissions are needed to run this Splunk query?

Search access to the vulnerability index; Read on the lookup.

What evidence does SI-2 need that Splunk cannot produce?

Known Exploited Vulnerabilities catalog (kev_catalog.csv). CISA's catalogue of vulnerabilities with confirmed exploitation in the wild, joined to your own vulnerability findings so SI-2 reports the ones that are actually being used against organizations rather than everything with a CVE. Download it from CISA rather than typing it: the authoritative CSV is published at https://www.cisa.gov/known-exploited-vulnerabilities-catalog and is a US federal work in the public domain. At minimum it must carry: cve_id, due_date.

Does a result from this query mean the control has failed?

A KEV entry past its due date does not establish that the vulnerability was exploited in your environment, or that exploitation is possible given your configuration. It establishes that a vulnerability confirmed to be exploited elsewhere is still reported as present after the date the federal catalogue set for fixing it. Scanner coverage gaps mean the absence of rows is not evidence of the absence of the condition.

The same control on other platforms

• SI-2 on Microsoft Sentinel — KQL
• SI-2 on AWS — SQL (Athena) + Lambda
• All platforms for SI-2