If your queue looks like an endless scroll of “Critical” CVEs, you’re not alone. In 2026, the hard part isn’t finding vulnerabilities, it’s choosing what to fix first with 1 to 5 people and a hundred other priorities.
The mistake many small teams make is treating CVE triage like a CVSS sorting task. CVSS is useful, but it’s not a work plan. It tells you how bad something could be, not how likely it is to hurt you this week.
This post gives you a repeatable triage method that treats CVSS as one input, alongside exploitation signals, exposure, asset value, and the controls you already have.
CVSS is a severity score, not your priority list
CVSS measures technical impact in a mostly vendor and researcher friendly way. That helps standardize discussions, but it doesn’t answer your daily questions, like “Is anyone exploiting this?” and “Is it reachable in our environment?”
To keep decisions grounded, use CVSS as a component, then add these risk signals:
- EPSS (likelihood): The Exploit Prediction Scoring System (EPSS) estimates the probability a CVE will be exploited in the wild. It’s a helpful counterweight to severity.
- CISA KEV (proof): The CISA Known Exploited Vulnerabilities catalog is the closest thing most small teams have to “confirmed exploitation intel” without building a threat intel program.
- SSVC (decision framing): CISA’s SSVC pushes you to decide based on exploitation, impact, and context, not just a number.
- NVD (canonical data): When you need references, affected products, and scoring details, check the NIST National Vulnerability Database.
A simple way to think about it: CVSS is the “how much damage if it hits” estimate. EPSS and KEV help answer “how likely is it to hit soon.” Your environment answers “can it hit us at all.”
If you want a clear explainer on why severity-only ranking burns time, this CVSS vs EPSS comparison captures the gap in plain terms.
A small-team CVE triage playbook you can run every day
This playbook assumes you have a scanner (or at least vendor alerts), a ticketing tool, and basic asset inventory. Keep it tight. The goal is consistent decisions, not perfect ones.
- Collect new candidates (daily): Pull new scanner findings, vendor advisories, and “top exploited” items from KEV. De-dup by CVE and affected asset.
- Enrich each CVE (5 minutes): Record CVSS, EPSS, KEV status, and any “known exploitation” notes (vendor advisory, exploit modules, incident reports).
- Confirm exposure (fast): Is the vulnerable service internet-facing, partner-facing, internal, or not reachable? If you can’t prove reachability, assume “internal” until you verify.
- Assign asset criticality: Tie the finding to what the system does (identity, payments, EHR, ERP, backups, endpoint fleet, dev tooling).
- Account for compensating controls: WAF rules, VPN-only access, EDR hardening, segmentation, patch management controls, disabled feature, removed package.
- Score, then assign a stoplight: Use a 0 to 3 scale per factor, then generate Red, Yellow, or Green. Push Reds straight into remediation with a due date.
Below is a scoring table designed for small teams. It won’t be perfect, but it will be repeatable.
| Factor (0–3) | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| CISA KEV | Not in KEV | In KEV | ||
| Known exploitation (non-KEV) | None seen | PoC only | Credible reports | Exploit observed in your logs/incidents |
| EPSS | < 0.10 | 0.10–0.29 | 0.30–0.59 | ≥ 0.60 |
| Exposure | Not reachable | Internal only | Partner-facing or broad internal | Internet-facing |
| Asset criticality | Low | Medium | High | Mission-critical (identity, core revenue, safety) |
| Compensating controls (reduces risk) | Strong controls | Some controls | Weak controls | None |
| CVSS (as one input) | < 4.0 | 4.0–6.9 | 7.0–8.9 | 9.0–10.0 |
Scoring note: for compensating controls, treat the number as a penalty you subtract (0 is best, 3 is worst), or keep the table as written and add it normally. If you add it normally, rename it “Control gaps.”
Stoplight output (quick rules):
- Red (act now): KEV = 3, or exploitation observed = 3, or total score ≥ 12.
- Yellow (schedule): total 8–11.
- Green (watch or accept): total ≤ 7, and not KEV, and not internet-facing.
If it’s in KEV and reachable, treat it like a smoking alarm, not a backlog item.
Handling noisy high-CVSS and sneaky exploited low-CVSS
This is where teams waste the most time: high CVSS items that look scary on paper, and lower CVSS items that attackers actually use.
“Noisy high-CVSS” cases (don’t auto-panic)
High CVSS often means big theoretical impact, like RCE. However, real risk drops fast when the flaw isn’t reachable, needs rare conditions, or sits behind controls.
Use this fast filter:
- If it’s not reachable (feature not enabled, package not installed, port closed), it can’t hurt you today.
- If it’s internal-only and you have strong segmentation plus EDR coverage, it often belongs in Yellow, not Red.
- If patching will break production, consider a short exception, but require a compensating control (rule, config change, or isolation) with an expiry date.
Your aim isn’t to “ignore Critical.” It’s to stop letting a label override context.
“Low-CVSS but exploited” cases (treat as urgent)
Attackers don’t care if a bug is a 5.6. They care if it’s easy, reachable, and common. Many footholds come from edge devices, auth bypass quirks, exposed admin panels, and misconfig chains.
When you see KEV listing, credible exploitation reports, or exploitation telemetry in your environment, bump priority even if CVSS is modest. In the scoring model above, KEV, exploitation, and exposure should pull it into Red.
If you want extra help aligning EPSS with KEV-style urgency, this EPSS and KEV analysis write-up is a good reference point: EPSS and CISA KEV guidance.
Templates that make triage repeatable: worksheet, ticket fields, and SLAs
Consistency is the whole win. The templates below reduce “it depends” debates and help you rotate on-call duties.
Triage worksheet (one CVE, many assets)
Keep one worksheet row per CVE, then list affected assets beneath it.
- CVE ID, product, version range
- CVSS score/vector, plus NVD link
- EPSS score and date
- KEV status (yes/no) and date added (if known)
- Exploitation notes (source, link, internal detections)
- Affected assets list (hostname, owner, environment)
- Exposure rating (internet, partner, internal, unknown)
- Asset criticality
- Compensating controls (current and proposed)
- Score total and stoplight
- Decision (patch, mitigate, accept, false positive)
- Due date and assignee
Ticket fields to capture (so work doesn’t vanish in chat)
Use these fields in Jira, ServiceNow, or even a shared inbox:
- Stoplight (Red, Yellow, Green)
- SLA due date
- Change window needed (yes/no)
- Mitigation option (config change, rule, isolate, patch)
- Validation method (rescan, package check, exploit test, log query)
- Exception expiry (date) and approver
Example SLAs small teams can meet
This table maps to common reality: limited hands, limited windows, but clear deadlines.
| Condition | Stoplight | SLA target |
|---|---|---|
| KEV + internet-facing | Red | 48 hours |
| KEV + internal-only | Red | 7 days |
| EPSS ≥ 0.60 + high criticality | Red | 7 days |
| CVSS ≥ 9.0, not KEV, internal-only | Yellow | 30 days |
| Low exposure + strong controls | Green | 90 days or accept with expiry |
Track a few metrics, then review them on a fixed rhythm:
- MTTR by stoplight bucket
- Percent of KEV remediated within SLA
- Backlog age by bucket (oldest Red, oldest Yellow)
- Exceptions past expiry
Cadence that works for 1 to 5 people: 15 minutes daily for intake and scoring, then 45 minutes weekly to burn down Reds, revisit exceptions, and close stale tickets.
Conclusion
CVE triage gets easier when you stop treating CVSS as a verdict. Use it as a signal, then let EPSS, KEV, exposure, and asset value drive the work. Once your team runs the same scoring and stoplight rules every day, the backlog stops feeling personal.
Start small: score today’s top 20 findings, assign stoplights, and commit to the SLAs for Red items. What would change in your patch outcomes after two weeks of that cadence?
