Threat and vulnerability management: How to prioritize what attackers actually exploit

Threat vulnerability management proves its value on the morning an internet-facing Medium with confirmed exploitation lands below dozens of theoretical Criticals. The scanner is not wrong; its severity order answers a different question. Threat and vulnerability management (TVM) repairs that queue by combining vulnerability data with exploitation evidence, exposure, asset criticality, and ownership.

The workload makes the distinction concrete. NIST enriched nearly 42,000 CVE records in 2025, while FIRST reports observed exploitation activity for roughly 2.5% to 3% of published CVEs in a 30-day window. The remaining vulnerabilities are not automatically safe. They simply should not all consume the same urgency.

This guide builds the operating model behind that decision. It explains the discipline, shows how EPSS and the CISA Known Exploited Vulnerabilities catalog change triage, lays out the policy and ownership model, tests software against the real workflow, and maps the result to cloud-native execution across scanners, asset context, ticketing, and reporting.

Key insights

• Treat CVSS as a severity signal, not a ready-made remediation queue. Confirmed exploitation and exposure can move a lower-severity vulnerability ahead of a Critical finding that is unreachable in your environment.
• CISA KEV records confirmed exploitation; EPSS estimates the probability of exploitation activity during the next 30 days. FIRST recommends following KEV when the signals appear to conflict.
• A useful TVM record needs enough context to support action: affected asset, environment, exposure, current owner, threat signal, due date, exception state, and verification status.
• Prioritization without an owner and an SLA produces a sharper report, not a functioning program. The loop closes only when the fixing team receives the evidence and a rescan verifies the change.
• If scanners already cover the estate, buying another scanner may add findings without improving decisions. Evaluate whether the missing layer is aggregation, threat context, ownership, workflow, or evidence history.

What is threat and vulnerability management?

Threat and vulnerability management (TVM) is the practice of identifying, prioritizing, and remediating security vulnerabilities with threat intelligence, so limited remediation capacity goes first to flaws with credible exploitation evidence, reachable assets, and meaningful business impact instead of following technical severity alone.

A severity-led vulnerability-management program usually discovers flaws, maps affected systems, and sorts work by CVSS. TVM keeps those mechanics, then adds exploitation evidence and the affected asset's operating context. The CVSS v4.0 specification treats the Base score as intrinsic severity under a reasonable worst-case assumption. It directs consumers to refine that score with threat, environmental, and organizational factors.

Jay Jacobs and the EPSS research team put the failure mode plainly:

“CVSS does not perform well when used to prioritize exploited vulnerabilities over those without evidence of exploitation.” - Jay Jacobs et al., Enhancing Vulnerability Prioritization

That finding does not make severity disposable. It defines its job. Keep CVSS as technical impact evidence; let threat and asset context set the queue position and remediation SLA.

Consider two illustrative findings:

• An isolated lab host carries a CVSS 9.8 vulnerability with no known exploitation. Keep it open, but use the standard remediation window.
• An internet-facing production gateway carries a CVSS 6.5 vulnerability newly listed in CISA's Known Exploited Vulnerabilities Catalog. Move it to urgent validation and assign the service owner.

The gateway moves first because recent confirmed exploitation and local reachability overlap. FIRST's EPSS guidance explains the boundary: EPSS forecasts observed exploitation over the next 30 days, while KEV records confirmed past exploitation. Neither signal proves that your asset is present, reachable, or unprotected by compensating controls.

One naming trap can derail product research. Older Microsoft Learn material uses “Microsoft Threat Vulnerability Management.” Microsoft's current documentation calls the product Microsoft Defender Vulnerability Management. Here, TVM means the security discipline, not a Microsoft SKU.

A useful threat and vulnerability management definition therefore has an observable test: new threat or asset evidence must be able to reorder the work. The next section examines which signals deserve that power and where each one can mislead.

Threat-centric prioritization: the core of TVM

FIRST reports roughly 61,000 CVEs published during the latest 12-month period. The operational bottleneck is rarely a missing score. Scanner evidence, exploitation data, asset relationships, and ticket state usually arrive in different records. Threat intelligence and vulnerability management become one process only when those records are joined without losing their source or timestamp.

