Security Engineering
Intermediate 16 min read Security Engineering

SAST and Static Analysis

Read the code for bugs before it ever runs: how SAST works, its blind spots, rule tuning, and the triage discipline that keeps the findings believable.

SASTstatic analysissemgrepCodeQLtaint analysisfalse positives
Prerequisites: DevSecOps Fundamentals Secure Coding Practices
Introduction

What is this?

SAST (Static Application Security Testing) parses source code and flags security-insecurity patterns — injection, secrets, unsafe APIs — without executing the program.

Motivation

Why do you need it?

  • SAST is the cheapest scan that runs on every commit: it finds flaws at the exact moment fixing is cheapest.
  • Modern engines (semgrep, CodeQL) do data-flow and taint analysis, catching real paths not just string patterns.
  • A tuned SAST is the first answer to 'why didn't we catch this earlier' in every breach debrief.
Think about it

Mental model

Imagine

A proofreader

Think of

One who reads the sentence AND follows the pronoun trail

Naive proofreaders catch typos; great ones track how a 'they' flows three paragraphs — the taint path.

Mechanics

How it works

  • The parser builds an abstract syntax tree (AST); rule engines match patterns and data flows across it.
  • Taint analysis tracks untrusted input from source to dangerous sink (query, exec, HTML injection).
  • Rules cover language families; custom rules extend for your framework's pet antipatterns.
  • The tool reports findings with rule id, severity, file:line, and a fix hint — the ticket starts curated.

SAST data-flow in one pass

Parse
Sources
Sinks
Trace
Report
Real world

In production

  • A payment codebase blocks merges on new SAST highs; the 'eval input' class disappears within months.
  • A team writes a custom semgrep rule for its own anti-pattern and shrinks a recurring bug family to zero.
  • A security engineer audits SAST coverage: languages, frameworks, and repos absent from the scan are the real gap list.
Guidelines

Best practices

  • Run SAST on every merge request with a patched, pinned tool version.
  • Baseline then trip the queue: triage historical noise once, keep the 'new findings only' gate clean.
  • Write custom rules for your stack's own recurring patterns.
  • Pair SAST with human review for the 20% it cannot see (logic, authorization, design).
Watch out

Common mistakes

  • Trusting count zero as 'clean' — a scanner that only reads strings misses real data-flow bugs.
  • Never triaging findings, so the queue decays into ignored red ink.
  • Suppressing a rule family you never verified — quieting the 'noisy' rule can hide the biggest class.
  • Scanning only the main repo while imports, tests and deploy scripts escape review.
When things break

Debugging tips

  • When a SAST false positive persists, reproduce the trace manually and tune the rule with an annotation.
  • Compare rule engine versions in CI vs local: drift makes 'passes locally' disagree with 'blocks in CI'.
  • Keep a findings-per-rule dashboard; a spike in one rule is a real code smell, not noise.
Security

Security considerations

  • SAST reads code — restrict repositories and results to need-to-know, and treat secrets found as incidents.
  • Rule tuning is a security decision; reviewed diff, not a silent config edit.
Interviews

Interview checkpoint

Practice

Hands-on lab

Run Semgrep on a Tiny Vulnerable Repo
40 min · intermediate
In progress
Objectives
  • Create a minimal repo with a known insecure pattern.
  • Scan with semgrep and catch the taint/injection.
  • Tune a rule and confirm the finding clears.

Run Semgrep on a Tiny Vulnerable Repo

40 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Taint analysis in SAST tracks...

2

A clean SAST run is best interpreted as...

Go deeper

Official documentation

Semgrep docs
docs
CodeQL docs
docs