AI SAST

What is AI SAST?

AI SAST applies a large language model (LLM) to source code to find vulnerabilities. Our own vendor comparison framework defines it as a solution that "provides vulnerability detection capabilities powered by artificial intelligence using SAST." The LLM receives code plus surrounding context, reasons about the data flow, and returns a judgment with an explanation instead of a rule ID.

The difference from conventional Static Application Security Testing is where the decision lives. A rule-based scanner encodes what a vulnerability looks like in advance. A rule writer describes a dangerous sink, an unsafe function, a tainted path. Anything the rule writer did not anticipate is invisible. AI SAST inverts that: the model is not told what the bug looks like, it is asked whether this code, in this context, can be abused.

That models find real flaws is not theoretical. In 2024, Google Project Zero and Google DeepMind reported that their Big Sleep agent found an exploitable stack buffer underflow in SQLite, the first real-world vulnerability discovered by the agent, and SQLite's maintainers patched it the same day. Big Sleep is agentic research, not AI SAST: it hunts one target deeply, while AI SAST runs continuously across a codebase as it changes. The common ground is what matters here — a model reasoning about code found what rules did not.

AI SAST, traditional SAST and AI coding agents are not alternatives

Three things get collapsed into one conversation, and buyers pay for the confusion. A rule set matches patterns. AI SAST judges context. A coding assistant writes software and can be asked to look for bugs on the side. They have different failure modes, and none of them replaces the other two.

Rules still win where the pattern is stable and the context burden is low. A hardcoded credential, a deprecated cipher, a disabled certificate check: a regular expression settles those faster than any model. AI SAST earns its cost on weaknesses whose exploitability depends on code assembled from several files.

So AI SAST belongs next to rule-based scanning, not on top of it: the cheap deterministic checks stay cheap, and the token budget goes to the classes that need a model's judgment. An organization that swaps its rule set for AI-powered SAST pays model prices for findings a regular expression was already catching. AI-powered SAST is an addition to an application security program, not a replacement inside it.

AI SAST at Fluid Attacks

Our AI SAST scanner runs inside the same program as our other scanners and our pentesters, available in our plans. What follows is what it actually does, including the parts of our own results that do not flatter us.

What we analyze, and under what rules

Your source code is analyzed under contract and under the controls in our compliance pages: TLS 1.3 in transit, AES-256 for object storage and the platform database, and mutual TLS to our origin. Audit evidence for SOC 2, PCI DSS and ISO sits in our Trust Center. Findings stay in our platform, where your team controls access, and our service-level agreement commits us to detecting 90% of the severity of vulnerabilities, measured per calendar quarter across all of your groups.

How candidates get prioritized

AI SAST does not try to read every file, because reading every file is the wrong objective when each read costs tokens. Our documentation is explicit: "Manual techniques and AI-SAST use statistical risk prioritization instead of file coverage as their operating objective," and "the AI-SAST prioritization model uses the probability that a snippet has a specific vulnerability."

That is the architectural choice that makes the technique affordable. Snippets go to the model in order of estimated risk, so budget lands on the code most likely to be vulnerable instead of being spread evenly over code that is not.

What it looks like in practice

From AI findings to published advisories

We point the scanner at open-source projects to test it against code nobody wrote for us. The funnel from our published workflow is the clearest picture of what this technique yields.

CVE-2026-6093 shows why context is the whole game. In Corteza 2024.9.x, the jsonPath function escaped single quotes with a backslash instead of T-SQL's quote doubling, and a second defect let payload.ParseMeta skip key-format validation when meta arrived as a JSON object. Neither is a vulnerability alone. Together they let an authenticated user inject SQL into a generated expression. Our scanner flagged the candidate; Oscar Uribe, of our Offensive Team, confirmed the chain and published our advisory.

Our advisory for CVE-2026-6093, showing the scanner that detected it and the researcher who disclosed it.

Where our own numbers get uncomfortable

In our benchmark against coding agents, the configuration of AI SAST that found the most real vulnerabilities found them at 52% precision. It caught 72 of 100 planted flaws and raised 66 bad calls doing it. Higher recall is bought with triage work, and any vendor who reports one number without the other is hiding half the trade.

