How I Stumbled Into OWASP CVE Lite

It started in 1991. My father handed me a TRS-80 and a stack of books, mostly GW-BASIC, a few games. I was fifteen. I don’t remember deciding to become someone who builds things with computers. I just started, and I never really stopped. By the time I graduated high school at sixteen I already had two college credits to show for it.

But the part that actually shaped me came later. Late nineties, I was a broke DJ, and I picked up web design for exactly one reason: to promote myself. I needed a site, I couldn’t pay anyone to build it, so I built it. That is my whole life with computers in one sentence. I needed a thing, nobody was going to hand it to me, so I made it.

That one site snowballed. Web design turned into graphic design, then a Certified Professional Webmaster, then all things Linux, then a web hosting company, and on from there into a career keeping mission-critical systems alive, the kind where an outage is measured in money and in people who can’t do their jobs.

So I still don’t call myself a developer. I’m an operator. The line from that TRS-80 to now never moved. I don’t write code for the craft of it. I write it to stop something from bleeding.

This isn’t a story about a brilliant tool I dreamed up. It’s a story about a problem that would not die, and the open-source project I stumbled into while trying to kill it.

Here is the honest version of what I am good at. I am not always the person who comes up with the solution. I am the person who finds the gap. I can walk into a mess, see what is missing, and scope it out, fairly consistently. The clever fix sometimes belongs to someone sharper than me. Spotting the need and framing it, that part I can do.

And that is exactly how this happened. I wasn’t setting out to contribute to anything. I was building HexOps, an open-source security tool, and somewhere in the middle of it I ran into a dependency problem I could not shake. Next.js had exact-pinned a transitive dependency to a version with a known CVE, and the only clean fix was a hand-written override buried in package.json. If you have never had to do that, count yourself lucky. If you have, you know the feeling. You patch the thing, you move on, and six months later you cannot remember which of your overrides are still load-bearing and which are quietly rotting. The postcss one would not stay dead.

I went looking for something that would just tell me the right way to fix it. That is how I found CVE Lite.

I started playing with it, and it kept solving problems I was already trying to solve, except cleaner than my version. It told me the vulnerable package, where it came in, the right shape of the fix, a floor pin instead of an exact pin, and it validated the safe version before it ever suggested it. I was genuinely impressed. Sonu Kapoor had built something good, and I slowly started folding it into HexOps.

So I reached out to him. Not for anything. Just to tell him he’d done good work. I believe in that. If you put good things into the universe, it costs you nothing to let the person know they are doing good things. Pay it forward where you can.

He asked if I’d write him a testimonial. I said sure. And then, in true Aaron form, I wrote an entire blog post about it.

What I did not know at the time was that the post would get quoted in a CSO Online editorial about CVE Lite. A simple thank-you turned into press for a project I had no hand in creating. I was glad to give it.

The more I used CVE Lite, the more I saw the gap sitting right next to it. That is the thing I am good at, so it found me.

CVE Lite does the hard part. It reads your lockfile, finds the vulnerable package, and tells you the right way to fix it. For an override, that means it hands you the correct override to write. If every developer wrote it exactly that way and never touched it again, my problem would mostly disappear.

But even with CVE Lite doing its job, I still had the override problem. Not the “what do I write” problem, CVE Lite solved that. The “what happens to this override over time” problem. Overrides cause more issues than they solve if you do not manage them, and managing them properly costs real time. That time is maintenance debt and security risk wearing the costume of a fix.

And this is one of those problems where both of the obvious answers are too expensive. Hand-editing override files does not scale, you will not do it on every audit, nobody does. Pointing an AI agent at them does not scale either, it is slow, it costs money every run, and you do not want a probabilistic model making deterministic security decisions inside your lockfile. This was a problem that wanted a deterministic tool. Not a human babysitter, and not an AI one.

So I followed Sonu’s lead. I went back to the override problem and dug in hard, programmatically, borrowing from the exceptional work he had already done on CVE Lite. I figured what I was building would be a sibling to it. Same philosophy, different artifact. CVE Lite tells you how to write the override. This would watch the override after you wrote it.

That became override-audit-cli, an auditor for the override file itself. The scanner stays a scanner. The auditor stays an auditor. Run both, and the most neglected file in your dependency stack finally has something watching it.

I built it as a sibling. But the more Sonu and I talked, the clearer it got that the work belonged in the same place. So we merged it. The detectors, the fix flow, the change-control logging, all of it went through review, passed CI, and landed inside OWASP CVE Lite. override-audit-cli stopped being my tool. It became part of the project.

That is the right ending for it. The gap I found is now closed inside a tool any developer can reach, not a repo with only my name on it.

What I built merged into CVE Lite as a new piece: override hygiene. And the part I care about is that it does more than point at the problem. Pointing at problems is easy. Closing them is the work.

You run it against a project, across npm, pnpm, Yarn, or Bun, and it reads your override file the way CVE Lite reads your lockfile, as something with a lifecycle, not as opaque config nothing watches. It knows the ways an override rots. The ones aimed at a package you dropped a year ago. The ones pinned to a version that was safe then and is the vulnerable one now. The ones nested or misfiled so they look like they are working and quietly are not. The ones where the vulnerable copy is still sitting on disk even though your override said it was handled.

Then it fixes them. Not by handing you a warning and a homework assignment. It writes the correct change itself, as a precise patch, and applies it. The override pattern that took me a year of operator time to learn, pull the pin that is fighting the parent, add a floor pin the right way so the next patch release does not turn your fix into the new vulnerability, now writes itself. And it does not make that change in silence. It explains it. It tells you why that is the right fix, why a floor pin beats an exact pin here, so you come out understanding the pattern instead of just trusting the tool. A fix you do not understand is a fix you cannot maintain. Then, after it writes the change, it verifies the fix actually took. A change that did not really resolve the problem fails loudly instead of passing silently, which is exactly the failure that bites you six months later when you have stopped looking.

And every one of those changes is logged. This is the part I added that matters most to me. Each detection and each fix streams out as a change-control record, an auditable line that says what was touched, why, and what happened to it. That is what makes it safe to let a tool, or a CI pipeline, or an orchestrator near your lockfile at all. You are never guessing what changed your overrides, because the record is right there, in order, after the fact. Detect, fix, verify, and log, the whole loop, finally running on the one file nobody was watching, inside a tool a lot of people already have installed.

And that is where we want to take it next. Not just a tool that fixes your overrides, but one that teaches you how they break in the first place. We are building toward a full library of worked examples, one real scenario for each way an override goes wrong, so the thing reads as much like a reference you learn from as a scanner you run. A security tool tells you that you have a problem. A good one makes sure you have fewer of them next time. I want it to be both.

I am not the flashiest developer you will meet, and I am fine with that. I am the one who finds the wound. I can walk into a mess, see the thing nobody is watching, and name the shape of what would fix it. Sometimes I build that thing. Sometimes someone sharper finishes it, or it belongs in someone else’s project and I hand it over. Either way the gap closes, and the next person hits it a little less hard.

That TRS-80 my father handed me in 1991 did not come with a plan. None of this did. I just kept finding things that were bleeding, and reaching for whatever would stop it.

---

The technical writeups behind this story: The postcss That Would Not Die, and How CVE Lite Ended My Override Grind, The Lockfile Scanner Said Clean. Grype Said Forty-One. Both Were Right., and The Apply Succeeded. The CVEs Persisted. The Log Knew..

Aaron Lamb Hexaxia Labs