SAST — how to find vulnerabilities in code before hackers do

Have you ever wondered how experienced programmers find bugs in someone else’s code just by looking at it? They look for patterns. They know that if user data goes straight into an SQL query — that’s bad. If a password is compared with a plain == instead of a secure function — that’s a risk.

But a person can’t review 100,000 lines of code without missing something. This is where SAST (Static Application Security Testing) comes in.

What is SAST and how does it work?

SAST is a source-code analysis technology that works without running the application itself. Imagine it as a very advanced “spell-checker”, but instead of typos it looks for architectural and logical vulnerabilities.

How does it do that?

• Scanning: the tool parses your code into components (builds the so-called abstract syntax tree — AST).
• Data flow analysis (Taint Analysis): this is the “smartest” part. The scanner tracks the path of data from a “source” (for example, an input field in the browser) to a “sink” (a function that writes to the database or outputs to the screen).
• Pattern matching: if data travels from the user to a dangerous function without prior sanitization (validation), SAST raises an alert.

Why is this needed if there are tests?

Many beginners think: “I have unit tests and integration tests, they will check that everything works.” The problem is tests check functionality, not security.

• Test: checks that when the username Ivan is entered it gets written to the database as Ivan.
• SAST: checks what happens if the user enters ' OR 1=1 --. It sees that your code isn’t ready for that scenario, even if functionally everything works perfectly.

The main tool: introduction to Semgrep

Today the industry is moving away from heavyweight, expensive tools toward lightweight and fast ones. Semgrep is the gold standard for the modern developer. It’s free for Open Source, supports dozens of languages, and runs incredibly fast.

Why Semgrep?

Unlike old scanners that flooded developers with thousands of “false positives”, Semgrep works based on simple and understandable rules. You can write a rule for your project in 5 minutes yourself.

Practical example: SQL injection

Let’s look at a classic mistake in Python/Flask:

@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    # ОПАСНО: переменная напрямую вставляется в строку запроса
    query = "SELECT * FROM users WHERE id = %s" % user_id
    db.execute(query)

Semgrep will detect this using a rule that looks roughly like: “Find any call to db.execute() where a string formed with % or f-strings is passed, if it includes data from request.”

How to run Semgrep locally

Installation:

pip install semgrep

or

brew install semgrep

Run in the project folder:

semgrep scan --config auto

The tool will detect the language your code is written in, download up-to-date security rules from the community, and produce a report.

Introducing SAST into the process (Shift Left)

In DevSecOps there is the concept of Shift Left. That means security should start as early as possible — at the code writing stage, not right before release.

Automation in GitHub/GitLab

You shouldn’t run the scanner manually. The most effective way is to configure it to run on every Pull Request.

If your colleague (or you) accidentally adds vulnerable code, the CI system (for example, GitHub Actions) simply won’t allow that code to be merged into the main branch until the issue is fixed. This creates a “culture of quality” where security is not a separate stage but part of everyday work.

Dealing with “noise”: what to do with false positives?

No scanner is perfect. Sometimes SAST will mark safe code as dangerous. This is called a False Positive.

How to live with that:

• Tune rules: if a rule is too “paranoid”, it can be disabled or adjusted.
• Ignore (Inline Suppress): most tools allow you to leave a comment above the line of code (for example, # nosemgrep) explaining why it’s safe here.
• Triage: in large teams security leads review reports and mark them as “fix” or “false”.

Summary: three SAST rules for a beginner

1. Start small: install Semgrep and just run it once on your project. You’ll be surprised how many useful tips it gives (not only about security, but also about code style).
2. Automate: code that isn’t automatically checked is potentially vulnerable. Set up checks in CI.
3. Don’t fear mistakes: SAST is not an exam, it’s your partner. It helps you become a better developer by teaching you to recognize dangerous patterns.