AI SAST vs Traditional SAST

Static analysis has read source code for decades, and it is good at what it does. But a new phrase keeps coming up in security tooling: ai sast. This post is an honest look at how AI assisted static analysis differs from the traditional rule based kind, what each is good at, and why the sound version of the AI approach keeps a deterministic graph as its source of truth instead of trusting the model to invent facts.

What traditional SAST does

Traditional SAST parses your code and looks for known dangerous shapes in it. It traces a value from where it enters, such as a request parameter, to where it lands, such as a database query. If tainted input reaches a sink without passing through something the tool recognizes as a cleaner, it raises a finding.

Here is the kind of flow it catches well:

name = request.args.get("name")
query = "SELECT * FROM users WHERE name = '" + name + "'"
db.execute(query)

The user controls name, it lands in a SQL string with no escaping, and the rule fires. This is fast, deterministic, and repeatable. Run it twice on the same code and you get the same answer. Run it on every commit and it catches obvious sink bugs before they ship.

Where rules run out

The trouble is that a rule does not know what your code is for. It matches patterns in the text, so it is strong on injection where input reaches a sink, and weak on anything with no fixed pattern. Two problems follow:

• It misses logic bugs. A missing ownership check on GET /api/invoices/42 is clean code. There is no tainted value, no dangerous sink, nothing for a rule to grab. So the rule stays quiet on one of the most common serious bugs in real apps.
• It produces many false positives. When a value was validated in a way the tool does not model, or the path is dead code, the rule cannot tell. To avoid missing a real bug it flags the maybe, and a developer spends time ruling it out. A backlog of noise trains teams to ignore the tool.

What ai sast adds

AI SAST puts a model on top of that picture. Instead of only matching patterns, a model can read code the way a person would. It can reason about what a function is meant to do, follow a flow that is too indirect for a fixed rule, and judge whether a candidate finding is actually reachable and harmful.

Take an access control example that rules miss. Say a notes app serves a note by id:

GET /api/notes/4471
Authorization: Bearer <user A token>

A rule checks the response is well formed and moves on, because nothing in the request looks malicious. A model reading the handler notices the id is a plain number from the URL, and that the query loads the note by id with no filter on the current user. It reasons about intent: a note is private, so the server should check who owns it, and this handler does not. That is an insecure direct object reference, and it has no payload and no pattern, which is why a rule never sees it.

The same reasoning catches a fail open check. Imagine an authorization function that returns True when a role lookup succeeds, but also returns True in the except branch when the lookup throws, so any error grants access. A rule matching known sinks walks right past it. A model reading the two branches can see that the error path opens the door instead of closing it.

The honest catch with models

A model on its own is not a safe security tool. It is nondeterministic, so it can give two different answers on the same file. It can hallucinate a call that does not exist or a flow that never connects. If you let a model roam a whole repository and report whatever it believes, you trade the known noise of rules for a new, less predictable kind.

A model is good at understanding intent and bad at being sure. Rules are sure and blind to intent. The useful design uses each for the half it is good at.

Pairing facts with understanding

The way to get the upside without the hallucination is to give the model hard ground to stand on: three parts working together.

• A deterministic code property graph for facts. A real parse of the code builds the call and dataflow graph: what calls what, what a value can flow into, what a pointer can reference. These edges come from a compiler grade parse, not from a guess. The public lachesis code property graph is this layer for us, the source understanding that the rest reasons over.
• A model for understanding and hypothesis. The model reads bounded, connected regions of that graph, not the whole repository at once. It asks the questions a rule cannot: what is this function meant to protect, does this check hold on every path, could this id belong to another account. It forms a hypothesis about a bug.
• Verification before reporting. A hypothesis is not a finding. The claim is checked against evidence before it goes in the report, so the output is proven rather than guessed.

The key move is that the model never invents edges. The graph is the source of truth for what connects to what, and the model reasons over regions of it. If the model believes a value flows from a request into a query, that path either exists in the deterministic graph or it does not. Understanding proposes, facts constrain, verification confirms. That is what keeps AI assisted analysis defensible instead of a stream of plausible sounding guesses.

Why bounded regions matter

Reasoning over a bounded region keeps the model focused on code that is actually connected, so it is not inventing links across unrelated files. It also makes the reasoning checkable, because the region and its graph edges are concrete. You can point at the exact functions the conclusion rests on.

How the two approaches compare

• How it finds bugs. Traditional SAST matches known patterns and taint rules. AI SAST reasons about what code is meant to do and forms a hypothesis.
• Determinism. Rules are repeatable and give the same answer every run. Models are nondeterministic, which is why the sound design grounds them in a fixed graph.
• Logic bugs. Rules miss access control and fail open flaws that have no pattern. Understanding plus verification reaches them.
• False positives. Rules flag maybes to stay safe. Verification before reporting removes the guesses the model would otherwise pass on.
• Trust. A rule finding is a candidate to triage. A verified finding is backed by evidence you can read.

We go deeper on this split in scanners vs research, and if you want the wider tool landscape first, our SAST vs DAST vs IAST post lays it out.

Where this sits honestly

None of this makes traditional SAST useless. It is fast, cheap, and good at sweeping for the known sink bugs, so keep running it. The point is that pattern matching has a ceiling, and the highest impact bugs live above it, in the assumptions code makes about who you are and what you are allowed to do. AI assisted analysis reaches those, but only when the model is grounded in facts and its claims are proven.

That grounding is the design UnboundCompute is built on: a deterministic graph for facts, a model to reason over bounded regions of it, and proof before anything is reported. The graph layer is open, and you can read the code as UnboundCompute on GitHub. We are early and still building, so we describe the approach rather than sell a result. A fuller walkthrough lives in how UnboundCompute works, and you can read where we are headed on our about page.

Frequently asked questions

What is the difference between AI SAST and traditional SAST?

Traditional SAST matches known dangerous patterns and taint rules over your source code. It is fast, deterministic, and repeatable, but it does not understand what the code is for, so it misses logic bugs and raises many false positives. AI SAST adds a model that reads code the way a person would, reasons about what a function is meant to do, follows less obvious flows, and judges whether a finding is real.

Can AI SAST catch bugs that rule based SAST misses?

Yes, especially bugs with no fixed pattern. A missing ownership check on a request like GET /api/notes/4471 is clean, well formed code with no dangerous sink, so a rule stays quiet. A model reading the handler can reason that a private note should be filtered by the current user and flag the insecure direct object reference. The same reasoning catches a fail open authorization check that grants access in an error branch.

Does AI SAST hallucinate findings?

A model on its own can. It is nondeterministic and can invent a call or a flow that does not exist. The sound design avoids this by keeping a deterministic code property graph as the source of truth for what connects to what, letting the model reason only over bounded connected regions of that graph, and verifying a claim against evidence before reporting it. The model proposes, the facts constrain, and verification confirms.

Should I replace traditional SAST with AI SAST?

No, keep running traditional SAST. It is fast, cheap, and good at sweeping for known sink bugs on every commit. AI assisted analysis reaches the logic and access control flaws that have no pattern, but only when the model is grounded in a real graph and its findings are proven rather than guessed. The two approaches cover different halves of the problem.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.