Static Analysis (SAST)

A core SAST technique that tracks untrusted user input (a source) as it flows through the application to a sensitive function (a sink), flagging potential injection vulnerabilities.

• How it works: The analyzer models data flow to see if user-controlled data reaches a dangerous operation without proper sanitization.
• Common Sources: HTTP request parameters, headers, cookies, database reads.
• Common Sinks: SQL execution functions, OS command calls, HTML output functions (XSS).
• Example Vulnerability Found: SQL Injection, Command Injection, Cross-Site Scripting (XSS).

Tools parse source code into an AST—a tree representation of the code's structure—and then apply rules to identify problematic patterns.

• Pattern Matching: Searches for specific, dangerous code constructs (e.g., use of eval() or md5()).
• Semantic Analysis: Understands code semantics to find more complex issues than simple pattern matching.
• Advantage: Fast and language-specific, allowing for precise rule definition.
• Used by: Linters (ESLint, Pylint) and many modern SAST tools as a foundational step.

SAST tools inspect the source code or intermediate representation (like EVM bytecode) directly, using techniques like data flow analysis, control flow analysis, and taint tracking to find patterns indicative of vulnerabilities. This allows for deep, systematic reviews but requires access to the codebase and an understanding of its structure.

SAST has several inherent constraints:

• False Positives/Negatives: Can flag benign code (false positives) or miss complex, runtime-dependent issues (false negatives).
• No Runtime Context: Cannot detect vulnerabilities that only manifest with specific transaction sequences or external state.
• Limited Logic Bug Detection: Struggles with flawed business logic that is syntactically correct but semantically wrong.
• Configuration & Tooling: Effectiveness depends heavily on rule sets, which must be kept current with new attack vectors.

SAST excels at finding well-defined code-level flaws, including:

• Reentrancy: By tracking external calls and state changes.
• Integer Over/Underflows: Through arithmetic analysis.
• Access Control Violations: By checking permission modifiers.
• Unchecked Return Values: From low-level calls.
• Gas Inefficiencies: Identifying patterns leading to high gas costs.

SAST is one pillar of a robust security strategy. It should be combined with:

• Dynamic Analysis (DAST/Fuzzing): Tests the live, running contract.
• Manual Review: For complex logic and architectural flaws.
• Formal Verification: For mathematical proof of specific properties. No single method is sufficient; SAST provides the essential first layer of automated, scalable code review.

To maximize SAST effectiveness:

• Integrate Early: Run in development and CI pipelines, not just before audits.
• Tune Rules: Customize rule sets for your project's specific risks and reduce noise.
• Triage Results: Dedicate time to manually review and validate findings.
• Combine Outputs: Correlate SAST results with findings from other testing methodologies to build a complete risk profile.

Beyond security, SAST enforces code quality and adherence to best practices and style guides. This improves maintainability and reduces gas costs.

Common checks include:

• Gas optimization patterns (e.g., using unchecked blocks safely, storage vs. memory)
• Conformance to standards like Solidity Style Guide
• Detection of dead code and unused variables
• Complexity analysis to identify overly convoluted functions

This proactive analysis helps developers write cleaner, more efficient, and less error-prone code from the start.

SAST is most effective when automated and integrated into Continuous Integration/Continuous Deployment (CI/CD) pipelines. This provides continuous security feedback.

Typical workflow:

1. Code is committed to a repository (e.g., GitHub).
2. CI pipeline (e.g., GitHub Actions, GitLab CI) triggers the SAST tool.
3. The tool analyzes the diff or entire codebase.
4. Results are reported, often failing the build if critical vulnerabilities are found.

This shift-left approach embeds security directly into the developer workflow, preventing vulnerabilities from reaching production.

Advanced SAST tools provide a pathway to formal verification by generating mathematical models of the smart contract's logic. They help verify that the code's behavior matches a formal specification or set of invariants.

How it supports formal methods:

