On this page
What Is Static Application Security Testing (SAST)?
SAST scans your source code for vulnerability patterns before it runs — catching SQL injection, XSS, and more at the earliest stage. Learn the basics.
Quick answer
- SAST analyzes source code for security weaknesses without running the program.
- It catches injection, XSS, and other flaws at the earliest, cheapest stage — right in the pull request.
- It complements, not replaces, runtime testing and manual review.
What is SAST?
Static application security testing is the analysis of source code, bytecode, or binaries to find security vulnerabilities without executing the program. A SAST tool parses your code, models how data flows through it, and flags patterns that match known weakness classes — a query built by string concatenation, a missing authorization check, a dangerous deserialization. It’s “static” because the program isn’t running.
How it works
SAST tools work from rules: semantic patterns for each language that describe insecure code. Modern tools like Semgrep and CodeQL let you write or use community rules, so a tool can encode your security conventions, not just generic ones. Findings are reported with the file, line, and rule, so a developer can fix the issue where it lives.
Why it matters
SAST catches flaws at the cheapest point — before merge, before deploy, before a customer ever touches the code. For DevSecOps, it’s the “shift left” workhorse, and it’s especially valuable when code is being generated faster than humans can review it: the scanner reviews every line, every commit.
SAST vs DAST
SAST looks inside the code (white-box, before runtime); DAST attacks the running application from outside (black-box). SAST finds issues like injection and XSS early; DAST finds issues that only manifest at runtime, like misconfigurations and broken authentication in the deployed app. They’re complementary layers.
Where this bites vibecoders
SAST is the review that scales to AI-generated code. An assistant will regenerate SQL injection and other classic flaws without noticing; a SAST rule flags them the same way every time. The trap is noise — turn on too many rules and the wall of findings gets ignored. Start with a small ruleset, fix real issues, then expand.
Where AI coding assistants get this wrong
- Proposing SAST as a “security program” by itself, without runtime testing.
- Generating configs with every rule enabled, producing unmanageable noise.
- Treating findings as bugs to suppress rather than signals to fix.
- Assuming a clean SAST run means the app is secure.
Checklist
- Run SAST on every pull request, not just on release.
- Start with a focused ruleset and tune it to reduce noise.
- Fix or deliberately suppress each finding with a reason.
- Pair SAST with DAST and dependency scanning.
- Encode your team’s conventions as custom rules.
FAQ
What is the difference between SAST and dependency scanning?
SAST analyzes your source code for flaws; dependency scanning checks the third-party libraries you import for known vulnerabilities. A SQL injection in your code is SAST territory; a vulnerable version of a library is dependency-scanning territory.
What are common SAST tools?
Semgrep, CodeQL, SonarQube, and Checkmarx are widely used. Semgrep is popular for its speed and custom rules; CodeQL is powerful for deep data-flow analysis. See How to Add SAST Scanning to a GitHub Repo.
Does SAST produce false positives?
Yes, and managing them is part of the practice. A good workflow distinguishes true positives (fix now) from false positives (suppress with a comment), and tunes rules over time so the signal stays useful.
Related topics
- How to Add SAST Scanning to a GitHub Repo
- How to Add Security Scanning to Your CI/CD Pipeline
- What Is DevSecOps?