Kusari Platform AutoFix

Fixes that arrive with their evidence.

Plan the fix against the real dependency graph, prove it in your CI, and leave the merge to your team, on every repo you own.

87% fewer vulnerabilities in 30 days, on Kusari's own estate
PULL REQUEST #4127 AUTOFIX fix(deps): core-utils 2.3.1 → 2.4.0 root cause: transitive, via lib-b · not the newest release CHECKS build passed unit tests passed integration passed inspector review no new risk provenance chain · CI result · reasoning for the version chosen Merge waiting on your team
Commercial and Open Source Partners
Google Microsoft Intel Red Hat VMware Yahoo DTCC Guidewire Roche Clear Alpha Purdue University
"
When it's found, it's fixed — what will we do with all the free time?
Security Leader · fintech company
What you get

A pull request that earns its merge.

Ship a fix that won't break something else
  • Accounts for your environment rather than upgrading to the newest version available
  • Tells you when a fix is a one-line change and when it will affect other systems
  • Patches transitive dependencies where a direct upgrade is not practical
Merge with the evidence attached
  • Attaches the provenance chain, the CI result, and the reasoning behind the version chosen
  • Waits on a human to approve, so the merge stays your team's call
  • Keeps the PR current as the surrounding code moves
Stop new risk before it lands
  • Evaluates many layers below the diff a developer opened
  • Has blocked pull requests that Snyk and Socket approved, including one from Snyk's own head of product
  • Runs on its own, free for developers, ahead of the platform
How it works

Plan, verify, merge.

Stage 01 · Plan
Model the change before writing it
  • Root causeFix the dependency causing the problem rather than the one reporting it.
  • Environment awareChoose the version your stack can actually take.
  • Breaking-change warningFlag when a fix will affect other systems before the work starts.
Stage 02 · Verify
Prove it before anyone sees it
  • CI validationPut the fix through the same pipeline your team ships through.
  • Inspector reviewCheck the change introduces nothing new, many layers below the diff.
  • Evidence panelAttach the provenance chain and the reasoning behind the version.
Stage 03 · Merge
Leave the last call to your team
  • Human approvalNothing lands without someone on your team merging it.
  • Kept currentRefresh the PR as the surrounding code changes.
  • Audit trailKeep what changed and why, for the question that comes six months later.
Take a tour

Watch a fix earn its merge

See the plan, the CI run, and the evidence panel on a real finding in your own repository.

FAQ

AutoFix, answered.

What makes AutoFix different from other automated fixes?

Most generate a version bump from the finding alone. AutoFix plans against the same dependency graph that produced the finding, so it can account for what else depends on the package, how deep the change reaches, and what your environment expects.

Will it merge code without us?

No. AutoFix opens a pull request and leaves the merge to your team. The change runs through your CI first, and the Inspector agent reviews it against the full dependency tree before it reaches you.

What happens when an upgrade would break something?

It tells you. Remediation planning models the change first and flags when a fix will affect other systems, and it can patch a transitive dependency where a direct upgrade is not practical.

How is AutoFix packaged?

AutoFix is available to Kusari Platform customers, metered by invocation so teams turn it up as confidence grows.

What is Kusari Inspector?

Inspector reviews changes at the pull request, before new risk lands. It evaluates the full dependency tree many layers below the diff, and it has blocked pull requests that Snyk and Socket approved. It is free for developers and runs on its own.

Get started

Close it, and keep the evidence.