What SAST Is
Static Application Security Testing (SAST) is "white-box" testing. It analyzes your application's source code, bytecode, or compiled binaries without actually running the program. Think of it like a spellchecker in a word processor, but for security vulnerabilities — it reads the text of your code and flags patterns that are known to be dangerous, before anyone ever executes a single line.
How SAST Works
SAST tools parse your code into an Abstract Syntax Tree (AST) — a structured representation of the code's logic — and then apply a ruleset of known vulnerability patterns against it. They trace how data flows through your program (called "taint analysis") to find cases where untrusted user input reaches a dangerous function without being sanitized first.
Common findings include:
- Hardcoded credentials — AWS keys, database passwords, or API tokens committed directly into source files.
- SQL injection sinks — User input concatenated directly into a database query string instead of using parameterized queries.
- Weak cryptography — Use of MD5 or SHA-1 for password hashing, or ECB mode for encryption.
- Path traversal — User-controlled input used to construct file paths without validation.
Popular SAST tools by language:
| Language | Tool |
|---|---|
| Python | Bandit, Semgrep |
| JavaScript/TypeScript | ESLint (security plugins), Semgrep |
| Java | SpotBugs + FindSecBugs, Checkmarx |
| Go | gosec |
| Multi-language | Semgrep, SonarQube, Checkmarx |
Semgrep deserves special mention because it is open-source, extremely fast, and uses a human-readable rule syntax that lets teams write custom rules for their own codebase patterns.
When it runs: Very early. Ideally in the developer's IDE as they type (via a plugin), and again as a mandatory CI pipeline step immediately after a code commit.
Pros: Finds issues early; points to the exact file and line number; achieves 100% code coverage because it reads every file.
Cons: Produces "false positives" — flagging code that looks dangerous but is actually safe — because it cannot understand runtime context. A SAST tool might flag a SQL query built from a hardcoded string (safe) the same way it flags one built from user input (dangerous). Teams must tune their rulesets to reduce noise, or developers will start ignoring alerts.
Key Point: SAST is a first-pass filter, not a final verdict. Its value is in catching the obvious, high-confidence issues at zero cost (no running environment needed). Treat false positives as a tuning problem, not a reason to disable the tool. A well-tuned SAST ruleset with a low false-positive rate is a force multiplier for a small security team.