SAST explained simply

By Joris VeyPublished 4 October 2026updated 19 October 2026SASTIntroduction10 min read

Ever given the barista a fake name, just to hear it shouted across the whole coffee shop?
Congratulations: without knowing it, you have understood the most famous flaw in computing.

To spot flaws in the program's instructions, we use SAST (Static Application Security Testing): a tool that reads an application's code, without running it, to spot flaws before it goes live.

You will learn what this tool can detect, what it misses and which questions to ask your team.

Tip: words with a dotted underline have a definition. Hover over them, or tap them on a phone.

In 30 seconds

The risk

Text typed into a form can be taken as an order by the application, and make it hand over all its data.

The tool

A SAST tool reads the code before it goes live and follows inputs to dangerous operations, like a spell checker for security.

Your role

No coding needed: ask three questions to whoever writes your code.

If your website or application has a form, a customer area or a customer file: yes, whether the code is written by your team or by a contractor. If you read nothing else, ask three questions:

Is the security of the code checked automatically, on every change, before it goes live?
Who handles the alerts, how fast, and where are the decisions written down?
Who checks that a user only sees what they are allowed to see?

The over-obedient barista

At a takeaway coffee shop, you are asked for your first name. The barista writes it on the cup in marker, then shouts it at the counter when the drink is ready.

Now imagine a barista who follows the rule like a machine: they shout “Serve the orders of”, followed by whatever is written on the cup. Word for word. Without thinking. Watch the scene, in three acts:

The name copied into the sentence

You give as your first nameMartin, and every order waiting
The barista shouts“Serve the orders of Martin, and every order waiting.”
Result The counter obeys: you leave with everyone's drinks.

The name in a box of its own

The name goes in the “First name” box on the labelMartin, and every order waiting
The counter reads the instruction, then the box“An order for exactly 'Martin, and every order waiting'? There is none.”
Result Nothing is served by mistake.

With a human barista, it is a joke. With a program, which does not think, it is a flaw.

That is an injection:what you wrote was not treated as a name, but as part of the order.

In a real application, the counter is the database, and the shouted sentence is a question written in a language called SQL. The attacker does not write “and every order”, but a few characters that have the same effect.

Hence the name: SQL injection.

The fix is the same as at the counter: the question goes one way, the visitor's text the other, in its own box. Developers call this a parameterized query. The deep dive takes it apart line by line, with a demo to try.

Developers even have a cult joke about it: the comic xkcd #327 (2007), where a mother names her son “Robert'); DROP TABLE Students;--”. Translation: “Robert, and delete the list of students”.

The school lost all its records.
He has been known as Little Bobby Tables ever since.

Over a quarter of a century

You might think this flaw belongs to 2000s websites, visitor counter and blinking GIF included. Not quite:

1998
The first public description.
A researcher signing as “rain.forest.puppy” explains in Phrack magazine how to slip orders into the questions sent to a database. The instructions have been public ever since.
2008
Heartland: 130 million payment cards.
A crew led by Albert Gonzalez gets into Heartland Payment Systems, a card payment processor, through an SQL injection, then installs tools to intercept card numbers. Together with a few other victims of the same crew, more than 130 million card numbers are stolen.
Gonzalez gets twenty years in prison.
And one day, the sentence specifies.
2015
TalkTalk: forgotten pages.
The British telecom operator has the data of about 157,000 customers stolen through an SQL injection in old web pages nobody was watching any more. Among the attackers: teenagers. The UK regulator imposes what was then a record fine: £400,000.
2023
MOVEit: one flaw, 2,000 victims.
In late May 2023, the Cl0p criminal group exploits an SQL injection in MOVEit Transfer, file transfer software used by thousands of companies and public bodies. The toll: more than 2,000 organizations hit, and the data of tens of millions of people stolen.
In one go.
2025
FortiWeb: even the guards.
An SQL injection is found in FortiWeb, a Fortinet web application firewall, whose job is precisely to block… SQL injections. Attackers exploit it a few days after the patch is released.

What they have in common:none of these flaws is exotic. Each time, input from outside changes the order sent to the database. In 2024, the US cybersecurity agency and the FBI even published an alert asking software makers to finally get rid of SQL injection.
Twenty-five years after the instructions went public.