Each feed answers a different triage question. Threat-centric vulnerability management uses five signals, but each one has a different job. Keeping the raw fields together lets a responder replay the decision later.

Signal	Fields worth retaining	Decision boundary
CVSS	Score, vector, version, publication date	Describes technical severity and exploitation conditions. A Base score does not establish current attacker activity or local exposure.
EPSS	Probability, percentile, score date	Forecasts observed exploitation activity across EPSS data partners during the next 30 days. It cannot see your inventory or controls.
CISA KEV	Date added, required action, source link	Confirms exploitation occurred. A recent addition deserves urgent validation, but KEV does not prove that your asset was attacked.
Campaign intelligence	Source, observation date, targeted product or sector, confidence	Raises priority when the campaign matches your technology and exposure. Attribution alone does not establish a reachable path.
Local context	CI, affected version, runtime state, exposure, service, data class, controls, owner	Converts global evidence into a local action and remediation SLA. Stale ownership or reachability data can misroute the result.

Use gates before weights. A threat intelligence vulnerability management queue should apply the evidence in this order:

1. Confirm the vulnerable condition. Match the finding to the deployed package, image, appliance, or managed-service version. Every exclusion needs evidence and a recheck date.
2. Escalate credible exploitation. Recent KEV additions and relevant campaigns trigger urgent validation. EPSS helps order the much larger non-KEV population.
3. Test the attack path. Inspect public reachability, authentication, segmentation, runtime state, and compensating controls. Unknown exposure stays unknown until someone verifies it.
4. Choose the response. Business impact, current ownership, change risk, exception state, and closure evidence determine the action and SLA.

Cyber systems engineer Emad Sherif and his co-authors describe the design target in a 2026 vulnerability-prioritization preprint:

“We propose a composite Key Risk Indicator grounded in expected-loss decomposition, integrating dimensions of threat, impact, and exposure.” - Emad Sherif, Iryna Yevseyeva, Vitor Basto-Fernandes, and Allan Cook

“Integrating” does not mean multiplying whatever numbers happen to be available. FIRST explicitly warns that multiplying calibrated EPSS probability by ordinal CVSS produces no interpretable risk measure. Either validate a composite model against outcomes or keep the raw fields visible behind an explainable decision rule.

The ticket must preserve the decision, not just the priority. Carry the finding source and timestamp, affected CI and version, CVSS vector, dated EPSS value, KEV date added, threat-intelligence source, exposure evidence, last control check, business service, owner, exception expiry, and closure test. A ticket containing only “Risk: 87” becomes useless when a score changes or an auditor asks why it jumped the queue.

Re-prioritization should run when evidence changes, not only after the next scanner cycle. A new KEV entry, public endpoint, expired control, asset restart, or campaign match can move an existing record forward. Retirement or verified containment may change the action, but it should not erase the earlier decision trail. For exploited vulnerabilities, fixing the condition and checking for compromise remain separate outcomes.

That is threat-based vulnerability management in practice. The wider cloud vulnerability lifecycle covers discovery through verified closure. If exploitation is active and no vendor patch exists, follow the containment and investigation path in the zero-day response guide.

Operating vulnerability management and threat intelligence as one queue requires named sources, decision owners, SLAs, exception rules, and closure evidence. The next section turns those controls into a TVM program.

Building a threat and vulnerability management program

A working TVM program is a closed operating loop: define the estate, collect current evidence, send risk-ranked work to an accountable owner, and prove the condition is gone. Scanners supply observations; policy, ownership, exceptions, and review cadence keep them moving.

Run the threat and vulnerability management process in seven stages:

