Static Application Security Testing (SAST)

This skill covers Static Application Security Testing — analyzing source code, bytecode, or binaries for security vulnerabilities without executing the application. It provides both the theory and practical implementation of SAST across the major tools.

How to Approach Tasks

1. Identify the tool -- Read the relevant sibling skill when a tool is named.
2. Understand the goal -- Finding vulnerabilities? Reducing false positives? CI/CD integration? Custom rules?
3. Apply SAST-appropriate reasoning -- SAST has inherent false positive rates; balance thoroughness vs. developer friction.
4. Integrate with context -- SAST findings mean more when mapped to OWASP Top 10 / CWE IDs and linked to remediation guidance.

Tool Routing

User mentions	Route to
SonarQube, SonarCloud, SonarLint, quality gate, quality profile	sonarqube
Checkmarx, CxOne, CxQL, KICS	checkmarx
Semgrep, semgrep rule, semgrep pattern, metavariable	semgrep
Snyk Code, DeepCode, Snyk SAST	snyk-code
Veracode, pipeline scan, policy scan, binary analysis	veracode

SAST Fundamentals

How SAST Works

SAST tools parse source code into an intermediate representation (typically an AST — Abstract Syntax Tree) then apply analysis techniques:

Pattern matching: Regular expressions or AST patterns. Fast, low false-negative rate for known patterns, but high false-positive potential. Used by Semgrep.

Taint analysis (data flow): Tracks user-controlled data ("taint") from sources (HTTP parameters, file reads) through the program to sinks (SQL queries, shell execution, HTML output). Finds injection vulnerabilities. Used by all enterprise SAST tools.

Control flow analysis: Understands how code execution can reach a particular point. Used to determine reachability and reduce false positives.

Type inference: Understands variable types even in dynamically typed languages to reduce false positives.

Inter-procedural analysis: Tracks taint across function/method call boundaries. Computationally expensive but necessary for real application code.

Source and Sink Taxonomy

Sources (user-controlled input):

• HTTP request parameters, headers, cookies, body
• File system reads of user-supplied paths
• Database reads of user-supplied data
• Environment variables in some contexts
• IPC / message queue data

Sinks (dangerous operations):

• SQL query construction → SQL injection
• Shell command execution → OS command injection
• HTML output rendering → XSS
• File path operations → path traversal
• URL fetching → SSRF
• Deserialization → insecure deserialization
• Log writing → log injection

Sanitizers (functions that break the taint chain):

• Parameterized queries / prepared statements
• Output encoding (HTML, URL, JavaScript)
• Input validation against allowlist
• Path canonicalization and allowlist check

False Positive Management

SAST tools have inherent false positive rates. Enterprise tools (Checkmarx, Veracode) typically see 30-50% FP rates without tuning. Semgrep community rules can be higher.

Tuning strategies:

1. Suppression annotations: Mark false positives inline with tool-specific comments (// NOSONAR, # nosec, // nosemgrep)
2. Path exclusions: Exclude test files, generated code, vendor directories
3. Custom rule tuning: Narrow rule patterns to reduce noise
4. Sanitizer registration: Tell the tool which custom functions sanitize input
5. Severity thresholds: Gate CI on Critical/High only; Medium/Low as informational

False positive vs. false negative tradeoff:

• Security-focused: prefer fewer false negatives (miss fewer real issues), tolerate more false positives
• Developer-experience-focused: prefer fewer false positives, tolerate some missed issues
• Practical balance: tune to <20% FP rate for gated findings, keep informational findings for review

CI/CD Integration Patterns

PR/MR scanning (incremental):

• Scan only changed files or new code
• Annotate the PR/MR with findings on the diff
• Block merge only on newly introduced findings (not pre-existing)
• Tools: SonarQube PR decoration, Semgrep --baseline-commit, Snyk Code PR checks

Full scan (scheduled or release):

• Complete codebase analysis
• Compare to baseline, track trends
• Input to security backlog
• Tools: all enterprise tools support full scan mode

Quality gate pattern:

PR opened
  → SAST scan (incremental, 2-5 min target)
  → Findings annotated on PR diff
  → Gate: any new Critical or High? → Block merge
  → Developer sees finding inline, fixes in same PR
  → Re-scan, gate passes
  → Merge allowed

Language Coverage Considerations

Category	Generally Well-Supported	Limited Support
Web backend	Java, C#, Python, JavaScript/TypeScript, PHP, Ruby, Go	Rust (improving), Kotlin (improving)
Mobile	Swift, Kotlin, Java Android	React Native, Flutter
Infrastructure	Terraform, CloudFormation, Kubernetes YAML	Pulumi, CDK
Compiled	C/C++, C#	Assembly, COBOL

Check specific tool for language support before deployment — depth varies significantly (e.g., Java taint analysis is far more mature than Go taint analysis across most tools).

SAST in the Security Program

Maturity levels:

• Level 1: Run SAST, review results manually, no gates
• Level 2: SAST in CI, gate on Critical, results tracked in backlog
• Level 3: SAST in IDE + CI + scheduled full scans, gated by severity, custom rules for org-specific patterns, metrics dashboarded
• Level 4: SAST integrated with threat model, custom rules per business logic, SLA-driven remediation, developer security champions

Integration with other tools:

• SAST + SCA: SAST finds code vulnerabilities, SCA finds library vulnerabilities. Both needed.
• SAST + DAST: SAST finds code paths, DAST validates runtime exploitability. Combine to reduce false positives.
• SAST + WAF: SAST finds XSS in code, WAF blocks XSS payloads at runtime. Not redundant — defense in depth.