---
title: How to Prioritize Vulnerabilities: CVSS, EPSS, KEV, and Reachability - Autter Blog
description: How to prioritize vulnerabilities: use CVSS for severity, EPSS for likelihood, KEV for proof, and reachability for reality. Then stop patching in alphabetical order.
url: https://autter.dev/blog/how-to-prioritize-vulnerabilities
date: 2026-10-09
author: Tanvi
tags: Security, Code Review, Merge Gate
reading_time: 8 min
site: Autter - Autter is your AI teammate for code review and testing: it reviews code, tests product impact, checks security, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Oct 9, 2026

# How to Prioritize Vulnerabilities: CVSS, EPSS, KEV, and Reachability

How to prioritize vulnerabilities: use CVSS for severity, EPSS for likelihood, KEV for proof, and reachability for reality. Then stop patching in alphabetical order.

Tanvi, Founder, autter.dev 8 min read

- Security
- Code Review
- Merge Gate

One startup we scanned had a critical remote-code-execution flaw in a serialization library. It had been in their dependency tree for four months. It arrived when they upgraded a completely unrelated package.

CI was green the whole time. CI runs the tests you wrote, and nobody had written one called *please don't let strangers run code on our server.*

They weren't careless. They were busy. And a list of 400 "criticals" is not a plan. It's a to-do list written by someone who has never met your sprint.

The short answer

Combine three signals. CVSS tells you how severe a flaw is in theory. EPSS tells you how likely it is to be exploited. CISA's KEV catalog tells you it already has been. Then add the one signal no public feed can give you: whether the vulnerable code is actually reachable in *your* codebase. Patch anything in KEV first, then high-EPSS criticals, then everything else on a schedule. Stop treating a raw CVSS score as your roadmap.

Tens of thousands of CVEs are published every year. You cannot fix them all. Prioritization isn't a nice-to-have. It's the whole job.

## What's the difference between CVSS, EPSS, and KEV?

Picture every vulnerability as a vessel requesting entry to your harbour. Capt. Patch has four questions before anyone clears the gate.

| Signal | The question it answers | Source | What it can't tell you |
| --- | --- | --- | --- |
| **CVSS** | How big is the cannon? (severity, 0.0 to 10.0) | FIRST / NVD | Whether anyone will fire it, or whether it's pointed at you |
| **EPSS** | How likely is someone to fire it? (probability of exploitation, plus a percentile, updated daily) | FIRST, free | Anything about your environment |
| **CISA KEV** | Has it already been fired at someone? | CISA | What hasn't been caught yet. It's a floor, not a ceiling |
| **Reachability** | Is the cannon pointed at *your* harbour? | Your own codebase | Nothing. It just needs your repo |