1. Define the denominator. Express scope as a reproducible inventory query, rather than “all production.” Record eligible CI classes, lifecycle states, and exclusions. Compare that population with the cloud CMDB inventory; assets without scan evidence belong in the coverage gap.
2. Collect time-bound evidence. Ingest scanner findings alongside dated EPSS values, CISA KEV status, relevant campaign intelligence, and vendor advisories. Preserve each source and observation time.
3. Test scan coverage. Require a successful authenticated assessment, or another approved source, within the asset’s freshness window. Separate unsupported, unreachable, retired, and formally exempt assets because each state requires a different response.
4. Prioritize with the established decision rule. Apply the threat, exposure, control, and business-impact gates from the previous section. Store the resulting tier and reason code; avoid rebuilding the entire calculation inside each downstream ticket.
5. Route an executable action. Assign remediation to the current service owner with an SLA, change window, and closure test. A missing or stale ownership record triggers mapping repair and escalation.
6. Verify the outcome. Rescan, or collect authoritative package, image, configuration, or retirement evidence. Tie proof to the same CI and vulnerable condition; a clean replacement host does not close an active predecessor. Confirmed exploitation still requires incident-response triage.
7. Review performance and drift. Hold an operational review weekly and a governance review monthly. Track eligible-asset coverage, KEV SLA attainment, median and 90th-percentile remediation time by threat tier, expired exceptions, and reopened findings. Fleet-wide averages can hide the oldest exposed records.

Write policy as an operating contract. A threat and vulnerability management policy should state the scope query, evidence-freshness rules, priority tiers, SLAs, escalation, exception approver and expiry, closure evidence, and reporting cadence. Give every field a named maintainer and a test.

A threat and vulnerability management framework can map that contract to NIST CSF 2.0 and use the patch lifecycle as a response playbook. NIST treats CSF outcomes as non-prescriptive, so local thresholds and decision rights stay in policy.

Split ownership by decision. Security owns prioritization and reporting; the platform or CMDB owner owns the inventory denominator and relationships. Service teams handle treatment and verification. A named risk authority accepts expiring exceptions. A threat and vulnerability management system can preserve those handoffs, but it cannot authorize risk acceptance.

That division is easy to blur when the scanner team controls the queue. The authors of NIST SP 800-40 Rev. 4, Murugiah Souppaya and Karen Scarfone, make the ownership requirement explicit:

“Leadership at all levels of the organization, business/mission owners, and security/technology management teams should jointly create an enterprise patch management strategy.” - Souppaya and Scarfone, NIST SP 800-40 Rev. 4

Security can set the order and report risk, but service owners decide how production changes. Risk authorities approve exceptions because acceptance carries business impact beyond the scanner queue. Patching is one treatment path; configuration change, containment, replacement, or retirement may fit better.

Use a copyable policy starter. Effective threat and vulnerability management templates capture seven decisions before adding narrative:

TVM policy starter

• Scope: [saved inventory query and exclusions]
• Evidence: [approved sources and maximum age]
• Priority: [tiers and decision rule]
• Ownership: [security, platform/CMDB, service, and risk roles]
• SLA: [tier, action, deadline, and escalation]
• Exception: [approver, rationale, expiry, and compensating control]
• Closure: [test, reviewer, metrics, and review cadence]

Keep the completed artifact version-controlled and test it against live records after every policy change.

Durable threat and vulnerability management best practices are auditable. For any record, the team can reproduce why it was in scope, who owned it, what deadline applied, and what evidence closed it. During the first month, sample ten closed records and ten overdue records. If an analyst cannot reconstruct those four decisions, revise the relevant policy field before automating more workflow.

With those controls fixed, automation has a stable contract. The same scope, tier, owner, deadline, exception, and closure identifiers must survive every handoff. The next section maps that contract to Cloudaware.

Running TVM on Cloudaware

TVM stalls when the scanner, asset inventory, and ticketing system describe the same risk in incompatible records. Cloudaware links source evidence to CMDB context. The resulting cohort moves into owned remediation, then back into status reporting. External scanners remain the systems of record for imported findings; Jira, ServiceNow, and PagerDuty remain action destinations.

Unified vulnerability data with threat-informed prioritization

Begin with provenance. Findings can enter Cloudaware vulnerability management through Vulnerability Scanning as a Service or connected products such as Qualys, Tenable Security Center, Rapid7 InsightVM, and CrowdStrike. Host-based assessments in the service depend on Breeze Agent, so they should not be counted as agentless coverage.

