Free Dependency Scanner — Catch CVEs Before You Ship

#security #opensource #python #webdev

At my previous job, our security scanning happened after production deployment.

BlackDuck and Snyk would run as part of the build pipeline, but by the time results came back, the release was already live. Vulnerabilities became overdue tickets. The cycle was: ship → scan → find CVEs → scramble to fix → ship again.

We had Snyk CLI available for local scanning, but getting it set up was a pain — download issues, config problems, never worked reliably for everyone. For Maven we had IntelliJ's dependency tree view which was useful. But for npm or Python? Nothing. No way to see what was hiding in your transitive dependencies before shipping.

The part that bothered me most: transitive dependencies. The packages you never installed directly but that get pulled in by your packages. That's where Log4Shell hid. That's where most real vulnerabilities live. None of the free tools we had showed the full picture.

So I built DepAnalyzer.

What it does

Upload your package.json, requirements.txt, or pom.xml — get a full CVE report in seconds. No account. No setup. No pipeline.
It resolves your entire dependency tree — direct and transitive — and checks every package against OSV and NVD. Then it shows you exactly how each vulnerability got into your project:

my-app → express → body-parser → lodash@4.17.15
                                  ↑
                         CVE-2020-28500 · CVSS 7.5
                         Fix: npm install lodash@4.17.21

You can't fix lodash directly — it's not in your package.json. But knowing the path tells you what to actually update.

How it works

The key decision was a local PostgreSQL cache of 249k+ CVEs instead of hitting the OSV API for every package on every scan. Cold API calls take ~500ms per package. With the cache it's ~5ms. For a project with 50 dependencies that's the difference between a 25-second wait and something instant.

The cache syncs with OSV every 5 minutes — only fetching what changed.

For the risk score, I didn't want a simple CVE count. A project with 50 LOW CVEs isn't more dangerous than one with 1 CRITICAL. I use a logarithmic decay model — your first CRITICAL drops your score dramatically, your tenth matters much less.

Stack