Static Application Security Testing (SAST) is the practice of analysing source code for security vulnerabilities without executing the program. A SAST tool reads your code the way a security-aware compiler would: following execution paths, tracking data flow, flagging patterns that match known vulnerability classes. Analysis happens offline, on source files, with no running server or test environment required. That makes SAST the right tool for catching security bugs at the moment a developer writes the code, on every commit, before a PR is merged.
Pattern matching defines regular expressions for dangerous constructs (eval(, System.exec(, password =) and flags every match. Fast and broad, but produces false positives — a regex can't distinguish whether the argument to eval is attacker-controlled or a hardcoded constant.
AST analysis parses source code into a structured syntax tree and analyses patterns within that structure. An AST rule can express "find all method calls to query() where the first argument is a concatenation involving a non-constant value" — far more precise than a regex, understanding code shape rather than raw text.
Taint analysis tracks data from untrusted sources (HTTP request parameters, form inputs) through the code until it reaches a dangerous sink (database queries, shell commands, HTML output). A taint finding fires only when there is a confirmed path from source to sink with no sanitisation in between. This is how serious SQL injection, XSS and command injection detections work. DepWarden's SAST engine combines all three: pattern rules for broad coverage, tree-sitter AST rules for structural precision, and an intra-file taint pass that only fires injection-class rules when user-controlled data actually reaches the sink.
Injection (SQL, NoSQL, LDAP, OS command) where user input reaches a dangerous API without sanitisation. Cross-site scripting (XSS) where user input is reflected into HTML without escaping. Hardcoded credentials: API keys, private keys and tokens committed directly in source. Weak cryptography: MD5 or SHA-1 for password hashing, ECB mode encryption, 1024-bit RSA keys, DES or RC4 usage. Insecure randomness for security-sensitive values. Path traversal via unsanitised file system calls. SSRF via user-controlled URLs fetched server-side. Insecure configuration: DEBUG = True in Django, CSRF protection disabled, CORS wildcard.
SAST runs without a deployed application — it can gate every PR and block merges on new critical findings. DepWarden covers 15 languages (JavaScript, TypeScript, Python, Java, Go, PHP, Ruby, C, C++, C#, Rust, Kotlin, Scala, Swift, Shell/Bash), IaC (Terraform, YAML, Dockerfile) and 300+ rules. False positives are managed through taint gating (only fire injection rules when the data flow is confirmed), confidence levels (separate HIGH-confidence from MEDIUM pattern-only findings), and suppression markers in code for known-safe findings. Starting with --fail-on critical and moving to --fail-on high once you have baselined is the practical approach. See also: SAST vs SCA — why you need both.