Vulnerability Intelligence: Turning Advisories and Exploit Data Into Patching Priorities

Most organisations have more vulnerability data than they can use and less vulnerability intelligence than they need: scanners report tens of thousands of findings, while the few that attackers are actually exploiting arrive as scattered advisories, catalogue entries and vendor bulletins. Vulnerability intelligence is the function that collects those signals, checks them, joins them to your own assets and turns them into decisions with owners and deadlines. This guide covers the sources (CVE records and their enrichment, CISA KEV, EPSS, SSVC decision points, vendor and ecosystem advisories, exploit evidence), how to build a pipeline that fuses them, how to judge source reliability, and how to measure whether the function is changing what gets fixed. It is for vulnerability management leads, threat intelligence analysts and SOC engineers. The scoring maths of prioritisation is in the Vulnerability Prioritisation Guide; this page is about the intelligence that feeds it.

Key takeaways

• Intelligence is data plus context plus a decision. A CVE ID is data; "this is exploited, it is on our internet-facing VPN, the owner has 3 days" is intelligence.
• Exploitation evidence outranks severity. KEV entries and active-exploitation reports should jump the queue whatever their CVSS base score.
• No single source is complete or timely. CVE records arrive with gaps, enrichment lags, and vendor advisories often precede both, so pipelines need several sources and must record which one supplied each field.
• Asset context decides the outcome. The same vulnerability is an emergency on an exposed edge device and a backlog item on an isolated lab host.
• Measure exposure time, not ticket counts. The test of the function is how long exploited vulnerabilities stay open on your exposed assets.

What vulnerability intelligence is, and how it differs from scanning and threat intelligence

Scanning tells you which known weaknesses exist on your assets. Threat intelligence tells you who is attacking whom and how. Vulnerability intelligence sits between them: it answers which vulnerabilities matter now, why, and to which of your systems. It usually lives in the vulnerability management team with a dotted line to threat intelligence, and its outputs are a prioritised queue, emergency notifications and periodic exposure reports.

See the Threat Intelligence Guide and the Vulnerability Management Guide for the adjacent functions.

The source landscape

Good vulnerability intelligence combines four kinds of source: identification (what the vulnerability is and what it affects), exploitation evidence (whether it is being used), likelihood (whether it is likely to be), and remediation (what to do). The table lists the main public sources by kind.

For the details of individual sources see the CISA KEV Catalogue Guide, EPSS Guide, SSVC Guide, CSAF Security Advisories Guide and CVE, CWE and CPE Guide.

Reading exploitation evidence correctly

Exploitation evidence is the most valuable signal and the easiest to misread. Treat it as a scale, not a yes or no.

• Active exploitation: a KEV entry, a vendor statement of exploitation in the wild, or a government advisory. Act on it. The KEV catalogue held 1,754 entries in the 21 October 2026 release, 361 of them flagged as known to be used in ransomware campaigns.
• Public proof of concept: working code is published. SSVC's Exploitation decision point records this as "poc". Expect exploitation to follow for internet-facing products.
• Automatable: the Vulnrichment SSVC point "Automatable: yes" means an attacker can exploit the weakness at will without reconnaissance or per-target effort, which is what drives mass scanning.
• Technical impact: "total" means exploitation gives the attacker total control of the affected software.
• High EPSS, no other evidence: a statistical signal that the CVE resembles ones that get exploited. Use it to order the large middle of the queue, not to override direct evidence.

KEV deadlines have tightened. In the KEV data, entries added since 11 June 2026 reference BOD 26-04 "Prioritizing Security Updates Based on Risk" and CISA's "Forensics Triage Requirements". Of the 137 entries added from that date to the 21 October 2026 release, 111 carry a due date three days after addition and 26 carry fourteen days; during 2025 the usual gap was 21 days. Even outside the US federal sector, that is a useful benchmark for exposed systems. Directive details change: check the KEV page and the directive itself before relying on a specific deadline.

Building the vulnerability intelligence pipeline

1. Collect: pull the KEV JSON (it is also mirrored on GitHub and updated within minutes of cisa.gov), daily EPSS scores, CVE records including the CISA ADP container, OSV data for your ecosystems, and vendor advisories for your top 30 suppliers (CSAF feeds where offered, otherwise RSS or mailing lists).
2. Normalise: key everything by CVE ID and, where no CVE exists yet, by vendor advisory or ecosystem ID with a later mapping. Record source and timestamp for every field so you can explain a decision.
3. Match to assets: join on product and version from the CMDB, scanner, SBOM and cloud inventory. Product naming is the hard part: maintain a mapping table from CPE, package URL (purl) and vendor product names to your asset records. See the SBOM operations page.
4. Add context: internet exposure, business criticality, data sensitivity, compensating controls and whether the asset holds privileged or machine credentials.
5. Decide: apply your decision model (an SSVC-style tree or a matrix) to produce an outcome: act now, attend in the next cycle, track, or close as not affected with a VEX-style justification.
6. Disseminate: create tickets with owner, deadline and the evidence behind the decision; send emergency notices for active exploitation on exposed assets; publish a weekly exposure summary.
7. Feed back: record false positives, missed exploitation and remediation times, and adjust weights and sources quarterly.

A worked example