How SAST spots the danger

A SAST tool does not run the application and tries no attack. It reads the code, like a very patient proofreader, and looks for a dangerous path in three steps:

1. The input

A visitor types a name into the search box.

2. The journey

The program passes the text from hand to hand.

3. The sensitive operation

The text ends up pasted into the question sent to the database.

To follow that path, the tool does something quite simple in principle: it puts a drop of ink on everything that comes from outside, and watches where the ink spreads. If it reaches a sensitive operation without going through a box of its own, the tool can report the path it managed to reconstruct.

Specialists call this taint analysis. The tool still has to be able to model every step of the path.

What a SAST tool follows: the visitor's input, marked with ink, all the way to the sensitive operation. At the bottom, the data does reach the database, but as a plain value: it can no longer change the question. Simplified illustration: in a real program, the path often crosses several functions and several files.

It is a bit like a spell checker for security: it reads every line, on every change, without ever getting bored or taking a coffee break. And like a spell checker, it sometimes underlines a correct word, and lets through a mistake it does not know.

So what does SAST actually find?

The name pasted into the order is only the star of the family. A SAST tool also looks for its cousins:

Typed text that becomes an order.Just like at the café counter. Specialists call it injection, and it does not only target databases: a system command can be hijacked the same way. Close cousin: a badly checked file name that lets anyone open any file on the server.
A page that traps its visitors.An attacker slips a small program into a comment; it runs in every reader's browser and can steal their session. This is called XSS.
A booby-trapped parcel.The application unpacks data prepared by a stranger, which can trigger actions nobody planned, up to running code. This is called deserialization.
Poorly protected secrets.A password written in plain text in the code, or encryption that has been breakable for years.
Disabled protections.An encrypted connection that no longer checks who it is talking to: like handing a registered letter to anyone who claims to be the postman.

And what it cannot do: understand what the application is supposed to do. It sees that an input ends up in an order, not that a customer should never see someone else's invoice.

Fixing: the right box, not a sticking plaster

Faced with an alert, it is tempting to patch over: ban commas, refuse apostrophes, block the word “DROP”.
That is the sticking plaster.

It blocks one specific trick, never all of them, and ends up annoying real customers (a warm hello to everyone called O'Brien or N'Diaye whom forms keep rejecting).

The real fix comes in four steps:

Step 1
Understand the path: where the input comes from, and where it is pasted.
Step 2
Fix it where it is pasted: the separate box for values. And for what does not fit in a box, like the name of a sort column, a list of allowed values.
Step 3
Add a test that replays the attack and checks that it no longer changes anything, so that this flaw does not sneak back in.
Step 4
Run the analysis again, then put the new version into service. Until then, your visitors are still using the old one.

Key takeaway:whether it comes from a human or an AI, a fix follows the same path. An AI may well suggest the sticking plaster: quick, clean-looking, and not enough. Check that it removes the cause.

Not all alerts are equal

An injection on the login page of a public website and an injection in an internal tool used by three people on the first Monday of the month are not equally urgent. To sort them, we go back to the risk managers' old formula:

Risk=Likelihood×Impact

Exploitation likelihood depends on the conditions an attack requires: is the input accessible to anyone on the Internet, or only to a logged-in administrator?

Impact: what can be reached at the end of the path? The customer file, payments, or a product list that is already public?

Exposed to everyone and wired to sensitive data: fix it now. The rest gets scheduled, but not forgotten: every postponed alert has an owner and a date.

One last point: confidence in the alert matters too. An alert that is still uncertain on a public page deserves a quick check.

And when the tool gets it wrong

Like any detection tool, SAST can be wrong both ways. Think of a medical test: “positive” means “the tool found something”.

What the tool says	There really is a flaw	The code is safe
The tool alerts	True alert We fix it.	False positive False alarm: time wasted.
The tool says nothing	False negative Missed flaw: the real danger.	Justified silence Nothing to do.

A false positive is expensive: someone has to read it, understand it and decide. A team drowning in false alarms ends up not reading the reports at all, and that is when the real flaw slips through, lost in the noise.

Where do they come from?

