AI SAST remediation: what an AI code fix should and should not do

Static analysis tools are good at finding problems and poor at getting them fixed. A typical SAST run produces a list of findings, each with a rule, a file, a line and a severity. Turning each one into a correct code change is still a developer's job, and that is where the backlog grows.

AI code-fix tools promise to close that gap by drafting the change. They can help. They can also introduce subtle bugs, change behaviour nobody asked them to change, or create a false sense that something has been fixed. This post covers what a safe AI SAST remediation workflow looks like, and what to check before trusting one.

Why SAST findings do not get fixed

The barriers are rarely about whether a finding is real. They are about effort and context:

• The fix needs the whole file. A SQL injection on one line may need a change to how a query helper is called, an import, or a parameter list elsewhere in the file.
• The developer is not the author. Findings land on whoever owns the repository now, not whoever wrote the code.
• Guidance is generic. "Use parameterised queries" is correct and still leaves the actual change to be worked out for this codebase, in this language, with this library.
• Many findings, one file. A legacy file can carry several findings at once, and fixing them one by one produces conflicting changes.

What AI can reasonably do

A language model given the right context can draft a plausible fix for many common SAST rule types: injection, unsafe use of cryptographic functions, hard-coded credentials, insecure deserialisation and similar. The quality depends heavily on what it is given:

• The full file, not a snippet, so it can see imports, helper functions and code style.
• All the findings in that file at once, so the changes are consistent.
• The rule's own guidance: what the issue is, the recommended fix, and a compliant example in the same language.

What AI should not do is decide on its own that a change is correct and ship it. A model can produce code that compiles, looks right and changes behaviour in a way only a test or a reviewer will catch.

Design principles for safe AI code fixes

The output is a proposal, not a merge

The fix should arrive as a branch or a diff that goes through your normal review and CI process. Nothing should merge or deploy itself.

Fix only what was flagged

The instruction to the model should be explicit: change the listed issues and nothing else, keep variable names, indentation and style, and do not add imports unless the fix requires them. Small, focused diffs are reviewable. Large rewrites are not.

Ground the model in rule metadata

Pass the rule's recommendation and a compliant example in the target language. This narrows the model towards the known-good pattern instead of improvising.

Respect suppressions

Findings already marked as false positives should be skipped, so the tool does not keep "fixing" code that was reviewed and accepted.

Handle credentials carefully

A tool that writes to your repository needs a credential with write access. It should be passed per request, never stored or logged, and scoped to the repository being fixed.

Fall back gracefully

When the model is unavailable or returns nothing useful, the developer should still get the rule's guidance and compliant example, rather than nothing.

A review checklist for AI-generated fixes

Before merging any AI-drafted fix, check:

• The diff touches only the lines needed to address the listed findings.
• The fix uses the safe pattern the rule describes, such as parameterised queries rather than escaping input by hand.
• No new dependencies or imports were added without a reason.
• Error handling and return values are unchanged unless the fix requires it.
• Existing tests pass, and there is a test that covers the fixed path.
• A re-scan of the branch no longer reports the original findings.
• A re-scan does not report new findings introduced by the change.
• The change has a human reviewer who understands the code, not only the security rule.

Rolling it out

• Start with one or two repositories and the rule types that produce the most findings.
• Track how many AI-drafted fixes are merged as-is, merged after edits, or rejected. That ratio tells you where the tool helps.
• Keep severity filters in mind: running AI fixes on critical and high findings first keeps review effort where it matters.

How Onam approaches it

Onam's code-fix engine works on the findings produced by its static analysis scanner. For a completed scan, it reads the findings, skipping any already marked as false positives, and can be limited to chosen severities. It looks up each rule's metadata (title, description, recommendation and a compliant example matched to the language where one exists) and makes a shallow clone of the source repository.

Findings are grouped by file. For each file, the engine sends the full file content and every finding in it, with the rule guidance, to a large language model, with instructions to fix only the listed issues and preserve everything else, including style and indentation. The corrected files are committed to a separate fix branch named after the scan and pushed to your repository for review. The engine does not merge or deploy anything; your team reviews the diff, runs tests and merges through your normal process.

The Git token needed to push the branch is passed per request in a header, and is not stored or logged. Each finding's outcome is recorded with a status, so you can see which were patched on the branch and which were not. If AI generation is not available, findings still carry the rule's explanation and compliant example as guidance.

Request a demo to see a fix branch generated from one of your scans.