
- Do not sort the patch queue by CVSS base score alone.
- Move a matching CISA Known Exploited Vulnerability near the front, then check whether the affected product and version are really in use.
- Use SSVC and local asset context to choose an action, owner and deadline.
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.
| Signal | Question | Queue effect |
|---|---|---|
| CVSS vector | How can the flaw be reached, and what can happen? | Sets technical severity and test scope |
| CISA KEV | Is exploitation in the wild confirmed? | Raises urgency when your product is affected |
| SSVC | What response does the decision path support? | Creates a repeatable action category |
| Asset context | Is 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
- Export open findings. Keep the CVE ID, product, version, CVSS vector, detection source and asset name.
- Match KEV. Flag exact CVE matches from CISA's current JSON or CSV feed. Record the catalog date.
- Confirm affected software. Read the vendor advisory and compare the installed version. Remove false product matches.
- Add asset facts. Mark internet exposure, privilege level, data sensitivity, business role and any compensating control.
- 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 →