A scanner flags a CVE. The hard part is knowing where it reaches in your code. Codna traces the affected call paths deterministically, then ships a patch your own tests verify — AI vulnerability remediation without the guesswork.
The problem
A scanner tells you a dependency has a CVE, or that a vulnerable sink is reachable. It rarely tells you which of your call paths actually touch it, or whether the patch breaks something three modules away. So the work stalls: an engineer reads the advisory, greps for the vulnerable function, traces every caller by hand, and hopes the upgrade or the input-validation change does not regress behavior. Handing the whole repo to an AI agent to find the blast radius is slow and lossy — it burns 100,000+ tokens orienting before a single line changes. Meanwhile the exposure stays open while triage drags on, which is exactly where teams lose days on what should be a contained fix.
How Codna fixes it
Codna builds the dependency and call graph with a deterministic engine — no LLM, no RAG, no embeddings — in about 60ms per repo for zero tokens. It pinpoints every path that reaches the vulnerable function or dependency usage, as the code is right now.
The agent gets a tight evidence bundle — the affected call paths, the sink, and the relevant tests — measured at 162x less context than reading the repo. It writes a defensive patch that hardens the real path, not a guess at where the risk lives.
Codna re-runs your existing suite and gates the patch on it. A fix that fails your tests never lands, so you close the finding without trading it for a regression — at about $0.04 per verified fix.
codna fix . --issue "CVE-2025-1234: unsafe deserialization reachable from the upload handler"
What you get
A deterministic map of every call path that reaches the vulnerable code, built in ~60ms for zero LLM tokens — so you remediate the paths that are actually exposed, not the ones a model guessed at.
The fix is gated on your existing test suite. Closing a CVE never silently introduces a regression, because a patch that fails your tests is never proposed.
Self-host with bring-your-own-key, fail-closed egress, and no training on your code. The map runs locally for zero tokens — which matters when the code under review is the vulnerable part.
The proof
Codna maps the exact call paths a finding reaches, hands the agent a ~600-token evidence bundle to patch from, and gates the result on your own test suite. The patch lands only when your tests pass, so closing the vulnerability does not introduce a regression.
Yes. Codna traces how your code uses a vulnerable dependency and the internal paths the CVE touches, so the patch — an upgrade, a wrapper, or input validation — lands exactly where the exposure is rather than everywhere the package is imported.
Remediation. Codna starts from a finding you already have — a CVE, a scanner alert, a reachable sink — locates where it reaches in your own code, and ships a test-verified patch to close it. It fixes the issue rather than just reporting it.
No. Codna is strictly defensive. It locates where a known vulnerability reaches in your own code and produces a verified patch to close it — fixing, never exploiting.
Every patch is gated on your existing test suite — a hard gate, not a probabilistic review. The fix is proposed only when your own tests pass, so remediating a finding does not trade one problem for a regression.
Only if you choose. Codna self-hosts with bring-your-own-key and fail-closed egress, and never trains on your code. The deterministic map runs locally for zero tokens — which matters when the code under review is the vulnerable part.
Related
