It was a Thursday afternoon. I had spent years in vulnerability management and I was tired of the same pattern playing out everywhere I looked: hundreds of findings, patch teams with capacity for maybe thirty of them, and CVSS-ranked spreadsheets telling everyone to go chase every 9.8 and 10.0 first.
The pattern I kept seeing across the industry was always the same. CVEs sitting at 6.5, quietly deprioritized. Medium severity. Not urgent. Teams move on. Except when you pull the full data, some of those have EPSS scores above 0.90. Ninety-plus percent probability of real-world exploitation within the next thirty days. Some are sitting in the CISA KEV catalog. Someone, somewhere, is already using them. Most teams just aren't looking at those numbers.
That Thursday afternoon, I opened my terminal. By Sunday I had a working prototype.
The Thursday It Started
I had been doing vulnerability management long enough to know the dirty secret: the tools aren't really designed to help you make good decisions. They're designed to surface data. What you do with that data, that's still on you, and the gap between "here are your CVEs ranked by CVSS" and "here's what you should actually patch first" is where breaches live.
I had been using enterprise vulnerability management tools over the years. Expensive licensing, all the features, well-supported platforms. And the AI capabilities being added felt bolted-on. Summaries. Descriptions. Not the core thing anyone actually needs, which is: given my specific environment, given what threat actors are actually doing right now, what do I patch this sprint?
I thought: I could build something that actually answers that question. A weekend project. No pitch deck, no investors, just a problem I wanted solved.
So I sat down and started. Bun for the backend because it's fast and sane. SQLite for local persistence. The NIST NVD API and Google OSV for CVE data. EPSS feeds from FIRST. CISA KEV as a live signal. And an AI layer that could take all of those inputs and generate an actual remediation runbook, not a summary, a runbook.
By Sunday night I had something that I knew practitioners everywhere would actually want.
The Tool I Wished Existed
Here's what I kept running into in every security role I've had: the vulnerability management problem is not really a technology problem. The data exists. EPSS is public and free. The KEV catalog is public and free. NVD is public and free. The signals that would let you make dramatically better prioritization decisions are all out there.
The problem is integration. The problem is that nobody had built a tool that pulled those signals together, applied them to your specific organizational context, and then generated actionable output. Not a score. Not a color. An actual runbook you could hand to a sysadmin and say: here's what to do, here's how to verify it worked, here's what breaks if you apply this patch.
The vulnerability management problem isn't hard because of the technology. It's hard because the industry sold everyone on CVSS as a prioritization tool when it was never designed for that.
CVSS was designed to score theoretical severity in isolation. That's a legitimate and useful thing. It was never designed to tell you what to patch first in your environment, this quarter, given current threat actor behavior. Using it as a prioritization tool is like using a weather forecast from a different country to decide whether to bring an umbrella today.
What We Built
CVEasy AI does a few things that I think matter:
- Composite risk scoring. Every CVE gets an TRIS™ score that combines CVSS base severity, EPSS exploitation probability, CISA KEV status, ransomware campaign signals, and your specific organizational context. Industry matters. Compliance obligations matter. Asset criticality matters. The score reflects that.
- AI remediation that generates runbooks. Not a summary of the CVE. An actual step-by-step remediation guide tailored to your environment. Patch commands, verification steps, rollback procedures, the specific packages affected. Something you can act on.
- Triage that surfaces the right ten, not the wrong hundred. The goal is never to show you everything. It's to show you the ten things that represent real, active, material risk to your organization right now. Everything else can wait.
- Local-first architecture. Your CVE data, your asset context, your remediation history stays on your machine or your infrastructure. It doesn't go to a cloud service. It doesn't train anyone's model. It doesn't leave.
Why Local-First Matters
This one matters more than people realize, and I want to be direct about why I made this call.
When you run vulnerability scans and feed results into a cloud-based tool, you are sending a remarkably detailed map of your weaknesses to someone else's infrastructure. Every CVE you ingest, every asset you tag, every remediation you defer, that's a picture of exactly where you're vulnerable and what you haven't fixed yet. In the wrong hands, that's an attack roadmap.
I'm not saying every cloud security tool is a liability. I'm saying that the threat model for security tooling itself is something most organizations never audit. You scrutinize your code dependencies. You scrutinize your vendors. But the tool that knows your full vulnerability landscape? That one often gets a pass.
CVEasy AI runs on your hardware. The database lives on your machine or your private server. The AI models run locally through Ollama with no external calls. You get the intelligence layer without the data exposure. That was a design principle from day one, not a feature we added later.
The enterprise version works the same way. You can self-host it completely. If you want to run it on a machine that has no outbound internet access, you can do that. Your vulnerability intelligence stays inside your perimeter.
The Bottom Line
I'm not trying to build a unicorn. I'm not raising a Series A. I built a tool I wished existed when I was doing this work every day, and I'm making it available because I suspect I'm not the only one who's been burned by the CVSS trap.
If one security team avoids a breach because they patched the right thing first, if one analyst goes home on Friday not having chased a dozen theoretical 9.8s that nobody was exploiting while a real active threat sat at 6.5 in their queue, then the Thursday afternoon was worth it.
The signals to make better decisions already exist. They've been public and free for years. Someone just needed to put them together in a tool that actually works.
That's what CVEasy AI is. A tool built by a practitioner, for practitioners. No corporate speak. No enterprise theater. Just the thing that should have existed already.