After ingestion, each finding resolves to a configuration item. Documented risk factors include severity, exploitability, asset exposure, and business context. Dashboards separately report scan coverage, vulnerability age, and exposure, with filters for fields such as application, tag, and cloud account. That distinction keeps a display filter from being mistaken for a scoring input.

Keep the original scanner, native ID, source status, and observation dates. If Qualys reports an active condition after another source marks it resolved, a merged status conceals the disagreement. Send that record back for validation.

The NIST security-testing team makes the evidence boundary explicit:

“Because no individual technique provides a comprehensive picture of an organization’s security when executed alone, organizations should use a combination of techniques.” - Karen Scarfone, Murugiah Souppaya, Amanda Cody, and Angela Orebaugh, NIST SP 800-115

For TVM, combining techniques does not mean averaging conflicting statuses. Retain both observations, then apply the agreed closure rule.

The asset graph that makes prioritization trustworthy

Routing becomes reliable after each vulnerability resolves to the asset and its production relationships. The Cloudaware CMDB maintains configuration records, dependencies, applications, ownership data, and change history across connected environments. That graph can expose the component that keeps recreating vulnerable hosts.

A decision trace shows the difference:

• Finding: Qualys reports an OpenSSH CVE on 43 active instances.
• Context: All support the production payments service and inherit from one source image.
• Action: Correct the image and handle already-running instances as a separate scope.
• Proof: Rescan the instances, then verify that new instances from the corrected image stay clear.

That relationship changes the work. Patching 43 instances may clear today's queue, yet leaving the image untouched recreates the exposure at the next deployment.

Closing the loop: routing, SLAs, and reporting

The handoff is where a threat and vulnerability management system earns its place. Cloudaware supports custom task assignment and can generate or update Jira, ServiceNow, or PagerDuty records as configured vulnerabilities are discovered or resolved. The resulting work item remains connected to its finding and asset context.

Choose ticket granularity deliberately:

• One finding per ticket gives each condition an independent owner, due date, and closure event but can swamp the destination queue.
• One task per application, owner, and risk tier controls volume. Its member findings must remain visible until every included condition clears.

When a later scan clears a member finding, update the existing task rather than creating a disconnected success event. External-ticket closure depends on the configured destination rules. Grouped work should close only after every member meets the agreed verification condition.

Use the Cloudaware dashboard to isolate an operational cohort; return to the source finding and linked CI before approving closure.

Build the operational view around scan freshness, vulnerability age, exposure, remediation status, and the responsible team. Raw totals can fall while old production findings remain open. Closure is credible only while source status, CI, ticket, and verification time still join.

Threat and vulnerability management software: how to choose

A TVM platform fits only when it preserves the evidence chain inside your existing stack. That chain runs from finding to verified closure. Treat category labels cautiously. Threat and vulnerability management tools may be scanners, prioritization engines, exposure-management platforms, or workflow layers.

Do not let a prepared demo stand in for the integration test. For the proof of concept, supply an anonymized sample from one production service. Include records from each in-scope scanner, current asset relationships, recent ownership history, exceptions, and matching ITSM tickets. Remove hostnames, IP addresses, cloud account IDs, and user details before sharing it.

Run that same sample through five acceptance tests:

• Make the threat signal explain itself. Ask the vendor to open one prioritized finding and identify the source, observation date, and refresh state behind its exploitation signal. Missing EPSS, CISA Known Exploited Vulnerabilities (KEV), or campaign data should remain visible. A colored risk badge without provenance fails this test.
• Test the day-60 ownership state. Change the application's responsible team during the proof of concept. Alternatively, replay a real transfer from the supplied history. The open finding should resolve to the maintained relationship while preserving its earlier assignment. A snapshot-only owner becomes stale after that transfer unless another process updates it.
• Challenge the deduplication rule. Include one CVE reported by two scanners and one source-specific finding. After normalization, the analyst still needs access to both native IDs, independent statuses, and observation times. Pass only if the records can be separated or reconciled without deleting the source trail.
• Exercise the whole ticket loop. Create a work item in Jira, ServiceNow, or the chosen destination. Reassign it, change its due date, resolve the underlying finding, and then reopen it. Record which system owns each status transition. An integration that only sends new findings is notification plumbing, regardless of how the slide labels it.
• Reconcile one KPI by hand. Choose scan coverage or SLA attainment and reproduce it from the sample export. Require the denominator, exclusions, filters, source records, and refresh time. A dashboard total that cannot be traced back to records is presentation output, not defensible program reporting.

