Vulnerability Management for SOC Teams: Prioritization, CISA KEV, and Detection Queries

Vulnerability management and SOC operations are often treated as separate programs with separate teams. In practice, the most effective SOCs use vulnerability data directly in their detection workflow — knowing which CVEs are being actively exploited helps prioritize where to hunt, what to patch, and when to treat an alert as higher severity because the affected software is exposed.

This post covers how SOC teams use vulnerability data operationally — CISA KEV integration, CVSS vs EPSS prioritization, correlating scan data with active exploitation, and the detection queries that connect vulnerability exposure to threat detection.

CVSS vs EPSS: Which Severity Score to Trust

CVSS (Common Vulnerability Scoring System) scores vulnerabilities based on technical characteristics — attack vector, complexity, privileges required, impact. A CVSS 9.8 sounds alarming. In practice, many CVSS 9.8 vulnerabilities have never been exploited in the wild because they require specific configurations, old software versions, or network access that doesn't exist in most environments.

EPSS (Exploit Prediction Scoring System) takes a different approach. It predicts the probability of a vulnerability being exploited in the next 30 days based on threat intelligence, PoC availability, and historical exploitation patterns. An EPSS of 0.90 means the model predicts a 90% chance of exploitation in the next 30 days — that's a much more actionable signal than a CVSS score.

CISA KEV Integration into SOC Workflows

The CISA Known Exploited Vulnerabilities catalog is updated multiple times per week with CVEs confirmed exploited in the wild. Every entry includes the affected vendor, product, required remediation date, and whether the CVE has been used in ransomware campaigns. This is the most operationally relevant vulnerability feed available to SOC teams.

Three ways to integrate CISA KEV into SOC operations:

• Alert enrichment — when an alert fires on a system, automatically check whether that system has any open KEV entries and surface them in the ticket. A credential dumping alert on a host with an unpatched CVE that's in the KEV catalog changes the risk picture significantly
• Hunt triggers — when a new KEV entry is added for software you run, trigger a proactive hunt for exploitation indicators specific to that CVE before an alert fires
• Patch SLA enforcement — use KEV due dates as hard patch deadlines and create SIEM alerts when systems with KEV exposures approach their due date without the vulnerability being remediated

Detecting Exploitation Attempts for Known CVEs

When a CVE is actively exploited, the exploitation patterns are often well documented within days of the KEV listing. The detection isn't generic — it's specific to how that vulnerability is exploited. Here's the pattern for detecting exploitation attempts against a critical RCE vulnerability:

DeviceFileEvents
| where TimeGenerated > ago(1d)
| where ActionType == "FileCreated"
// Web shells typically written to web-accessible directories
| where FolderPath has_any(
    "\\inetpub\\", "\\wwwroot\\",
    "\\webapps\\", "\\htdocs\\"
  )
// Web shell extensions
| where FileName has_any(
    ".aspx", ".asp", ".php",
    ".jsp", ".jspx"
  )
// Exclude legitimate deployment processes
| where InitiatingProcessFileName !in(
    "msdeploy.exe", "w3wp.exe",
    "WebDeployAgent.exe"
  )
| project TimeGenerated, DeviceName,
    FolderPath, FileName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by TimeGenerated desc

index=firewall_* OR index=proxy_*
earliest=-6h latest=now
/* Look for high-volume connection attempts
   to specific ports associated with known CVEs */
| eval target_port=coalesce(dest_port, dpt)
| where target_port IN (8080, 8443, 4848,
    7001, 9200, 6379)
/* Common ports for frequently exploited services:
   WebLogic (7001), Elasticsearch (9200), Redis (6379) */
| stats
    count as Attempts
    dc(src_ip) as UniqueSources
    values(src_ip) as SourceIPs
    by dest_ip target_port
| where Attempts > 50 AND UniqueSources > 3
| sort - Attempts

Correlating Vulnerability Scan Data with Alert Context

The most powerful use of vulnerability data in a SOC is correlation — when an alert fires, automatically checking whether the affected system has open vulnerabilities relevant to the alert type. A lateral movement alert on a host with an unpatched Kerberos vulnerability is fundamentally different from the same alert on a fully patched host.

// Requires vulnerability scanner data ingested into Sentinel
// Works with Tenable, Qualys, Defender TVM output
let CriticalVulnHosts =
    DeviceTvmSoftwareVulnerabilities
    | where CvssScore >= 9.0
    | where IsExploitAvailable == true
    | distinct DeviceName, CveId, CvssScore;
SecurityAlert
| where TimeGenerated > ago(7d)
| where AlertSeverity in ("High", "Medium")
| join kind=inner CriticalVulnHosts
    on $left.CompromisedEntity == $right.DeviceName
| project TimeGenerated,
    AlertName, AlertSeverity,
    CompromisedEntity,
    CveId, CvssScore
| order by CvssScore desc, TimeGenerated desc

Building a KEV Monitoring Alert

When a new CVE is added to the CISA KEV catalog, you want to know within hours whether any systems in your environment are affected. This requires ingesting the KEV catalog into your SIEM and joining it against your asset inventory or vulnerability scan data.

// Run daily — requires KEV data ingested as custom table
// and vulnerability scan data in DeviceTvmSoftwareVulnerabilities
let NewKEVEntries =
    CISA_KEV_CL
    | where dateAdded_t > ago(24h)
    | project cveID_s, vendorProject_s,
        product_s, shortDescription_s,
        knownRansomwareCampaignUse_s;
DeviceTvmSoftwareVulnerabilities
| join kind=inner NewKEVEntries
    on $left.CveId == $right.cveID_s
| summarize
    AffectedDevices = dcount(DeviceName),
    DeviceList = make_set(DeviceName)
    by CveId, vendorProject_s, product_s,
        shortDescription_s, knownRansomwareCampaignUse_s
| order by AffectedDevices desc