sa-tests-db: data flows in static analysis

The Evolution of Static Analysis: From Patterns to Data Flow in sa-tests-db

A static analyzer qualifies under GOST R 71207-2024 using the sa-tests-db corpus for six languages: C, C#, Go, Java, JavaScript, Python. This is achieved by transitioning from pattern-based searching to data flow analysis, which accounts for interprocedural calls, control flow, and field sensitivity in structures. This approach minimizes false positives and false negatives across error types.

Limitations of Pattern-Based Search

Pattern-based analysis looks for dangerous calls like sprintf, system, or SPI_execute within a context of a few lines. It's effective for quick initial scanning but has limitations:

• It does not account for data flows between points of definition and use.
• False positives arise from the accidental proximity of suspicious code without a real connection.
• It misses long chains that pass through functions or files.

On the external sa-tests-db corpus, these limitations quickly become apparent, necessitating a shift to data-flow analysis.

Data Flow Analysis

Transitioning to data flow answers the question: can data from sources (like getenv, recv, fgets) reach dangerous sinks? This builds a graph of connections between the definition and use of values.

Advantages:

• Reduces false positives by verifying the actual route.
• Discovers interfunctional paths.

In implementation, the analyzer tracks taint propagation, excluding unrelated values.

Interprocedural Analysis

Intrafunctional data flow is insufficient for real vulnerabilities that pass through call chains. The interprocedural layer connects arguments with parameters:

• Tracking return values.
• Analyzing arguments in calls.
• Building a call graph for cross-file paths.

Without this, patterns only see local blocks, losing the system context.

Accounting for Control Flow

The existence of a data path does not guarantee a vulnerability. The path can be blocked by:

• Validation.
• Error handling.
• Permission checks.
• Logically unreachable branches.

Integrating control-flow analysis classifies paths:

• Unconditional (high priority).
• Conditional (requires manual review).

This filters out noise, improving report accuracy.

Field Sensitivity in Structures

In structures, taint from one field should not spread to the entire structure. Distinguishing between fields reduces false alarms:

• Separate taint tracking for each field.
• Excluding safe fields when reaching a sink.

Such details are critical for production code with complex data.

Hybrid Analyzer Architecture

The optimal approach combines stages:

• Pattern-based pre-scan for candidates.
• Filtering out trivially safe cases.
• Full data-flow analysis for the remainder.
• Prioritization based on confirmed paths.
• Downgrading the rank of unconfirmed ones.

This balances speed and accuracy.

The Role of sa-tests-db in Development

The sa-tests-db set serves as an external benchmark for error types corresponding to GOST R 71207-2024. It detects regressions during changes:

• Metrics: false positives, false negatives by language.
• Not aggregated averages, but a breakdown by categories.

A run from March 23, 2026, confirmed qualification for C, C#, Go, Java, JS, Python.

Key Takeaways

• Patterns are only suitable for quick filtering; data flow is essential for accuracy.
• Interprocedural + control-flow analysis finds 80% of real paths.
• Field sensitivity reduces noise by 30–50% in structures.
• sa-tests-db is a regression test, not a one-time demonstration.
• GOST requires metrics by error type, not general figures.

— Editorial Team