TechWeb Magazine illustration showing a noisy vulnerability alert pile moving through a shield checkpoint into three ordered response queues
A public severity score is one input. Evidence of exploitation, asset exposure and business impact decide what moves first.

A scanner finds two hundred flaws. The dashboard puts the largest CVSS number at the top. That looks objective, yet it can send the team toward a severe lab condition while an actively exploited flaw sits lower down.

Use three layers instead. CVSS describes technical severity. CISA's Known Exploited Vulnerabilities catalog adds evidence of attacks in the wild. SSVC adds a decision path that considers exploitation, impact and the role of the affected system.

CVSS answers a useful, narrower question

CVSS is not useless. Its Base metrics describe how a flaw can be exploited and what damage a successful attack may cause. They are meant to stay consistent across organizations.

Your environment is different. A public CVSS Base score may not know that one server faces the internet, another is isolated, and a third runs the system that pays staff. CVSS version 4 includes Threat and Environmental metric groups for that context, but public providers often publish only the Base score.

Read the vector, not just the number. Network reach, required privileges and user action can change the first response. Then add facts the public score cannot know.

KEV adds evidence that attackers are using the flaw

CISA calls its KEV catalog the authoritative source for vulnerabilities known to be exploited in the wild. It tells organizations to use the catalog as an input to prioritization.

That wording matters. A KEV match is a strong signal, not proof that every device in your inventory is exposed. Confirm the vendor, product, affected version and deployment path. A scanner name match is not enough.

Also separate guidance from obligation. Binding Operational Directive 22-01 sets remediation due dates for U.S. Federal Civilian Executive Branch agencies. Other organizations can use KEV as a priority signal, but those federal deadlines do not automatically become their legal deadlines.

SSVC turns the same facts into an action

Stakeholder-Specific Vulnerability Categorization is a decision tree. CISA uses four outcomes: Track, Track*, Attend and Act. The path considers exploitation status, technical impact, whether the product is common, and effects on safety or mission functions.

In June 2026, NIST added CISA SSVC data to NVD feeds and APIs beside CVSS. NVD now exposes a computed SSVC result and the affected-software list when that data is present. This is useful for automation, but the local asset decision still belongs to you.

SignalQuestionQueue effect
CVSS vectorHow can the flaw be reached, and what can happen?Sets technical severity and test scope
CISA KEVIs exploitation in the wild confirmed?Raises urgency when your product is affected
SSVCWhat response does the decision path support?Creates a repeatable action category
Asset contextIs the system exposed, important and reachable?Sets the owner, deadline and safe change plan

A small example shows why the order can change

Take two flaws. Flaw A has a Base score of 9.8. It sits on a lab tool with no path from the web.

Flaw B scores 7.5, appears in KEV, and runs on a public VPN that staff need to sign in. Flaw B moves first.

The team checks the vendor fix, saves the current setup, sets a change time, and watches logs after the patch. Flaw A stays in the queue with an owner and due date.

This is an example, not a rule that all KEV items beat all other work. A flaw that can stop a plant or harm a person may still need the top slot even before KEV lists it.

Build the first queue in thirty minutes

  1. Export open findings. Keep the CVE ID, product, version, CVSS vector, detection source and asset name.
  2. Match KEV. Flag exact CVE matches from CISA's current JSON or CSV feed. Record the catalog date.
  3. Confirm affected software. Read the vendor advisory and compare the installed version. Remove false product matches.
  4. Add asset facts. Mark internet exposure, privilege level, data sensitivity, business role and any compensating control.
  5. Choose an outcome. Use SSVC as a shared decision path. Assign an owner, deadline and reason.

Start small. One internet-facing service is enough for the first pass. The aim is not a perfect scoring formula. It is a queue the security team and system owner can explain together.

Do not let automation erase the caveats

A patch may not exist. The vendor may list a workaround, a configuration change or a product replacement instead. Write the chosen mitigation beside the finding and set a review date.

Availability matters too. Emergency patching can break a critical service. Use a tested rollback plan, yet do not turn change risk into an open-ended exception. The restore-test guide and emergency admin drill cover two controls worth checking before a high-risk change.

Inventory quality is the quiet dependency. If owners cannot tell which version is running, triage stalls. Build lifecycle ownership with the software support calendar, and ask suppliers for evidence using the SBOM review workflow.

A short decision record prevents repeat debates

For each urgent finding, save six fields: affected asset, evidence of exposure, KEV status, SSVC outcome, chosen treatment and accountable owner. Add the date and the source links.

Keep exceptions visible. If a flaw is accepted for now, name the control that reduces risk and the event that ends the exception. “Low priority” is not a reason.

Frequently asked questions

Should every critical CVSS score be patched first?

No. A critical score deserves review, but exploitation, exposure, asset importance and available controls can change the order. Record why a lower-scored item moves ahead.

Does a KEV entry prove my system was attacked?

No. It means CISA has evidence that the vulnerability has been exploited in the wild. Your logs and incident process must answer whether your asset was targeted or compromised.

Can SSVC replace a risk register?

No. It supports a vulnerability-response decision. Broader business risk, dependencies and accepted exceptions still need normal governance.

What if the vendor has no patch?

Use the vendor's supported mitigation when available. Limit exposure, add monitoring, isolate or replace the product, assign an owner, and set a dated review.

Sources

CISA: Known Exploited Vulnerabilities Catalog · CISA: Stakeholder-Specific Vulnerability Categorization · NIST: National Vulnerability Database updates · FIRST: CVSS v4.0 specification. Product state and threat evidence change; verify the live advisory and catalog before acting.

More in this sectionTechnology →