• Abstract Interpretation: Creates an abstract model of the contract to prove general properties (e.g., "this state variable never decreases").
• Model Checking: Exhaustively explores possible states to verify temporal logic properties.
• Specification Generation: Helps developers draft the initial formal properties that need to be proven.

Tools like SMTChecker (built into Solidity) and Certora Prover leverage these principles.

The blockchain SAST ecosystem features specialized tools for different analysis depths and languages.

Primary Tools:

• Slither: A static analysis framework written in Python for Solidity. It provides vulnerability detection, code optimization hints, and printer utilities.
• Mythril: A security analysis tool for EVM bytecode using concolic analysis and taint checking.
• Semgrep: A fast, lightweight static analysis tool that uses pattern matching for many languages, including Solidity.
• Solhint: A linter for Solidity code that focuses on style guide and security best practice enforcement.

These tools are often used in combination for comprehensive coverage.

SAST has inherent limitations, making it one part of a broader security strategy. It must be combined with other methods.

Key Limitations:

• False Positives/Negatives: Can report non-issues or miss complex, context-dependent bugs.
• Runtime Behavior: Cannot analyze dynamic interactions, oracle data, or complex economic attacks like flash loan exploits.
• External Dependencies: Limited analysis of integrated off-chain components or other contracts.

Essential Complements:

• Dynamic Analysis (DAST): Testing the running contract (e.g., fuzzing with Echidna).
• Manual Audits: Expert review for business logic and novel attack vectors.
• Bug Bounties: Crowdsourced testing in a production-like environment.

A security testing methodology that analyzes a running application, as opposed to its source code. DAST tools interact with a deployed system (e.g., a live smart contract) to find vulnerabilities by simulating attacks. Key differences from SAST include:

• Target: Executing code vs. static source.
• Findings: Discovers runtime flaws like logic errors and environment-specific issues.
• Stage: Performed post-deployment or in staging environments. SAST and DAST are complementary; SAST finds code-level bugs early, while DAST uncovers issues in the live system.

The mathematical process of proving or disproving the correctness of a system's logic against a formal specification. In blockchain, it's used to prove a smart contract behaves exactly as intended under all possible conditions. Unlike SAST, which scans for known bug patterns, formal verification attempts to mathematically guarantee the absence of entire classes of errors. Tools like K Framework or Certora Prover use this method for high-assurance contracts.

The fundamental data structure that enables SAST. An AST is a tree representation of the abstract syntactic structure of source code. SAST tools parse code into an AST to:

• Traverse the code's logic flow without executing it.
• Apply pattern-matching rules to identify vulnerable code structures.
• Perform data flow and control flow analysis. The accuracy and depth of SAST are directly tied to the tool's ability to construct and analyze a precise AST.

A specific type of data flow analysis used within SAST to track untrusted user input ("tainted" data) through a program. It identifies if tainted data can reach a security-sensitive function (a "sink") without proper validation ("sanitization"). In smart contracts, this is critical for finding:

• Reentrancy: Tainted external call return values.
• Input Validation: Unchecked user-provided parameters.
• Oracle Manipulation: Tainted price feed data.

A lightweight form of static analysis focused on code style, formatting, and catching simple errors. Linters (like Solhint for Solidity) enforce coding standards and best practices. While SAST encompasses linting, its primary goal is deep security vulnerability detection. Linting is often the first, fastest layer of static checking, handling rules like:

• Style: Naming conventions, indentation.
• Simple Bugs: Unused variables, shadowed variables.
• Gas Optimizations: Identifying patterns that waste gas.

An advanced SAST technique that executes a program using symbolic values (representing arbitrary inputs) instead of concrete data. It explores all possible execution paths to derive constraints and find inputs that cause erroneous states. In blockchain security, it's used to:

• Generate test cases that reach deep code branches.
• Prove the absence of overflow/underflow for all inputs.
• Discover complex logical contradictions. Tools like Manticore and Mythril apply symbolic execution to Ethereum smart contracts.