![A nautical chalkboard compares CVSS severity, EPSS likelihood, KEV confirmed exploitation, and reachability in your codebase, with exposure and blast radius added as context.](https://autter.dev/blog/vulnerability-prioritization-signals-v1.webp)

*Four signals answer four different questions. Your repository supplies the context.*

Everyone has CVSS. Fewer teams use EPSS. Almost nobody does reachability, because it requires reading your code, which is the one thing a CVE feed can't do.

## How do you actually prioritize vulnerabilities?

Four lanes. Work them top to bottom.

**1. Already in the harbour (it's in KEV).** Drop everything. Exploitation is confirmed, so the score is decoration. A 5.4 in KEV outranks a 9.8 that exists only in theory. KEV entries come with remediation due dates for a reason.

**2. Pirates on the horizon (high EPSS + high CVSS).** You're next. No KEV listing yet doesn't mean no raid. It means nobody's filed the paperwork.

**3. Big cannon, no pirates (high CVSS, low EPSS).** Schedule it. Normal cadence. But EPSS refreshes daily, so a low score today is not a pardon.

**4. Rowboats (low CVSS, low EPSS).** Batch into routine maintenance. Do not convene a war room for a rowboat.

Then apply the part no feed knows: **blast radius.** Is it reachable? Is it internet-facing? Does it touch auth, billing, or user data? Is there a compensating control? A medium on your public API can outrank a critical in an internal script nobody has opened since 2023.

![Four chalkboard priority lanes: fix KEV first, prioritize high EPSS with high CVSS next, schedule high CVSS with low EPSS, and batch low scores into routine maintenance. Adjust each lane for reachability, exposure, and blast radius.](https://autter.dev/blog/vulnerability-prioritization-lanes-v1.webp)

*Work the lanes in order, then apply the reality of your own codebase.*

## What does this look like on a real afternoon?

Three findings. One engineer. Slightly unreasonable expectations.

| Finding | CVSS | EPSS | In KEV? | Reachable? | Where it lives | Verdict |
| --- | --- | --- | --- | --- | --- | --- |
| A | 9.8 | Low | No | No, vulnerable function never called | Transitive dep in a build tool | Schedule it. Keep your weekend. |
| B | 6.5 | Medium | **Yes** | **Yes** | Public API | Fix today. |
| C | 8.1 | High | No | Yes | Internal admin panel | This week. |

Rank by CVSS alone and you fix A, C, B. Rank by evidence and you fix B, C, A. Raw CVSS gets you the exact wrong order, delivered with great confidence, which is the most dangerous kind.

*(Illustrative numbers, not a real incident. The ordering logic is the point.)*

![A chalkboard shows CVSS-only ordering A, C, B beside evidence-based ordering B, C, A. Finding B is exploited and reachable despite its lower 6.5 score. The findings are illustrative.](https://autter.dev/blog/vulnerability-prioritization-order-v1.webp)

*Same findings. Different priorities. Evidence moves the exploited public API ahead of the unreachable build dependency.*

## Why is timing the part everyone ignores?

Because nobody's job description includes **"notice on day one."**

When we scanned 10 startup codebases, 8 had a dependency with a known critical CVE. The average CVE had been public for **94 days**. The average number of PRs merged in that window: **38**. That's 38 chances to notice. Nobody did, because at merge time, noticing wasn't anyone's job.

A ranking refreshed once a quarter is not a ranking. It's a historical document. [Full scan findings here.](https://autter.dev/blog/we-scanned-10-startup-codebases)

## What do CVSS, EPSS, and KEV not catch?

Everything without a CVE number. Which is, inconveniently, a lot of your own code.

In that same scan, a Copilot-generated API handler validated the request body perfectly. It never validated *who was sending it.* Any authenticated user could trigger a job scoped to another user's data. No CVE. No CVSS. No EPSS. No KEV. Invisible to every scoring system in this post.

The same goes for the live Stripe key that was rotated but never removed from the repo (6 of 10 codebases had a secret that had touched a production branch), and the migration that would've failed against 180,000 rows in production but sailed through an empty staging database.

Scores rank known flaws in other people's code. The expensive ones are increasingly in yours, especially when AI is writing a share of it.

## Where does Autter fit?

Honest version: a scoring framework tells you what to fix. It doesn't stop the next bad change from landing.

**Codebase scans** run on demand, on a schedule, after a default-branch push, or at a release tag. They combine focused security agents with established tooling across code, dependencies, containers, infrastructure, APIs, and secrets. The report is deduplicated and ranked by reachability, exploit evidence, severity, and repository context, with a CycloneDX SBOM attached. So you get a queue, not a pile.

**The merge gate** handles the rest. Every PR executes in an isolated sandbox against your base branch. Dependencies are vetted against real registries. Secrets and CVEs get caught at the gate. The merge stays blocked until the checklist clears.

> “A CVSS score is a comment. A merge gate is enforcement.”

That's the whole bet. Comments get scrolled past at 4:47pm on a Friday. [We wrote a whole post about it.](https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment)

What Autter doesn't do: replace your CI (it sits on top of it) or replace your humans (it clears the repetitive stuff so they can argue about architecture instead). You still decide what risk is acceptable.

**Want to see it first?** Run it on one of our demo repos with planted findings, or connect your own. The Harbour plan is free (10 PR reviews a month on one repository), public repos are free, and your code never trains a model. [Start now](https://app.autter.dev/login) or [book a demo](https://autter.dev/contact).

## Frequently asked questions

### Should I patch every critical CVSS first?

No. Patch KEV first regardless of score, then use EPSS and reachability to rank the rest. "Patch all criticals" floods the team and still misses exploited mid-scored bugs.

### Is EPSS free?

Yes. FIRST publishes EPSS scores openly, updated daily, for the full CVE set.

### Does low EPSS mean I can ignore it?

No. It's a probability, not a promise. It tells you where to look later, not that you never have to.

### What if a vulnerability has no CVSS score yet?

Don't wait for NVD. Some actively exploited flaws hit KEV before they're scored. KEV membership is a priority signal on its own.

### What about vulnerabilities in my own code?

They have no CVE, so none of these scores apply. That's what reviewing the change itself is for: running it, testing it, and blocking the merge if it fails.

## Our read

Prioritization is where vulnerability management is won or lost, and the data to do it well is free. Rank by evidence. Then make sure the next bad change can't walk in while you're busy ranking.

The startup with the four-month-old RCE didn't need a smarter list. It needed something standing at the gate the day that dependency arrived.

Capt. Patch has been standing there since. [Hire Autter for a peaceful weekend.](https://app.autter.dev/login)

*Sources: exploitation probability per [FIRST EPSS](https://www.first.org/epss/); confirmed exploitation per [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog); severity per [NVD](https://nvd.nist.gov/vuln-metrics/cvss); scan statistics from [Autter's own codebase scans](https://autter.dev/blog/we-scanned-10-startup-codebases).*

**Keep reading:** [Securing Your CI/CD Pipeline Against AI-Introduced Vulnerabilities](https://autter.dev/blog/automated-pipeline-security) · [Catching AI-Generated Code Before It Ships](https://autter.dev/blog/ai-generated-code-review)

## P.S.

**Sagnik:** What if we build our own EPSS? Autter Probability Scoring System. APSS.

**Tanvi:** FIRST already publishes EPSS. Free. Daily. For every CVE.

**Sagnik:** Ours would have a mascot.

**Tanvi:** Ours would also have a maintenance burden.

**Sagnik:** *(has already drawn the logo)*

*(currently: the logo is ready, the roadmap is not)*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Oct 5, 2026 · 9 min read Claude Code, Cursor, Codex: Fast Hands, Zero Fear of Consequences The real security risks of Claude Code, Cursor, and Codex: insecure code, leaked secrets, bad packages, and prompt injection. And why a merge gate beats a polite suggestion.](https://autter.dev/blog/ai-coding-assistant-security-risks)