The second result surprised us more. Running the same system on larger models made it worse: 0.19 recall with GPT-5.5 and 0.47 with Opus 4.8, against 0.72 with the cheapest configuration. The extraction, the flow analysis and the validation around the model mattered more than the model itself. Buy the architecture, not the model name.

What this technique does not cover

Our scanner is not yet meant to find every weakness type. The research concentrates on classes where context decides exploitability: flows between files, data persistence, SQL and authorization controls. It is also not a substitute for software composition analysis, which looks at third-party dependencies rather than your own code, nor for dynamic testing or cloud configuration review. A CVE in a library you imported is not a problem AI SAST is looking for.

How AI SAST works

An AI SAST pipeline has four moves. The repository is split into functions. A model scores each function for the probability of a specific weakness. The highest-ranked snippets go to specialized agents that pull in surrounding code through tool calls — callers, callees, related templates, the storage layer. Each candidate is then confirmed or discarded with its reasoning attached.

The model acts as a candidate generator, not as a verdict. That framing is what keeps AI SAST usable. A model asked to produce a final answer about exploitability will produce one whether or not the evidence supports it, which is how hallucinated vulnerabilities reach a developer's queue. Every step after scoring exists to make the model prove its claim against retrieved code.

Non-determinism is handled the same way: by design rather than by hope. The same snippet can get different answers across runs, so the pipeline constrains what the model is asked, grounds it in code it has actually read, and treats a single positive as a candidate to be checked. A finding that survives is worth a developer's attention.

This is where AI SAST separates from pointing a chat model at a repository. The model is the smallest part of the system: extraction decides what it sees, scoring decides what it reads first, validation decides what reaches a person. In our testing those three stages explained more of the result than the model did.

AI SAST vs. traditional SAST: a comparison

Rule-based scanners and AI SAST fail in opposite directions, and the comparison only makes sense per weakness class rather than in the aggregate.

Contextual understanding

Many vulnerabilities are not visible on a single line. Stored cross-site scripting is the standard example: user input arrives in one file, gets persisted in another, and is rendered unescaped in a template somewhere else. Each file looks fine on its own. Our weakness catalog describes stored XSS as the ability to persistently inject JavaScript into application fields, scores it at CVSS 4.0, and maps it to fixes in seven languages — but finding it in a real repository means assembling three files into one story.

Entry 010 of our weakness catalog, with its CVSS 4.0 score and language-specific fixes.

That assembly is what AI SAST does and what a single-file scanner structurally cannot.

Precision, recall and what each one costs

Independent research points the same way. At ICLR 2025, the authors of IRIS combined a language model with static analysis and evaluated it on 120 manually validated vulnerabilities: CodeQL detected 27, IRIS with GPT-4 detected 55, and four of its findings were unknown to existing tools.

Our own data points at the same gap. In our benchmark of 36 third-party AppSec tools against a web application seeded with 1,201 vulnerabilities across 105 CWE categories, a pentester reached 89.6% recall at 100% precision, well above what any automated tool in the study managed on the same target. Closing part of that distance without putting a person on every file is the job AI SAST is built for.

Language support and execution

Rules are written per language, so coverage grows one grammar at a time and new frameworks lag. A model generalizes across syntax, which makes AI SAST useful on languages a rule set has not reached — though a weakness class the pipeline does not target is still missed, whatever the language.

AI SAST vs. AI coding agents

Asking a coding agent to audit a repository is not the same as running a scanner built to audit repositories. We measured the gap across 52 codebases, 68 versions and roughly 98 million lines of code, then scored every configuration on 200 snippets: 100 real injection and scripting vulnerabilities and 100 decoys written to look vulnerable without being exploitable.

Costs marked with an asterisk are projected from a targeted run, not measured end to end.

Read the last row carefully, because it is the one a dashboard will misreport. Claude Code produced zero false positives and 100% precision, which looks like the best result in the table. It also missed 92 of the 100 real vulnerabilities. A tool that never cries wolf and never finds the wolf is not a security control. This is a measurement of two vulnerability classes on one dataset, not a general ranking of these products — but it is enough to show that precision alone tells you nothing about coverage.

