Vulnerability Intelligence

CISA KEV and AI Systems: What Security Teams Should Track

How security teams can connect CISA KEV exploitation evidence to real AI infrastructure, exposure, ownership, and verification.

By PermsAI Editorial Team

CISA’s Known Exploited Vulnerabilities (KEV) Catalog is a practical signal for defenders: it lists vulnerabilities for which CISA has evidence of exploitation and considers remediation a priority for the federal enterprise. It is not an AI-only list, a replacement for a complete vulnerability inventory, or proof that a particular customer environment is compromised. AI systems inherit the same operating systems, web frameworks, identity services, container runtimes, orchestration planes, document parsers, and cloud services as other applications. Security teams should therefore connect KEV updates to an accurate inventory of the AI stack.

What the KEV Catalog tells you

The catalog is a living CISA data set. Its current feed includes fields such as CVE ID, vendor and product, vulnerability name, date added, short description, required action, due date, and optional ransomware-use, notes, and weakness information. CISA publishes machine-readable JSON and a schema, so teams can automate ingestion while still reviewing the source record. Entries are added because exploitation is known, not because a CVSS threshold was crossed.

That distinction matters. A KEV entry is evidence that exploitation has occurred somewhere and that the issue deserves heightened attention. It does not establish that your version is affected, that your deployment is reachable, that the exploit conditions are present, or that an attacker accessed your system. Conversely, a CVE absent from KEV is not safe by default: exploitation may be undiscovered, underreported, non-public, or not yet assessed by CISA. Use KEV as a prioritization input alongside vendor advisories, NVD enrichment, asset inventory, configuration, reachability, and local detections.

CISA’s federal obligations also require precision. BOD 22-01 established the catalog-based remediation model in 2021. In 2026, BOD 26-04 superseded and revoked the earlier directives for federal civilian executive branch agencies and moved to a broader, risk-based remediation approach that considers exposure, exploit automation, technical impact, and KEV status. Private-sector teams can use the catalog as high-value guidance, but a KEV due date is not automatically a legal deadline for a commercial tenant.

Why AI teams should track ordinary KEVs

An AI product may contain no component named “AI” in a KEV record. The exploitable path can sit in an internet-facing reverse proxy, authentication library, API gateway, Kubernetes control plane, container runtime, GPU driver, notebook service, object store, message broker, PDF parser, image library, vector database, or developer platform. A compromise in one of those layers can expose prompts, retrieval data, credentials, model endpoints, or tool integrations.

Inventory is the bridge between a generic CVE and an AI decision. Map each product name and version to an owner, deployment, environment, network path, tenant boundary, and business criticality. Include managed services and vendor-hosted inference where you cannot inspect the underlying package. For those services, record the provider’s advisory, patch or mitigation statement, feature configuration, and any customer-side control such as network restriction or credential rotation.

AI STACK KEV EXPOSURE MAP

AI stack layer	Component class	Why KEV matters	Evidence to collect	Likely owner
Edge and web	Reverse proxy, framework, API gateway	Public reachability can turn a generic flaw into model or tenant exposure	Hostnames, routes, versions, WAF and access logs	Web/platform
Identity	SSO, OAuth library, session service	Account takeover can unlock prompts, data, and tools	Identity provider notices, configuration, sign-in telemetry	IAM
Orchestration	Kubernetes, container runtime, scheduler	Control-plane or workload escape can cross AI jobs	Cluster inventory, images, admission policy, network paths	Platform
Inference	Model server, runtime, GPU driver	A reachable service may expose models, files, or execution capacity	Provider/upstream advisory, image digest, endpoint exposure	ML/platform
Data and RAG	Object store, parser, vector database	Disclosure or tampering can poison context or leak tenant documents	Bucket/index ownership, parser versions, retrieval tests	Data/AI platform
Agent tools	Connector, SDK, webhook or job worker	Compromise can convert model proposals into external side effects	Tool inventory, credentials, policy logs	Application/security
Developer plane	Notebook, CI runner, registry	Build or experiment compromise can ship a poisoned artifact	SBOM, runner image, registry and pipeline logs	Engineering

