Stop 10 · Application Security (AppSec)Topics · 3/9

Static Application Security Testing (SAST)

In short

SAST reads your source code without running it, looking for risky patterns like unsafe queries or hard coded secrets. It is a tireless reviewer that checks every line on every commit.

Automatically scanning source code (without running it) for known vulnerable patterns — catches issues early in development, though it produces false positives that require human review.

The blob proofreader circles mistakes on a long printed page with a red pen.

Think of it like this

The proofreader who never tires

A sharp proofreader reads an essay and circles every grammar slip, without needing to act out the story. SAST is that proofreader for code: it reads the text and flags risky patterns, long before the program ever runs.

Watch it happen

SAST versus DAST at a glance

SAST

Reads source code
Runs early, before build
Can give false positives

DAST

Tests the running app
Needs a live target
Misses code it never hits

SAST catches issues early in the code; DAST finds runtime problems later. They see different things, so mature teams run both.

The big ideas

What you need to know

Reads, does not run

SAST analyses source or compiled code statically, so it works even before the app can start.

Catches issues early

Run it in the editor and pipeline, so developers fix flaws as they write, not months later.

Expect false positives

Static tools flag patterns that may be safe in context. Tuning and triage keep the noise manageable.

Blind to runtime

SAST cannot see what only appears when the app runs, like a config or an auth flaw. Pair it with DAST.

See it in code

Walk through the code

yaml

1# Run a free SAST scan on every pull request2name: sast3on: [pull_request]4jobs:5  scan:6    runs-on: ubuntu-latest7    steps:8      - uses: actions/checkout@v49      - name: Semgrep scan10        run: |11          pip install semgrep12          semgrep --config auto --error

1/2The scan triggers automatically on every pull request, so no risky code merges unchecked.

This runs Semgrep, a free SAST tool, on each pull request. The error flag fails the build when it finds a serious issue.

Save yourself the pain

Common mistakes

Oops

Ignoring SAST output because it has false positives.

Do this instead

Tune the rules and triage findings. Some noise is normal; a real vulnerability hidden in it is not worth missing.

Oops

Relying on SAST alone for full coverage.

Do this instead

It cannot see runtime or config issues. Combine it with DAST and dependency scanning for a fuller picture.

Your mission

Scan your own code

~35 min

Quick check

What is a key limitation of SAST?

Go deeper

1Run a free SAST tool against a sample codebase and review the findings.
2Learn why SAST tools generate false positives, requiring triage, not blind trust.
3Understand SAST as one layer of a defense-in-depth AppSec strategy, not a complete solution alone.