sa-tests-db: przepływy danych w analizie statycznej

Ewolucja analizy statycznej: od wzorców do przepływów danych w sa-tests-db

Statyczny analizator przechodzi kwalifikację według GOST R 71207-2024 na korpusie sa-tests-db dla sześciu języków: C, C#, Go, Java, JavaScript, Python. Osiąga się to poprzez przejście od wyszukiwania wzorcowego do analizy przepływów danych z uwzględnieniem wywołań międzyproceduralnych, przepływu sterowania i wrażliwości na pola struktur. Takie podejście minimalizuje fałszywe alarmy i pominięcia typów błędów.

Ograniczenia wyszukiwania wzorcowego

Analiza wzorcowa szuka niebezpiecznych wywołań takich jak sprintf, system czy SPI_execute w kontekście kilku linii. Jest skuteczna do szybkiego wstępnego skanowania, ale ma ograniczenia:

• Nie uwzględnia przepływów danych między punktami definicji i użycia.
• Fałszywe alarmy pojawiają się przy przypadkowym sąsiedztwie podejrzanego kodu bez rzeczywistego powiązania.
• Pomija długie łańcuchy przez funkcje lub pliki.

Na zewnętrznym korpusie sa-tests-db takie ograniczenia szybko się ujawniają, wymagając przejścia do analizy data-flow.

Analiza przepływów danych

Przejście do przepływów danych odpowiada na pytanie: czy dane ze źródeł (getenv, recv, fgets) mogą dotrzeć do niebezpiecznych sink'ów. To buduje graf powiązań między definicją a użyciem wartości.

Zalety:

• Zmniejszenie fałszywych alarmów dzięki sprawdzeniu rzeczywistej ścieżki.
• Wykrywanie ścieżek międzyfunkcyjnych.

W implementacji analizator śledzi propagację taint, wykluczając niepowiązane wartości.

Analiza międzyproceduralna

Intrafunkcyjny data-flow jest niewystarczający dla rzeczywistych luk w zabezpieczeniach przechodzących przez łańcuchy wywołań. Warstwa międzyproceduralna łączy argumenty z parametrami:

• Śledzenie zwracanych wartości.
• Analiza argumentów w wywołaniach.
• Budowanie call-graph dla ścieżek międzyplikowych.

Bez tego wzorce widzą tylko lokalne bloki, tracąc kontekst systemowy.

Uwzględnienie przepływu sterowania

Obecność ścieżki danych nie gwarantuje luki. Ścieżka może być blokowana przez:

• Walidację.
• Obsługę błędów.
• Sprawdzanie uprawnień.
• Logicznie nieosiągalne gałęzie.

Integracja analizy control-flow klasyfikuje ścieżki:

• Bezwarunkowe (wysoki priorytet).
• Warunkowe (wymagają ręcznej weryfikacji).

To filtruje szum, zwiększając dokładność raportu.

Wrażliwość na pola struktur

W strukturach taint jednego pola nie powinien rozprzestrzeniać się na całość. Rozróżnianie pól zmniejsza fałszywe alarmy:

• Oddzielne śledzenie taint dla każdego pola.
• Wykluczanie bezpiecznych pól przy osiąganiu sink.

Takie szczegóły są kluczowe dla kodu produkcyjnego ze złożonymi danymi.

Hybrydowa architektura analizatora

Optymalne podejście łączy etapy:

• Wzorcowy pre-scan dla kandydatów.
• Odrzucanie trywialnie bezpiecznych przypadków.
• Pełna analiza data-flow dla pozostałych.
• Priorytetyzacja według potwierdzonych ścieżek.
• Obniżanie rangi dla niepotwierdzonych.

To równoważy szybkość i dokładność.

Rola sa-tests-db w rozwoju

Zbiór sa-tests-db służy jako zewnętrzny benchmark dla typów błędów zgodnych z GOST R 71207-2024. Wykrywa regresje przy zmianach:

• Metryki: false positives, false negatives według języków.
• Nie zagregowane średnie, a breakdown według kategorii.

Przebieg z 23 marca 2026 r. potwierdził kwalifikację dla C, C#, Go, Java, JS, Python.

Co jest ważne

• Wzorce nadają się tylko do szybkiego filtrowania, data-flow jest obowiązkowy dla dokładności.
• Analiza międzyproceduralna + control-flow znajduje 80% rzeczywistych ścieżek.
• Wrażliwość na pola zmniejsza szum o 30–50% w strukturach.
• sa-tests-db to test regresji, a nie jednorazowa demonstracja.
• GOST wymaga metryk według typów błędów, a nie ogólnych liczb.

— Editorial Team