.svg)
Every vulnerable dependency, fixed — automatically, deterministically.
Heeler burns down the dependency backlog and responds the moment new CVE research lands — computing the safest upgrade, validating it through your build and CI, and opening a merge-ready pull request. No human in the loop until review.
Three ways dependency fixes stall
Auto-bump bots pick “latest” and break the build. Chatbot fixers let a model guess the version. And when neither can be trusted, the backlog gets deferred — while upgrades age and get riskier.
“Just upgrade to latest”
Auto-bump bots grab the newest tag — pulling in new breakage, new CVEs, and major-version churn nobody asked for.
A model guessing the version
Chatbot fixers let an LLM choose what to upgrade to. Now your security outcome depends on a guess you can't audit or reproduce.
Deferring instead of fixing
So the backlog gets “prioritized” while dependencies age, upgrades get harder, and the eventual jump is bigger and riskier.
Heeler computes. The agent applies. Your CI proves.
The upgrade is computed, not guessed by AI
For each vulnerable dependency, Heeler uses your dependency graph and active CVE data to pick the version with the highest security impact and the least breaking-change risk — not the latest tag. It respects your minimum package-age policy, and for transitive CVEs it finds the smallest direct-ancestor upgrade that resolves them out of your tree.
- Lowest version that clears the CVEs and adds no new ones
- Weighs security impact against breaking-change risk
- Transitive fixes via the smallest direct-ancestor bump that resolves the whole closure
- Reproducible and auditable — computed from your graph and CVE data, not a prompt
An agent does the work, in a governed loop
The agent applies Heeler's exact target version — editing manifests, lockfiles, and any first-party code the upgrade breaks. It validates the build and dependency resolution with ecosystem-specific checks, then runs your CI. If checks go red, a repair loop pushes fix commits to the same PR until they pass.
- Branch off your base commit; your CI runs on the PR
- Repair-on-red loop — bounded attempts to get CI green
- Abstains when uncertain — can't build it clean? It aborts and tells a human what to do
A documented, merge-ready PR
Every PR states the impact, the changes made, how it was validated, and the exact CVEs resolved. If the agent had to deviate from the requested version, it documents why — with evidence the substitute still clears every CVE. Heeler opens the PR automatically by default; clear skip review to inspect the fix before the PR opens. Either way the pull request goes through your existing branch protections — Heeler never merges it for you.
- Impact, changes, validation, and CVEs fixed — in the PR body
- Skip review is on by default; clear it to review the fix before the PR opens
- Your repository's own PR template shapes the body — a Heeler PR reads like every other PR in the repo
- The template shapes the write-up, never the agent's behavior — a PR body is not a side channel into what the agent does
- A fix that couldn't be validated opens as a draft — validated means validated
DUAL VALIDATION
Every fix is proven twice.
First in an isolated sandbox: the agent applies the change and runs a true build with your project's own toolchain — before a pull request even exists. Then through your own CI on the PR, iterating until the checks pass. Automation never quietly hands you a broken build; when it can't get to green, it tells you exactly why.
The agent applies Heeler's exact target version in an isolated sandbox — manifests, lockfiles, and any first-party code the upgrade breaks — and runs a true build with your project's own toolchain, not a surface check.
Heeler branches, commits, and opens the pull request — the upgrade, the CVEs it resolves, and how it was validated. If the sandbox build didn't pass, the PR opens as a draft: flagged, never disguised as ready.
Your pipeline runs on the PR exactly as it would for any engineer. Heeler reacts to check results from your SCM the moment they complete — no polling, no waiting.
A CI-fix agent reads the failing logs, attributes the failure to the upgrade, fixes it, and pushes a follow-up commit to the same PR — re-triggering CI. Earlier attempts feed back in, so it never repeats an approach that already failed.
If the loop can't finish, Heeler comments on the PR explaining exactly what it couldn't resolve — every intermediate commit and CI result left in place, plus a link into Heeler for the full run.
All CI checks pass — the PR is ready for review.
A bounded run of repair commits chasing green — then a person gets the finding with the full trail, not a mystery diff.
The agent judges the failure won't resolve automatically and stops early, rather than burning CI cycles.
Everything gets fixed. The most dangerous first.
Auto-fix works the backlog in the order that reduces risk fastest. Before a dependency vulnerability can rank Urgent it has to be genuinely exploitable — loaded in a running deployment, reached by your call graph, internet-exposed, and unmitigated. The most dangerous get fixed first; nothing gets written off. Every finding lands on one level: Urgent, Plan, or Defer.
One agent. Three ways in.
From a finding, from the pull request that introduced it, or from a standing policy — every fix enters the same governed loop.
Three doors into the same loop — every path is sandbox-validated, driven through your CI, never merged for you, and recorded in Agent Executions. A fix that doesn't build never gets pushed; the agent explains what it tried and routes to a human instead.
DEPLOYED
Merge isn't the finish line. Deployed is.
A merged fix still isn't proven until it's actually running. Because Heeler correlates your running deployments back to source, it tracks each fix past merge and confirms when the vulnerable code is genuinely gone — everywhere it was running.
Active → Fixed → Deployed
Three states, and only the last one means the risk is retired. Fixed means the change merged. Deployed means Heeler has seen the new code actually running.
Confirmed, not assumed
The same deployment correlation that powers reachability confirms closure. No runtime agent, no tagging, no manual sign-off — the evidence comes from your live environment.
Tracked per deployment
A service running in several places isn't closed until every one of them carries the fix. The Lifecycle panel shows the share actually deployed, not an average.
The step most tools skip
Almost every scanner closes a finding the moment the pull request merges. That's an assumption about production. Heeler waits for the evidence instead.
DETERMINISTIC × AGENTIC
Deterministic where it counts. Agentic where it helps.
The security decision is math, not a prompt. The labor is an agent's — inside a governed loop that abstains when it's unsure.
Decided deterministically — no AI guessing
- Whether a finding is auto-fixable (language and upgrade type)
- Which exact version to upgrade to — minimal viable, fewest new CVEs, most cleared
- Which direct ancestor to bump to resolve a transitive CVE
- The size and breaking-change risk of the upgrade
- Batching, the hold window, and the human-review gate
The agent does
- Applies the exact version Heeler chose
- Edits manifests, lockfiles, and the first-party call-sites the upgrade breaks
- Validates the build and dependency resolution, then runs your CI
- Fixes CI breakage in a bounded repair loop
- Writes the PR — and aborts to a human when it can't finish cleanly
AGENT EXECUTIONS
You can check the agent's work.
Deterministic means reproducible, and reproducible means you can go and check. Every run is recorded — the plan it followed, the tools it called, the files it changed, and where the pull request it opened now stands.
See the full audit trail →Heeler fixes the code you write, too.
You've just seen how Heeler fixes the dependencies you import. Its other half — SAST Auto-fix — fixes the code your team and your agents write: a deterministic, strategy-matched transform anchored to the taint path, validated in your build and opened as the same merge-ready PR. One context engine, one prioritization model, one workflow — across both halves of your codebase.
Explore SAST Auto-fix →See it fix a real CVE in your repo.
Connect a repo and watch Heeler compute an upgrade, validate it, and open the PR — in your first session.
