Remediation
Turn xgrep findings into fixed code — apply the safe fixes automatically, hand the judgement calls to a coding agent, and prove every change by re-scanning it.
Remediation
A scan gives you a list. What you actually want is the list gone.
xgrep fix closes that gap: it takes the findings a scan produced and turns them
into committed code changes — applying the fixes that have exactly one right
answer, delegating the ones that need judgement to your coding agent, and proving
every change by re-scanning it before it is written.
xgrep scan . # find
xgrep fix # review and fix, interactivelyscan never modifies your source. fix is the only command that writes, and it
only ever writes a change it has verified.
What you get
The obvious fixes, applied for you. verify=False → verify=True,
InsecureSkipVerify: true → false, a cookie missing HttpOnly, an
http:// URL that should be https://. Where a rule knows the one correct edit,
xgrep makes it — no prompt, no model, no waiting.
The hard ones, handed to your agent with the context it needs. Where the fix depends on what the code is trying to do, xgrep does not guess. It hands your coding agent the unsafe region, the strategy, the sanitizers it will accept, and the criteria the result has to meet — then checks the answer.
Nothing written that isn't proven. Every edit is re-parsed and re-scanned before it lands. A fix that would break the file, or that doesn't actually clear the finding, is rejected rather than written. You never have to wonder whether a "fix" fixed anything.
Vulnerable dependencies upgraded too, not just vulnerable code — the same command, the same verification.
A pull request at the end, opened from the fixes you accepted, if you want one.
The loop
| Step | Command | What happens |
|---|---|---|
| Find | xgrep scan . | discovers findings and caches them |
| Confirm | xgrep fix --triage-only | decide what's real before you change anything |
| Fix | xgrep fix | apply, or delegate, the fixes |
| Prove | automatic | every change re-scanned before it is written |
You can start anywhere in it. Fixing without triage is fine — triage exists for when you'd rather not hand-review a hundred findings first.
Where to go next
- Fixing code — the interactive review session, delegating to a coding agent, and opening a pull request from what you fixed.
- Fixing dependencies — upgrading the packages a CVE names, including the transitive ones.
- Triage — confirming what's real first, by hand or with an agent, so a fix run only touches findings someone stands behind.
Overview
Inventory the sensitive data a codebase handles and find where it leaks — PII, PHI, PCI, and secrets flowing to logs, external services, AI models, responses, or storage — from source alone, no datastore access.
Triage
Decide which findings are real before you change anything — by hand in the review session, or headlessly with a coding agent — and fix only what someone stood behind.