At my previous job, we took dependency security seriously.
Every release went through security scanning. We had tools like Snyk and BlackDuck integrated into our pipeline, and on paper everything looked fine.
The problem?
The cvm prod scan happened after deployment.
The typical workflow looked like this:
- Ship the release
- Security scan runs
- Vulnerabilities are discovered
- Create tickets
- Rush out another release
We weren't preventing vulnerabilities from reaching production. We were discovering them after they were already there.
The Part That Always Bothered Me
Most developers know what packages they install directly.
If your package.json contains Express, you know Express is in your application.
What you usually don't know is what Express depends on.
And what those dependencies depend on.
And what those dependencies depend on.
A modern application can easily pull in hundreds or thousands of packages through transitive dependencies.
That's where things get dangerous.
The biggest security incidents often don't come from packages you installed yourself.
They come from packages buried deep in the dependency tree.
Log4Shell is probably the most famous example.
Many affected teams had never added Log4j directly. It arrived through other dependencies.
When vulnerabilities live several levels deep, finding them is only half the problem.
The harder question becomes:
How did this package get into my application in the first place?
Existing Solutions Didn't Quite Fit
We had access to Snyk CLI for local scans.
In theory, that solved the problem.
In practice, setup was inconsistent across machines and not everyone used it regularly.
For Maven projects, IntelliJ could visualize dependency trees reasonably well.
For npm and Python projects, the experience wasn't nearly as straightforward.
What I wanted was simple:
- Upload a dependency manifest
- Resolve the full dependency tree
- Check every dependency for vulnerabilities
- Show exactly how vulnerable packages entered the project
No accounts.
No setup.
No CI integration required.
Just answers.
Building a Better Way to Inspect Dependencies
That idea eventually became DepAnalyzer.
The goal wasn't to replace enterprise security platforms.
The goal was to answer one question quickly:
"What vulnerable packages are actually inside this project right now?"
You upload a package.json, requirements.txt, or pom.xml and the application:
- Resolves direct dependencies
- Resolves transitive dependencies
- Checks packages against vulnerability databases
- Displays affected packages and severity
- Shows the exact dependency path
Instead of seeing:
lodash@4.17.15
Critical vulnerability detected
You see:
`my-app
└─ express
└─ body-parser
└─ lodash@4.17.15`
CVE-2020-28500
CVSS: 7.5
Fix: Update dependency chain
That path is often more useful than the vulnerability itself because it tells you what actually needs to be upgraded.
Making Scans Fast
One challenge was performance.
Many scanners rely heavily on remote API calls.
That works, but it becomes slower as dependency counts increase.
Instead, I maintain a local PostgreSQL cache containing more than 249,000 vulnerability records sourced from:
- OSV
- NVD
- EPSS
- CISA Known Exploited Vulnerabilities
The cache syncs periodically and only downloads changes.
This reduces lookups from hundreds of milliseconds per dependency to just a few milliseconds.
For larger projects, the difference is significant.
What I Learned
Building this reinforced something I've seen repeatedly in production systems:
Security tools are most valuable when developers can use them before code ships.
Finding a vulnerability after deployment is useful.
Finding it before deployment is better.
Understanding exactly how it entered your dependency tree is even better.
Try It
DepAnalyzer: https://depanalyzer.com
No signup required. Upload a manifest file and get a dependency vulnerability report in seconds.
I'd Love Your Feedback
How are you currently scanning dependencies?
Do you rely on Snyk, Dependabot, Trivy, BlackDuck, or something else?
And more importantly:
How do you investigate vulnerabilities hiding in transitive dependencies?
I'm curious what workflows other teams are using today.
Top comments (0)