Consider one morning's intake. Three CVEs match your estate. The first has a CVSS base score of 9.8 in a library used by an internal reporting tool, an EPSS percentile in the bottom half, no proof of concept and no KEV entry: it goes to the normal cycle with the tool's owner. The second scores 7.2 but was added to KEV overnight, affects the SSL VPN appliance on your perimeter, and its Vulnrichment record shows "Automatable: yes" and "Technical Impact: total": it is an emergency, with a ticket to the network team inside the hour, a deadline matching the KEV due date, a forensic check of the appliance and rotation of the service account it uses for directory lookups. The third has no CVE enrichment yet, but the vendor's advisory says a fix is available and exploitation has been observed: the pipeline keys it by the vendor advisory ID, treats the vendor statement as active exploitation and links the CVE when it is enriched. Severity alone would have ranked these in exactly the wrong order.

Judging source reliability and timeliness

Treat vulnerability sources as you would any intelligence source and grade them. The Intelligence Confidence and Reliability Guide covers grading systems; the questions below apply them to vulnerability data.

Where identity fits

Exploited vulnerabilities and identity compromise are usually the same incident seen from two sides. Edge devices, VPNs and identity infrastructure are among the most exploited product types, and exploitation of them commonly leads to theft of session tokens, service account passwords and API keys stored on the appliance. Vulnerability intelligence should therefore flag when an exploited asset holds or brokers credentials, and the response should include rotating those credentials, not only patching. CISA's newer KEV required-action wording points to forensic triage for this reason: patching closes the hole, but not the access already gained. See the Edge Device Exploitation by Threat Actors Guide and the Threat Intelligence for Identity and NHI Guide.

Decision guidance: building, buying and scaling

• Small organisations: subscribe to KEV and your key vendors' advisories, use a scanner that ingests KEV and EPSS, and run a weekly review. A spreadsheet joined to the KEV CSV is a legitimate start.
• Mid-sized organisations: automate the pipeline steps above, add asset exposure data, and adopt a written decision model with deadlines per outcome.
• Large or regulated organisations: dedicate analysts, add commercial exploit intelligence where it measurably improves timeliness, consume CSAF and VEX at scale, and integrate with threat intelligence so actor reporting changes priorities.
• Build versus buy: commercial vulnerability intelligence feeds add earlier exploitation reporting and analyst notes; evaluate them on lead time over public sources and accuracy on your product set, using the Threat Intelligence Feed Evaluation Guide. Public sources remain the baseline.

Detection and measurement

• Monitor: new KEV entries matching your inventory (alert within the hour), EPSS jumps above your threshold for open findings, vendor advisories that state exploitation, and exploitation attempts in WAF, IDS and edge device logs for vulnerabilities in your open queue. See the T1190 Exploit Public-Facing Application Guide.
• KPI: time to awareness. Hours from KEV addition or vendor exploitation notice to a ticket with an owner.
• KPI: exposure window for exploited vulnerabilities. Median days a KEV-listed vulnerability stays open on internet-facing assets.
• KPI: match rate. Share of advisories for your products that the pipeline matched to assets automatically.
• KPI: queue precision. Share of "act now" items later confirmed relevant (not a false product match or not affected).
• KPI: missed exploitation. Exploited vulnerabilities found in your estate that the pipeline had not ranked as urgent; review each one.

Framework mapping

Common failure patterns

• Queue by CVSS base score alone: thousands of "critical" findings bury the handful on KEV.
• Single-source dependence: waiting for NVD enrichment before acting, when the vendor advisory and KEV entry already say what to do.
• No asset context: intelligence that cannot say which hosts are affected and who owns them produces bulletins, not fixes.
• Patch and forget on edge devices: fixing an exploited appliance without checking for compromise and rotating the credentials it held leaves the attacker's access in place.
• Treating EPSS as a threshold switch: ignoring everything below a percentile cut-off, including vulnerabilities on your most exposed systems.
• Unexplained decisions: no record of which source and score drove a priority, so owners dispute deadlines and exceptions pile up. See the Remediation SLAs and Vulnerability Exceptions Guide.

Practitioner checklist

• Ingest KEV, EPSS, CVE records with the CISA ADP container, OSV data and advisories from your top suppliers into one store keyed by CVE and vendor ID.
• Record the source and timestamp of every field used in a decision.
• Maintain a product name mapping (CPE, purl, vendor names) to your asset inventory and measure the automatic match rate.
• Alert within the hour when a new KEV entry or vendor exploitation notice matches an internet-facing asset.
• Write a decision model with outcomes and deadlines, using exploitation evidence before likelihood and severity.
• Include forensic checks and credential rotation in the response for exploited edge and identity systems.
• Keep at least two sources per signal and a documented fallback if CVE or NVD data stops.
• Report exposure window for exploited vulnerabilities and missed exploitation to leadership monthly.

Standards and references

• CISA: Known Exploited Vulnerabilities Catalog
• CISA: kev-data repository
• CISA: Vulnrichment
• FIRST: Exploit Prediction Scoring System (EPSS)
• OpenSSF: Open Source Vulnerability (OSV) Schema
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Vulnerability Prioritisation Guide · Risk-Based Vulnerability Management Guide · CISA KEV Catalogue Guide · EPSS Guide · Zero-Day and Exploited Vulnerabilities Guide