‹ Back to Blog
▲ Security

How agentic AI handles CVE triage at scale

2026-03-04

CVE Overload

Security teams are drowning in CVE notifications. The National Vulnerability Database published over 28,000 CVEs in 2023 alone — roughly 77 per day. For a typical enterprise running hundreds of services across mixed Windows, Linux, and cloud infrastructure, determining which CVEs actually pose material risk is a full-time job.

The conventional approach — export from your scanner, CVSS-sort, send to operations for manual patching — creates a multi-week lag between disclosure and remediation. For critical vulnerabilities like Log4Shell or MOVEit, that window is catastrophically wide.

The Triage Problem

Not all CVEs with a high CVSS score are equally dangerous in your environment. A CVSS 9.8 remote code execution vulnerability in software you don't run is irrelevant. A CVSS 5.3 information disclosure in your publicly-facing authentication service is critical.

Effective triage requires context that static scores don't capture:

  • Is the affected service exposed to the internet?
  • Is a working exploit available in the wild (EPSS score)?
  • Does your configuration trigger the vulnerable code path?
  • Is a patch available, and what's the deployment complexity?

The Agentic Pipeline

IT Support AI approaches CVE triage as a multi-stage pipeline rather than a single query.

Stage 1: Asset Correlation

# Identify affected services from scanner output
$ run --module security.audit --cve CVE-2024-XXXX --scope all

[TRIAGE] Correlating CVE-2024-XXXX against asset inventory...
[TRIAGE] Affected package: openssl 3.0.x → 3.0.13
[TRIAGE] Identified 14 hosts running affected version
[TRIAGE] 3 hosts internet-facing: web01, web02, api-gateway

Stage 2: Exploitability Assessment

[DIAGNOSE] Checking EPSS score for CVE-2024-XXXX...
[DIAGNOSE] EPSS: 0.847 (84.7% probability of exploitation in 30 days)
[DIAGNOSE] PoC exploit: publicly available on GitHub
[DIAGNOSE] Attack vector: network, no authentication required
[DIAGNOSE] Risk classification: CRITICAL — immediate remediation required

Stage 3: Remediation Planning

The agent generates a prioritised remediation plan with rollback procedures:

[FIX] Remediation plan for CVE-2024-XXXX:

Priority 1 (internet-facing): web01, web02, api-gateway
  → apt-get install --only-upgrade openssl=3.0.13-1
  → Estimated downtime: 0 (live upgrade, no restart required)
  → Rollback: apt-get install openssl=3.0.11-1

Priority 2 (internal): db-server, app01-app11
  → Schedule during next maintenance window
  → Batch upgrade available: ansible-playbook patch-openssl.yml

[FIX] Executing Priority 1 on web01...

Automated Patch Application

With explicit authorisation, the agent can apply patches directly:

$ sudo apt-get install --only-upgrade openssl -y
Reading package lists... Done
Building dependency tree... Done
The following packages will be upgraded: openssl
1 upgraded, 0 newly installed

[FIX] ✓ web01 patched — openssl 3.0.13 confirmed
[FIX] ✓ web02 patched — openssl 3.0.13 confirmed  
[FIX] ✓ api-gateway patched — openssl 3.0.13 confirmed
[FIX] Incident logged. Audit trail exported to /var/log/itsupport/CVE-2024-XXXX.log

Compliance Integration

Every remediation action is logged with:

  • Operator identity (Supabase auth)
  • Timestamp (UTC)
  • Before/after version verification
  • Test result confirming fix

This creates a complete audit trail suitable for SOC 2, ISO 27001, and PCI-DSS reporting without any manual documentation effort.