You've seen the alert. You've opened the PR. You've read the changelog. Then you realize: your code doesn't even call the vulnerable function.
Every week. Hundreds of teams drowning in CVE notifications for packages sitting dormant in their node_modules — dependencies they pulled in years ago, bundled by a transitive library, and never actually executed. Meanwhile, the real vulnerabilities get buried.
VigilOps is a free Node.js CLI that fixes this.
How VigilOps Works
VigilOps does three things:
Scans dependencies against OSV.dev — the open vulnerability database used by GitHub, PyPI, and npm
Runs static reachability analysis to filter out unreachable vulnerabilities (packages in your tree but never called by your code)
Auto-opens a GitHub PR with the fix
The result: you get one PR with one real vulnerability. Not a spreadsheet. Not a wall of Slack messages. A fix.
Demo
Here's a quick scan:
npx vigilops scan examples/vigilops-demo-lodash
And to see everything including suppressed (unreachable) deps:
npx vigilops scan examples/vigilops-demo-express --all
The --all flag shows what's in your dependency tree but not actually reachable from your code. That's what the noise looks like — and that's what VigilOps filters out.
Why This Is Different
Dependabot and Snyk scan your entire lockfile. They report every CVE in every package, regardless of whether your code ever touches the vulnerable surface. This creates alert fatigue that causes teams to eventually... stop reading.
VigilOps inverts the model: only surface vulnerabilities in code you actually call.
Dependabot: "Your project has 47 vulnerabilities" (but 40 are unreachable noise)
VigilOps: "Your project has 1 reachable vulnerability. PR is ready."
Quick Start
npm install -g vigilops
npx vigilops scan .
Authenticate with GitHub: https://github.com/Vigilops/vigilops
npx vigilops auth
That's it. The first run will scan, analyze, and open a PR if there's a fixable reachable vulnerability.
What's Included
OSV.dev integration — covers npm, PyPI, Go, Rust, Ruby, and more
Static analysis — identifies which packages are actually reachable from your entry points
GitHub PR automation — opens a PR with a pinned safe version and a summary of what changed
Suppress filters — if you want to see the full tree, use --all
GitHub
Questions, issues, contributions: https://github.com/Vigilops/vigilops
Try It
npx vigilops scan examples/vigilops-demo-lodash
Start with a demo repo or point it at any Node.js project. If it finds nothing, you now have confidence in your dependency tree. If it finds something — you have a PR waiting.
VigilOps is free and open source. Built for maintainers and small dev teams who've had enough of the noise
Top comments (1)
The reachability filter is the important move here. A lot of teams say they want fewer vuln notifications, but the real issue is that lockfile-level reporting collapses “installed somewhere” and “reachable from our runtime” into the same severity bucket, which is how alert fatigue wins. I also like that the output is a PR instead of another dashboard, because maintainers usually need a fix path more than one more source of truth. The interesting next challenge is proving that the reachability model itself is conservative enough for dynamic imports, generated paths, and framework magic, since that is where trust in this kind of tool usually gets won or lost. Curious how you’re thinking about false negatives versus noise reduction as the analysis gets deeper.