Turn Dependabot CVE alerts into bump PRs
Condux reads the open Dependabot findings on a connected repository and turns a fixable one into a dependency-bump draft pull request your team reviews and merges. Same safe engine as the code fixes.
A CVE alert is only useful once it is fixed. Condux closes that gap: it surfaces the open findings and, on one click, opens the bump PR, so remediation is a review, not a research project.
From finding to fix
- Surface the findings
Open Dependabot CVE alerts on a connected repo, with severity and the fixed version.
- See what is actually running
Where a server-side Condux SDK reports it, the finding shows which versions of that package were seen running, in which release and environment.
- One-click bump PR
A fixable finding becomes a dependency-bump draft PR authored by the bot.
- Same guardrails
Draft PR only, credential isolation, metered against your AI-fix allowance and spend cap.
Frequently asked questions
How is this different from Dependabot's own PRs?
It runs through the same safe Conductor engine as your code fixes, with the same credential isolation, audit trail and per-org allowance and spend cap, all in one place beside your errors.
Can it tell me whether the vulnerable version is really deployed?
It shows you what was observed. A server-side Condux SDK reports the dependency versions your application actually resolved, and the finding lists the ones seen for that package with their release, environment and last sighting. A manifest cannot tell you that, because it does not see transitive resolution, lockfile drift or a deploy that no longer matches the branch someone scanned. We show the observed version beside the advisory's fixed version and leave the comparison to you, rather than printing a verdict we cannot stand behind.
What if my language reports nothing?
Then the finding shows no runtime line at all, and that means we did not observe it rather than that you are unaffected. It is read on the server, so a browser or edge bundle has no package tree to read and a project that ingests only through OTLP will not have it either. The JVM SDK reports nothing here on purpose: a jar almost always states its version and almost never states the group and artifact name an advisory is indexed against, so an entry built from it would match nothing and read as not observed anyway.