Every few days GitHub would nudge me with a new number. Twelve vulnerabilities. Then fourteen. No order, no weight, just a list that kept growing and a vague sense that I should probably do something about it.
I maintain open source projects the way most solo developers do, in whatever hour is left after everything else. When an alert list has no ranking, the real ranking becomes whichever fix is easiest, or whichever alert happened to load first. That's not prioritization. That's just picking the one closest to the top.
Showing the math
Commercial tools solve part of this. Snyk and its competitors will rank things for you. Most of them sit behind a paywall past the basics, and none of the ones I tried would show me the actual formula behind a score. You get a number and a color. You don't get the reasoning.
So I built DepTend: a dashboard that turns a GitHub repo's dependency data into a ranked list of maintenance missions, with every score shown alongside the inputs that produced it. Impact, effort, and how much the package matters to its ecosystem, weighted and visible, not hidden behind a proprietary algorithm.
It runs on npm, PyPI, and Go repos. Submit a repo, sign in with GitHub, and it pulls advisories from OSV, resolves what's actually affected, and ranks the fixes by what's worth doing first. Every mission links back to its source advisory and shows exactly how its score was computed, one click away.
Built on free tiers, on purpose
The zero-budget part isn't a marketing angle. It's a real constraint I designed around from day one. If a feature needed a credit card, it didn't ship:
- Postgres from Neon's free tier
- Hosting on Vercel's free tier
- GitHub Actions for the cron jobs
- No paid tier anywhere else in the stack
The bug that taught me the most
Early on, the ranking function's tie-break rule was based on when a mission got created. It looked correct in every test. Then I built a CLI that runs the same scoring logic locally and compared its output against the live dashboard for a real repo, and the order didn't match. Same missions, same scores, different order.
The cause was Postgres. When you write an entire repo's missions inside one transaction, the database's now() function returns the same value for every row in that transaction. My tie-break was comparing timestamps that were never actually different. It had probably never worked correctly, on either the CLI or the dashboard, since the day I wrote it. I fixed it by switching the final tie-break to the advisory's own publish date, real per-row data that isn't sensitive to batch-insert timing. Nobody using the dashboard would have noticed. I noticed because I'd built a second, independent way to check the first one, and the two disagreed.
That's the part of "explainable" that doesn't show up in a screenshot: being explainable to yourself first, in a way that surfaces your own bugs instead of hiding them.
Claim it, don't just report it
Missions don't have to sit with a repo's own maintainer either. The dashboard has a public board listing every open mission across every indexed repo. Anyone signed in with GitHub can claim one, work on it, and release it again if they change their mind. If you want to help a project you don't maintain, you can claim a mission and get a specific, scoped fix to make, instead of waiting for someone to label an issue "good first issue."
Honest about what's not solved yet
Right now, every mission shows low confidence. That's not a bug I forgot to fix. Two of the scoring inputs, how many other packages depend on a given one, and whether a fix has a real migration guide, don't have a data source wired up yet. Rather than fake a higher number, the score stays conservative until that data actually exists. I'd rather show an honest "low" than a confident number I can't back up.
Try it: deptend.vercel.app, free and open source. If you maintain something on npm, PyPI, or Go, submit it and see what it finds. If you don't maintain anything but want to help someone who does, the rescue board is open to anyone with a GitHub account.
Top comments (0)