Score each test from 0 to 2. Award 2 when it works in the configured proof of concept. Give 1 when it needs custom code or a manual export, and 0 when the vendor cannot demonstrate it. A zero in provenance, asset linkage, or closure authority is a disqualifier. Dashboard polish should not average it away.

Decide which buying job matters. Some threat and vulnerability management solutions replace inadequate detection coverage. Others coordinate prioritization, ownership, tickets, and evidence above scanners that already work. If coverage is already adequate, another scanner adds observations without repairing the handoff.

Need named products? The cloud security tools comparison covers vulnerability management, CNAPP, CSPM, and runtime security.

Threat and vulnerability management software: how to choose

A TVM platform fits only when it preserves the evidence chain from finding to verified closure inside your existing stack. Category labels are unreliable: threat and vulnerability management tools may be scanners, prioritization engines, exposure-management platforms, or workflow layers.

Use an anonymized sample from one production service for the proof of concept, not the vendor's prepared data. Include records from each in-scope scanner, current asset relationships, one real ownership transfer, exceptions, and matching ITSM tickets. Remove hostnames, IP addresses, cloud account IDs, and user details before sharing it.

Run that same sample through five acceptance tests:

• Make the threat signal explain itself. Open one prioritized finding and identify the source, observation date, and refresh state behind its exploitation signal. Missing EPSS, CISA Known Exploited Vulnerabilities (KEV), or campaign data should remain visible. A risk badge without provenance fails.
• Test the day-60 ownership state. Change the application's responsible team or replay a real transfer. The open finding should resolve to the maintained relationship while retaining its earlier assignment. A copied owner field becomes stale unless another process updates it.
• Challenge the deduplication rule. Submit one CVE reported by two scanners plus one source-specific finding. After normalization, the analyst should still reach both native IDs, independent statuses, and observation times. Merging away the source trail is a failure.
• Exercise the whole ticket loop. Create a work item in Jira, ServiceNow, or the chosen destination; reassign it, change its due date, resolve the finding, and reopen it. Record which system owns every transition. One-way ticket creation is notification plumbing, not workflow integration.
• Reconcile one KPI by hand. Reproduce scan coverage or SLA attainment from the sample export, including its denominator, exclusions, filters, source records, and refresh time. A total that cannot be traced to records is not defensible program reporting.

Score each test from 0 to 2. Award 2 when it works in the configured proof of concept. Give 1 when it needs custom code or a manual export, and 0 when the vendor cannot demonstrate it. A zero in provenance, asset linkage, or closure authority is a disqualifier. Dashboard polish should not average it away.

Here is an illustrative result from that rubric. The candidates are examples, not scores for named products:

Acceptance test	Candidate A: new scanner	Candidate B: context and workflow layer	Candidate C: reporting aggregator
Threat-signal provenance	2	2	1
Asset linkage after an ownership change	1	2	1
Existing-scanner ingestion	0	2	2
Ticket loop and closure authority	1	1	0
KPI traceability	1	2	2
Total	5/10	9/10	6/10
Hard-gate failure?	No	No	Yes
Decision if current scanners stay	Reject	Proceed; price the ticket work	Reject

Candidate B wins when the current scanners are staying. It preserves their evidence, resolves findings against maintained asset relationships, and makes reporting reproducible. Its 1 for ticket handling also exposes custom work that belongs in the implementation estimate.

Candidate C loses despite outscoring Candidate A because it cannot demonstrate closure authority. Candidate A serves a different buying job: its ingestion gap is acceptable only if you intend to replace the current scanners and separately prove equivalent coverage, authenticated assessment, and refresh cadence.

Choose by buying job first, hard gates second, and total score third. Otherwise, threat and vulnerability management solutions with different operating models appear falsely interchangeable.

Need named products? The cloud security tools comparison covers vulnerability management, CNAPP, CSPM, and runtime security.