AI SAST for remediation, verification and compliance

AI SAST that stops at a ticket does not reduce risk. Three things have to follow a finding for vulnerability remediation to actually happen: a fix the developer can act on, proof the fix worked, and a line back to whatever standard the organization is audited against.

Generative AI fix guidance is the first. A patch applied in one click is convenient, but a guide that explains the secure alternative in the context of your codebase changes how the next function gets written. Developers who get contextual guidance stop reintroducing the same class, which is the compounding return AI SAST has over a scanner that only labels.

Verification is the second. A fix is not finished because a model says so; our platform lets your team request a reattack, and the vulnerability stays open until testing confirms it is closed. Our CI Gate breaks the build when a finding violates your policy, which keeps unverified code from shipping.

Compliance is the third, and it is where AI SAST quietly saves the most time. Our security rules catalog carries 2,206 rules across 47 targets, mapped to 173 standards, so a finding arrives already connected to the OWASP, PCI DSS or NIST requirement it breaks. Auditors do not accept a list of bugs; they accept a mapped control with evidence of closure, and that mapping is what turns AI SAST output into audit evidence instead of a backlog.

How to evaluate an AI SAST solution

The OWASP Benchmark project exists to verify the speed and accuracy of vulnerability detection tools, and its logic is the right starting point for evaluating AI SAST: a claim without a dataset behind it is marketing. Most AI SAST pitches lead with precision because precision is the number that improves when a tool reports less. These are the questions worth asking instead.

A finding in our platform, with the explanation of where attacker input reaches the query.

Conclusions

AI SAST moves the decision about whether code is exploitable from a rule written in advance to a model reasoning over context, and that shift is what lets it catch weaknesses spread across several files. It is not free and it is not clean: our best-recall configuration ran at 52% precision, the larger models underperformed the cheapest one, and every candidate still passes a person before it becomes a vulnerability report. Those limits are the reason we publish the numbers rather than a single precision figure, and the reason AI SAST sits inside an Application Security Program with scanners and pentesters rather than standing in for one. Agents build, you lead, we secure — and the securing part still ends with a person reading the evidence.

Frequently asked questions

How accurate is AI SAST? 

It depends entirely on the configuration and the dataset, which is why a single number is not an answer. In our benchmark of 200 snippets covering injection and scripting flaws, our highest-recall configuration found 72 of 100 real vulnerabilities at 52% precision, while configurations built on larger models reached 0.47 and 0.19 recall.

Can AI SAST find vulnerabilities that rule-based scanners miss? 

Yes, specifically those whose exploitability depends on code in other files. Stored scripting flaws and injection chains that cross an input handler, a storage layer and a template are the clearest cases. Independent work points the same way: at ICLR 2025, IRIS detected 55 of 120 validated vulnerabilities where CodeQL detected 27.

How is AI SAST different from an AI coding agent? 

A coding agent is built to write software and can be prompted to look for bugs; AI SAST is a pipeline built to find them, with code extraction, flow analysis, prioritization and validation around the model. In our benchmark, two coding agents found 9 and 8 of 100 real vulnerabilities.

Does AI SAST still need human review? 

Yes. A model finding is a candidate, not a confirmed vulnerability. Our analysts determine whether attacker-controlled data reaches a dangerous operation and whether sanitization, escaping, validation or authorization blocks it, then handle deduplication and severity.

Does Fluid Attacks use AI SAST to find new CVEs? 

Yes. Of 1,006 scanner findings our analysts reviewed on open-source projects, 118 were unique true positives and 28 became CVE candidates. Twelve are published advisories, including CVE-2026-6093, a SQL injection in Corteza confirmed and disclosed by our Offensive Team.

Put the model's findings in front of a pentester

Our AI SAST scanner and our pentesters review your code together, so a candidate becomes a confirmed vulnerability before it ever reaches your developers' queue. Start free trial · Contact us.