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.
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.
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 |
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.
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.)
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.
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.
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 or book a demo.
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.
Sources: exploitation probability per FIRST EPSS; confirmed exploitation per CISA KEV; severity per NVD; scan statistics from Autter's own codebase scans.
Keep reading: Securing Your CI/CD Pipeline Against AI-Introduced Vulnerabilities · Catching AI-Generated Code Before It Ships
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)