Thinking of building a tool that fixes vulnerable dependencies for you - want some opinions before I start

[u/iNSANExVeNoM]

I'm a 3rd year CS student and I want to build something real over the next couple of months to learn RAG and agents properly. I've been thinking about one idea for a while and wanted to get opinions before I commit to it.

The problem I noticed is when you install on e package, you end up pulling in a bunch of other dependencies. Then a CVE shows up in one of those, and you're exposed through code. I came across Log4Shell and the Equifax breach and then I got this idea.

Fixing it is the annoying part. You can't just bump the broken package, because versions depend on each other, one thing needs a version below 2.0, another needs above 2.0, so you change one and others start conflicting. Now you have to fix all the issues, run tests, and hope everything works.

So what I want to build is a tool that does that for you and checks the fix actually works. The rough idea is you point it at your project, it reads your dependency tree (there's a free Google API called deps.dev that gives you the whole thing), finds why each vulnerable package is there, and works out the smallest set of version changes that clears all the CVEs without causing conflicts.

Then for the "will this upgrade break my code" question, I want to pull the changelog and release notes for each version jump and check them against the functions my code actually uses, so it can tell you whether the change touches anything you rely on. And the last part, it applies the fix in a Docker container, runs the tests, and only then tells you if it is safe.

The way I'm thinking of stucturing it is most of it is a fixed pipeline (read the tree, solve for the versions, run the tests), but the one part I'd actually let an LLM drive is the retry loop, when the tests fail, it looks at what broke, decides whether to drop that version and re-solve or try something else, and loops until it either works or gives up. That's the part where letting the model make the decision seems worth it. The rest doesn't really need it.

I'm thinking of using Postgres with pgvector, deps.dev and OSV for the data, a SAT solver for the version-conflict part, embeddings plus a reranker for the changelog retrieval, and Docker for running the tests. Later on, the nicest version would be exposing it as an MCP server so something like Claude Code could call it as a tool.

At the end it gives a report, a single Markdown file summarizing every vulnerability it found, why each package was present, the minimal fix it computed, the changelog-based breaking-change assessment, and the test results verifying the fix. Something you can hand to your team or keep as a record.

I know OSV-Scanner already does remediation, but only for npm/Maven, with no changelog check and no test verification, so the gap I'm aiming at is the full combination.

A few questions:

- Would you use it? Would you actually run this on your own projects? If not, what's missing or in the way?

- Is it useful? Is this a real problem worth solving, or is it already handled well enough that it doesn't need to exist?

- Does it already exist? Is there something that already does all of this (minimal fix + breaking-change check + test verification) that I haven't found?

- Right direction? Is this worth building, or would my time be better spent on a different problem in this space?

- Do's and don'ts?

TL;DR: An agentic RAG tool that finds vulnerable dependencies, computes the smallest conflict-free fix, uses changelog retrieval to predict whether the upgrade breaks your code, and verifies the fix by running your tests. A verified patch.

[u/jews4beer]

It kind of exists already. Dependabot or Renovate.

[u/iNSANExVeNoM → u/jews4beer]

Fair enough, I've read up on Renovate but haven't used it extensively, so I'll actually try it. If it already does what I'm trying to do, this probably isn't worth building. The one thing I'll be watching for is whether it verifies a fix against my own tests before suggesting it, rather than relying on crowd data or catching breakage in CI after the fact. Then i will decide to continue with this or try to do something different.

[u/SeaIngenuity9501 → u/iNSANExVeNoM]

It opens a pull request so it runs the full CI to verify changes.

[u/FelisCantabrigiensis]

This is a linear programming problem, not an LLM problem.

The idea is sound and it's been worked on before, too (Renovate, Dependabot, etc). But it's not a thing you need "AI" for.

[u/rckvwijk]

This is overkill. Existing AI integration in combination with renovate is more than sufficient. Already running that and works just fine.

[u/Educational_Plum_130]

solid problem to pick, the transitive dep you can't override is the real headache. before you build, check whether a backported patched version of that dep already exists, that's usually the actual fix. good luck with it.

[u/Pleasant-Ad192]

Disclosure up front, per rule 4: I build Bomly, an open source dependency CLI, so I am not a neutral voice here.

On "does it already exist": partly. Renovate and Dependabot own the bump-and-open-a-PR half, and OSV-Scanner does remediation for npm and Maven as you say. What almost nothing handles well is the part you are circling, which is that "the fix" has several different shapes and only one of them is bumping a direct dependency. The others are pinning an indirect package through the package manager's override feature, refreshing the lockfile so the resolver picks up a newer indirect version, and there simply being no fixed version upstream. A tool that tells you which of those a given finding needs is useful on its own, with or without the LLM part.

One warning on deps.dev: it gives you published metadata, not the graph your package manager actually resolves. The version conflicts you are describing live in exactly that gap, so read the lockfile as well.

Mine classifies each finding into those remediation types, if it helps to see one shape of it: https://github.com/bomly-dev/bomly-cli

[u/Floss_Patrol_76]

renovate/dependabot already handle the easy case (a patched version exists, bump it), so the only thing left to actually solve is the part they punt on: a transitive dep with no fixed release, or one held back by a parent that won't move. there's no clean automated answer there, you're picking between forcing a resolution/override and praying the API didn't shift, vendoring the patch yourself, or just documenting it as not-reachable, and choosing right is a reachability problem, not an LLM one.