KEV versus other security signals

No single signal answers applicability and urgency. Preserve the provenance and date of each source:

Signal	What it tells you	What it does not tell you
CVSS	Standardized technical severity and attack conditions	Whether your asset is deployed, reachable, or exploited
CISA KEV	CISA has documented known exploitation and added the CVE to its catalog	That your environment is compromised or affected by the exact version
Vendor advisory	Product-specific affected ranges, fixes, mitigations, and sometimes exploitation notes	That the vendor’s fix is installed in your running artifact
Public proof of concept	Someone published technical material demonstrating a path	That the material applies to your configuration or that exploitation succeeded
Local detection	Your telemetry observed a relevant request, process, or indicator	That every vulnerable asset was found or that an absence means safety

For a deeper severity discussion, link the CVSS vector and local context using PermsAI’s AI vulnerability intelligence triage, AI security advisory reading guide, and CVSS for AI vulnerabilities.

KEV-TO-AI TRIAGE PIPELINE

CISA KEV update → Product/component match → Local asset inventory → Version match → Deployment/exposure → Owner → Remediation → Local verification → Closure evidence

Ingest and normalize. Track the catalog version, release date, CVE ID, date added, due date, and source URL. Deduplicate updates without erasing history.
Match the component. Match vendor, product, package name, image digest, driver, or managed-service feature. Do not rely on an AI-generated inventory assertion.
Validate the version. Check lockfiles, SBOMs, package metadata, running images, and backports. A product may be patched while its base image or sidecar remains vulnerable.
Assess deployment and exposure. Identify public routes, internal reachability, credentials, feature flags, tenant data, and whether the vulnerable code path is enabled. A private label is not evidence of isolation.
Assign an owner and treatment. Patch or upgrade where possible. If a provider owns the component, request confirmation, apply a documented configuration mitigation, restrict access, disable the feature, or rotate exposed credentials.
Verify and close. Confirm the deployed artifact and configuration, retest the relevant path, review detections, and retain evidence. Closure means the local risk decision is supported, not merely that a ticket says “fixed.”

Prioritization for managed AI services

A hosted model or vector service may never expose a package version. Keep the KEV record, then ask the provider whether the service includes the affected component, whether remediation is complete, and which customer controls are recommended. While waiting, reduce exposure: disable an optional connector, restrict egress, narrow API scopes, enforce an identity gateway, or move sensitive workloads to a supported configuration. Treat provider statements as evidence with a date and scope; do not imply that a customer can patch provider internals.

Operational ownership and evidence

KEV processing works when remediation is accountable. The security team can curate the feed and set urgency, but platform, IAM, data, application, and service owners must confirm applicability. Capture the CVE, catalog version, local asset ID, version evidence, exposure decision, owner, treatment, verification result, and closure date. Feed status and local detections into the security observability process without copying sensitive prompts or documents into tickets.

For federal teams, map the current BOD 26-04 process and agency procedures to your workflow. For other organizations, define your own service-level objectives based on exposure, exploit evidence, asset criticality, customer commitments, and recovery needs. A CISA due date can inform urgency; it does not replace local governance.

Practical tracking checklist

Subscribe to the official KEV feed or API and record catalog release metadata.
Reconcile vendor/product names with SBOMs, image digests, runtime inventory, and managed-service records.
Check version, configuration, reachability, tenant impact, and compensating controls before declaring applicability.
Compare KEV with CVSS, vendor advisories, NVD, public reports, and local detections; preserve each source and date.
Assign a named owner, treatment, target date, and escalation path for every affected AI-stack asset.
Retest the real deployment after patching, mitigation, provider confirmation, or feature disablement.
Retain evidence of the running version, configuration, logs, and decision; revisit when the catalog or service changes.

The catalog should be treated as a continuously changing operational input: re-evaluate exposure when an asset is rebuilt, a provider changes its implementation, or a new network path is enabled.

Sources

Tracking KEV entries is a way to make exploitation evidence visible across an AI stack. The security decision still belongs to the organization that operates the asset: verify the component, understand the path, contain exposure, remediate, and prove the result.