A protection the tool does not see.The program only accepts a number, but the tool misses that check and just sees “an input, pasted into a question”.
A value that does not come from outside.A word hard-coded in the program, such as a table name: no visitor can change it.
An impossible path.The dangerous code exists, but no entry point (page, API, scheduled job) leads to it, once checked.

And false negatives, the most dangerous kind, come mostly from a file the tool could not read, a detour too long that it lost along the way, or a development framework it does not know. A good SAST tool is therefore judged on two things: how long it takes to decide on each alert (it must show the full path), and how honestly it reports what it did not read.

What SAST does not cover on its own

A SAST tool reads first and foremost the code your team writes, For the rest, you need other tools:

The code we write

SAST, the subject of this article

Can an input make the program do anything it likes?

The blocks we reuse

SCA, component analysis

Are we using a block with a known flaw? The SCA article covers it.

Servers and their settings

Server and cloud service configuration

Storage open to everyone, permissions that are too broad.

The live application

DAST, automated attack tests

What the application really does when attacked from outside.

Forgotten passwords

Secret detection

A key or password left in the code.

Above all, none of these analyses knows your business rules. Example: a website hands order 42 to anyone who types 42 in the page address.

Nothing is pasted into an order, most tools stay silent (some spot missing authorization checks, none knows your rules), and yet anyone can read their neighbour's invoice by changing one digit in the page address. Who may see what, only you know: it has to be written in the code, and tested.

Your turn: rush hour at the counter

You now hold all the cards: let's get behind the counter. You run the Sieve Café for five days.

Staff follow the instruction sheets to the letter, like a program, and every morning the analysis tool hands you its report. You decide what to do: each choice protects your customers… or wastes your day.

This game needs JavaScript. In short: five days, five reports.

A first name pasted into the order shouted at the counter, a first name that takes a detour through a colleague, a false alarm on a word printed in advance, a handwritten sheet the tool cannot read, and a customer who leaves with someone else's order just by giving a number.

The moral: the tool can follow detours it knows how to model. Choosing the right fix, dismissing a false alarm with proof and reviewing what it cannot read is where it all happens.

Quick quiz

Question 1.SAST flags an injection in an internal tool used by three administrators who are already logged in. Can it wait for the next release?

Show the answer

It depends.The likelihood is lower: you have to be logged in already. But look at the impact: if the query touches payroll, fix it quickly anyway.

Question 2.The SAST tool found nothing in your project. Is the application safe?

Show the answer

Not on its own.First check what the tool actually read: if you only look at the alerts, a file it could not read looks just like a file with no flaw. Check the errors and exclusions too.

Then remember what it does not see: reused blocks, servers, business rules.

Common questions

Does SAST replace a penetration test?

No, they complement each other. A penetration test, run by specialists, attacks the live application, often once or twice a year.

SAST reads the code on every change. The first finds logic flaws a tool cannot see; the second helps catch common flaws before they reach production, between two tests.

Isn't a web application firewall enough?

A web application firewall (WAF) filters, in front of the application, whatever looks like a known attack. It is useful, but it is a bouncer at the door: a well-dressed attack gets in, and the flaw stays in the code.

Does it slow developers down?

Well tuned, barely: alerts land where developers already work, and analyzing a single change is usually quick. Measure it on your code anyway, the duration depends on the project and the tool.

What really slows things down is noise. A tool that cries wolf ten times a day ends up ignored.

Wrapping up

An injection is input that ends up inside an order, like the name shouted word for word at the counter. A SAST tool rereads the code to spot that path before release, but it sees neither what it could not read nor your business rules. Keep three habits: an analysis on every change, a written decision for every alert, and tests on who may see what.

Words in this article · 10 words

SAST: Static Application Security Testing: analyzing an application's code, without running it, to find flaws.
Injection: A flaw where a visitor's input is executed as an instruction.
SQL: The language used to query a database.
Parameterized query: A question where the input travels separately, as a plain value: the separate box.
Taint: Following data that comes from outside all the way to a sensitive operation.
False positive / false negative: An alert on safe code / a real flaw the tool did not find.
Source: The input, where what the user types comes in (the cup).
Sink: The sensitive operation, where the data becomes dangerous (the counter).
Sanitizer: What neutralizes data for one specific operation. The separate box does even better: the data arrives, but can no longer change the question.
Coverage: The share of the code the tool actually analyzed.