Vulnerable dependencies caught
before an attacker finds them
A dependency scanner that lists two hundred CVEs with no sense of which ones actually matter gets ignored within a week. We build an agent that scans your dependencies continuously and ranks each finding by whether the vulnerable code path is actually reachable in your codebase. It opens a pull request with the fix for anything genuinely urgent.
Why the alert list gets ignored
Dependency scanners exist in most stacks already, and most teams have learned to ignore them. The output is a long list of CVEs sorted by a severity score. That score does not account for whether the vulnerable function is ever actually called in your code. A critical-rated vulnerability in a test helper, never invoked in production, gets the same red banner as one in a library your app calls on every request. Faced with that list weekly, most teams either triage none of it or spend hours manually checking reachability by hand.
Patch fatigue and patch risk compound each other. Bumping a dependency version to fix a vulnerability can itself break something. Teams that do patch often batch updates together, which makes it harder to isolate what broke if something does. Teams that do not patch accumulate risk silently, until an audit or an incident forces the issue.
There is also the software bill of materials nobody maintains until a customer or a compliance review asks for one. Building it from scratch for a codebase with hundreds of dependencies takes longer than it should.
How the agent tells urgent from noise
The agent scans every dependency across the repositories in scope, on a schedule and on every merge. It checks each finding against known CVE databases, then against your actual code, to see whether the vulnerable function or code path is reachable from code you call. Findings get ranked by that reachability check combined with severity. A critical CVE in code your app actually executes surfaces first. A critical CVE in an unused test utility does not drown it out.
A straightforward version bump that fixes the issue without a breaking change gets a draft pull request. It carries the updated dependency and a note on what the fix addresses, ready for your normal review and test cycle. Anything requiring a code change beyond a version bump gets an issue instead, describing exactly what needs to change and why. A software bill of materials stays current and attached to every release, ready to hand to a customer or an auditor without rebuilding it from scratch. Typical setup: GitHub, GitLab or Bitbucket for the repository and pull request flow, Slack or email for the weekly digest.
Where your team still decides
Merging the pull request, delaying a patch for a specific release window, and accepting a finding as a known, tolerated risk all stay decisions your team makes. The agent surfaces the risk clearly and proposes the fix. It does not merge anything on its own. Sometimes a finding has no clean upstream fix yet. The choice between a workaround, a version pin, or accepting the exposure temporarily goes to a person, with the context the agent has gathered.
How the scan stays auditable
Every finding and its reachability assessment gets logged, along with whatever was done about it: patched, exempted, or still open. An audit or a customer security questionnaire has a clear answer ready. The agent never merges its own pull requests. Everything goes through your normal review and CI process. A kill switch pauses automatic pull request creation while keeping the scanning and alerting running, useful during a release freeze.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Single automation | from $800 | Up to a handful of repositories, reachability ranking, automatic patch pull requests | 4 to 8 days |
| Department package | from $2,200 | Dependency scanning plus secrets rotation and access reviews across your stack | 2 to 4 weeks |
Running cost is usually $15 to $45 a month in model usage depending on repository count and scan frequency.
Related
This pairs well with secrets rotation and access reviews and offboarding as part of the same security hygiene program. CI/CD pipelines with AI code checks put a dependency bump through the same risk review as any other change. Full package details are on the AI agents service page and the automation-everything overview. For how we handle security on infrastructure we run ourselves, see the secure infrastructure case study and the secure messenger case study.
Not sure which of your two hundred CVE alerts actually matter? Get in touch and we will run a reachability pass on your current list.
Tired of doing this by hand? We can take the whole routine off your team, not only this step: Routine takeover, from $400 →
FAQ
How much does dependency and vulnerability scanning cost?
From $800 for up to a handful of repositories, live in 4 to 8 days. A larger codebase or multiple teams usually run $1,500 to $2,500.
How is this different from the free scanner GitHub already runs?
GitHub's built-in alerts list every known CVE, whether or not your code actually calls the vulnerable function. This agent checks reachability first, so your team sees the handful that matter instead of a list of two hundred that mostly do not apply.
Does it just open pull requests automatically?
For a simple, non-breaking version bump with a clean fix, yes, as a draft pull request for review. Anything that needs a real code change gets an issue instead, with the specific fix needed, and your team makes the change.
What about vulnerabilities in our own code, not dependencies?
This automation focuses on third-party dependencies and the software supply chain. A broader code security review is a separate, deeper engagement. Ask us and we will scope it.
Can we exempt a finding we have already assessed as low risk?
Yes. An exception list lets your team mark a finding as reviewed and accepted, with a reason and an expiry date. It stops resurfacing every week, without being silently forgotten forever.