SAST vs DAST vs IAST — porównanie narzędzi w AppSec

SAST vs DAST vs IAST to trzy różne punkty widzenia na bezpieczeństwo aplikacji. SAST analizuje kod bez uruchamiania programu, DAST atakuje działającą aplikację od zewnątrz, a IAST obserwuje wykonanie od środka podczas testów. Żadne z tych narzędzi nie daje pełnej ochrony i żadne nie zastępuje manualnego testu logiki biznesowej.

Najczęstszy błąd wdrożeniowy nie polega na wyborze „złego” skanera. Polega na uruchomieniu wszystkich skanerów jednocześnie, bez właścicieli, zasad triage i uzgodnionych progów blokowania. Zespół dostaje tysiące alertów, przestaje ufać wynikom i po kilku tygodniach omija kontrolę. Poniżej pokazujemy, co wykrywa każda metoda i jak zbudować program etapami.

SAST vs DAST vs IAST — porównanie

Cecha	SAST	DAST	IAST
Analizowany obiekt	Kod źródłowy, bytecode lub binaria	Działająca aplikacja	Działająca aplikacja z instrumentacją
Perspektywa	White box	Black box	Inside-out podczas wykonania
Etap	Kodowanie i pull request	Test, staging, okresowo produkcja	Testy integracyjne i QA
Potrzebny kod	Tak lub artefakt	Nie	Zwykle agent/runtime
Lokalizacja błędu	Zwykle dokładna linia i przepływ	Endpoint i zachowanie	Endpoint plus ścieżka w kodzie
Mocne strony	Wczesne wykrycie, szeroka analiza kodu	Realne zachowanie i konfiguracja runtime	Kontekst wykonania i mniejszy szum
Typowe ślepe pola	Logika runtime, konfiguracja, wdrożenie	Nieosiągnięty kod, dokładna przyczyna	Kod niewykonany w testach
Ryzyko false positives	Często wyższe	Niższe dla potwierdzonego zachowania	Zwykle niższe, zależne od pokrycia
Integracja	IDE, commit, PR, build	Pipeline po wdrożeniu środowiska	Test runner i agent aplikacyjny

Do tego zestawu dochodzą SCA dla zależności, secret scanning, skan IaC, kontenerów i ręczny pentest. To nie konkurenci, lecz warstwy o różnych danych wejściowych.

Czym jest SAST

Static Application Security Testing analizuje kod bez uruchamiania aplikacji. Proste reguły szukają niebezpiecznych funkcji i wzorców. Bardziej zaawansowane silniki śledzą przepływ danych od źródła kontrolowanego przez użytkownika do niebezpiecznego „sink”, np. zapytania SQL, powłoki systemowej albo HTML.

Największa zaleta SAST to wczesny feedback. Deweloper widzi problem w pull requeście, gdy pamięta zmianę i może tanio ją poprawić. Narzędzie może wskazać linię, wyjaśnić przepływ oraz zaproponować bezpieczny wzorzec.

SAST dobrze wykrywa część injection, hardcoded secrets, niebezpieczne API, błędy kryptograficzne, path traversal i niespójne walidacje. Wynik zależy jednak od języka, frameworka i jakości analizy. Dynamiczne wywołania, metaprogramowanie, generowany kod i niestandardowe abstrakcje ograniczają widoczność.

Analiza statyczna nie widzi rzeczywistej konfiguracji reverse proxy, WAF, chmury ani nagłówków. Może oznaczyć potencjalną ścieżkę, która w praktyce jest nieosiągalna, albo pominąć błąd autoryzacji wynikający z relacji kilku usług. Dlatego alert wymaga triage, nie automatycznego przypisania CVSS.

Czym jest DAST

Dynamic Application Security Testing wysyła żądania do działającej aplikacji i analizuje odpowiedzi. Patrzy jak zewnętrzny napastnik, bez konieczności dostępu do kodu. Może wykryć podatność faktycznie osiągalną przez HTTP, niebezpieczną konfigurację, brak nagłówków, część XSS, SQL injection, SSRF i problemów sesji.

DAST testuje również warstwę wdrożenia: serwer, framework, gateway, TLS i zachowanie błędów. Jest przydatny dla aplikacji dostawców, których kodu nie posiadamy.

Największe ograniczenie to pokrycie. Skaner zobaczy tylko endpointy i stany, do których dotrze. Bez kont, crawlingu, dokumentacji i danych testowych może ominąć większość aplikacji. Nowoczesny SPA, GraphQL, wieloetapowy workflow i funkcje za rolami wymagają konfiguracji lub nagrania sekwencji.

DAST zwykle wskazuje URL oraz payload, ale nie zawsze dokładną linię kodu. Naprawa może wymagać ręcznego odtworzenia przepływu. Testy destrukcyjne i duże obciążenie powinny być ograniczone na produkcji.

Czym jest IAST

Interactive Application Security Testing łączy testy działającej aplikacji z agentem lub instrumentacją wewnątrz runtime. Gdy test integracyjny wysyła dane, IAST obserwuje, jak przechodzą przez kod, biblioteki, bazę i system plików.

Dzięki temu może potwierdzić, że parametr rzeczywiście dotarł do zapytania SQL bez właściwej parametryzacji, oraz wskazać dokładną ścieżkę. Ogranicza część false positives SAST i daje więcej kontekstu niż DAST.

IAST widzi jednak tylko kod wykonany podczas testów. Słabe pokrycie QA oznacza słabe pokrycie bezpieczeństwa. Agent zwiększa złożoność środowiska, może wpływać na wydajność i nie obsługuje jednakowo wszystkich języków. Wymaga też zaufania do komponentu działającego wewnątrz aplikacji.

Nie należy mylić IAST z RASP. IAST służy głównie do wykrywania podczas testów, a Runtime Application Self-Protection próbuje blokować ataki w produkcji. Produkcyjna ochrona nie powinna zastępować naprawy kodu.

Gdzie SCA, skan sekretów i IaC pasują do układanki

SAST analizuje kod własny, ale większość aplikacji składa się również z bibliotek open source. Software Composition Analysis identyfikuje komponenty, licencje i znane CVE. Nie powie automatycznie, czy podatna funkcja jest osiągalna, dlatego warto łączyć SBOM, reachability i VEX.

Secret scanning wyszukuje hasła, tokeny i klucze. Powinien działać przed commitem, w repozytorium i artefaktach. Samo usunięcie sekretu z bieżącej wersji nie wystarcza — trzeba go unieważnić i sprawdzić historię.

Infrastructure as Code scanning analizuje Terraform, Kubernetes, CloudFormation i polityki. Wykrywa publiczne buckety, szeroki IAM, brak szyfrowania i niebezpieczne workloady, których SAST aplikacji może nie rozumieć.

Te narzędzia wspierają DevSecOps, ale każdy typ wyników powinien mieć osobny workflow i właściciela.

Co wykrywa która metoda — przykłady

SQL injection. SAST może wykryć konkatenację danych w zapytaniu. DAST potwierdzi injection przez endpoint. IAST połączy payload z linią i użytym driverem. Manualny tester sprawdzi warianty oraz wpływ.

BOLA w API. SAST czasem zauważy brak filtra właściciela, ale złożona autoryzacja utrudnia analizę. DAST z jedną sesją zwykle nie rozpozna problemu. Manualny pentest API porówna dwa konta i tenanty.

XSS. SAST śledzi dane do HTML, DAST wysyła payload i obserwuje wykonanie, IAST pokazuje ścieżkę renderowania. DOM XSS w rozbudowanym froncie może wymagać specjalnego narzędzia lub manualnej analizy.

Hardcoded secret. SAST lub secret scanning znajdzie ciąg w repo. DAST może nigdy go nie zobaczyć. Po wykryciu trzeba dokonać rotacji, bo repozytorium i artefakty mogły już zostać skopiowane.

Błąd logiki płatności. Narzędzia mogą nie zrozumieć, że refund przekracza wpłatę albo kupon działa po zamknięciu zamówienia. Potrzebne są modelowanie zagrożeń, testy biznesowe i pentest manualny.

Błędny nagłówek CSP. DAST lub skan konfiguracji zobaczy stan wdrożenia. SAST może jedynie sprawdzić fragment konfiguracji, jeśli znajduje się w repo.

Kiedy blokować pipeline

Blokowanie każdego alertu od pierwszego dnia tworzy kolejkę, którą zespoły zaczną omijać. Próg powinien zależeć od pewności, nowości i wpływu.

Dobry start:

blokuj nowe, wysokiej pewności sekrety;
blokuj nowe krytyczne CVE w zależności osiągalnej w produkcji, jeśli istnieje poprawka;
blokuj wysokiej pewności SAST w zmienionym kodzie dla krytycznych kategorii;
blokuj potwierdzone DAST/IAST w endpointach produkcyjnych;
nie blokuj automatycznie całego backlogu historycznego;
pozwól na czasowe wyjątki z właścicielem, uzasadnieniem i datą wygaśnięcia.

„Nowe problemy” są łatwiejszym i skuteczniejszym pierwszym celem niż naprawa tysięcy starych alertów. Backlog należy priorytetyzować osobno według osiągalności, ekspozycji i wartości aktywa.

Plan wdrożenia na 90 dni

Dni 1–30: widoczność bez blokad

Wybierz jeden reprezentatywny projekt, zintegruj SCA, secret scanning i lekkie SAST. Zmierz czas skanu, liczbę wyników, precision po triage i najczęstsze przyczyny. Wyznacz właścicieli AppSec i deweloperskich championów.

Nie włączaj jeszcze globalnego fail build. Najpierw usuń reguły niedopasowane do frameworka, dodaj baseline i ustal format zgłoszenia. NIST SSDF zaleca integrowanie bezpiecznych praktyk w istniejący SDLC, a nie tworzenie równoległego procesu bez właścicieli.

Dni 31–60: feedback w pull requestach

Włącz komentarze dla nowego kodu i blokowanie bardzo wysokiej pewności. Dodaj DAST na stabilnym stagingu, z kontami oraz ograniczonym crawlingiem. Testy powinny tworzyć własne dane i je sprzątać.

Zmapuj wyniki do CWE i właścicieli komponentów. Dodaj instrukcje naprawy specyficzne dla stosu. Sam link do ogólnej definicji nie pomaga programiście w napiętym sprincie.

Dni 61–90: coverage i mierniki

Rozszerz skanowanie na kolejne repozytoria według ryzyka. Rozważ IAST tam, gdzie testy integracyjne mają dobre pokrycie. Dodaj skan IaC i kontenerów. Ustal SLA według ekspozycji, nie tylko CVSS.

Mierz: odsetek projektów objętych kontrolą, czas do triage, precision, medianę naprawy, liczbę wyjątków i powracające klasy błędów. Liczba „znalezionych podatności” bez kontekstu może rosnąć mimo poprawy bezpieczeństwa.

Jak zmniejszyć false positives

Po pierwsze, skanuj zmianę i pokaż przepływ, nie tylko nazwę reguły. Po drugie, dostosuj źródła oraz sinki do własnych frameworków. Po trzecie, połącz wynik z kontekstem: czy endpoint jest publiczny, czy dane są kontrolowane, czy biblioteka trafia do artefaktu.

Triage powinien kończyć się jednym z jasno zdefiniowanych statusów: potwierdzone, nieosiągalne, akceptacja ryzyka, duplikat albo błąd narzędzia. Każda suppressja musi mieć powód i scope. Globalne wyłączenie reguły po jednym false positive jest równie złe jak ignorowanie wszystkich alertów.

Warto tworzyć test regresyjny dla naprawionej klasy. Jeśli zespół ciągle wprowadza ten sam problem, potrzebuje bezpiecznego komponentu lub zmiany architektury, nie tylko kolejnych ticketów.

Dlaczego narzędzia nie zastępują pentestu

SAST, DAST i IAST działają w przewidywalnych ramach. Manualny tester łączy informacje, zmienia role, omija workflow, analizuje race condition i modeluje przeciwnika. Może również sprawdzić, czy kilka średnich słabości razem daje krytyczny skutek.

Automatyzacja działa ciągle i szybko, więc wykrywa regresje między pentestami. Pentest dostarcza głębi i kontekstu. Dojrzały program korzysta z obu. Artykuł test penetracyjny, audyt czy skan wyjaśnia różnicę celów.

Najczęstsze pytania

Od czego zacząć: SAST czy DAST? Jeśli rozwijasz kod, zacznij od secret scanning, SCA i lekkiego SAST w PR. DAST dodaj na stabilnym stagingu. W aplikacji bez kodu źródłowego DAST może być pierwszym dostępnym narzędziem.

Czy IAST zastępuje SAST i DAST? Nie. Daje świetny kontekst dla wykonanego kodu, ale nie widzi ścieżek, których nie pokrywają testy. SAST może przeanalizować więcej kodu, a DAST ocenia zachowanie bez agenta.

Czy skaner powinien blokować każde high CVSS? Nie automatycznie. Potrzebne są pewność, osiągalność, ekspozycja, wpływ i informacja o poprawce. Nowy, potwierdzony problem w publicznym endpointcie ma inny priorytet niż nieużywana funkcja testowa.

Jak często uruchamiać skany? Szybkie kontrole przy każdym PR, cięższe w buildzie nocnym lub po wdrożeniu stagingu. Pełny DAST musi mieć stabilne środowisko i dane. Częstotliwość nie naprawi złej konfiguracji narzędzia.

Kto powinien robić triage? AppSec wspólnie z właścicielem kodu. Zespół bezpieczeństwa zna klasę ryzyka, a deweloper kontekst aplikacji. Przerzucenie wszystkich alertów przez ścianę nie działa.

Podsumowanie

SAST analizuje kod wcześnie, DAST testuje działającą aplikację od zewnątrz, a IAST obserwuje wykonane ścieżki od środka. SCA, secret scanning i IaC uzupełniają obraz. Najlepsza kombinacja zależy od stosu, etapu SDLC i jakości testów.

Nie zaczynaj od zakupu trzech platform. Zacznij od pilota, baseline, właścicieli i mierników. Blokuj nowe problemy wysokiej pewności, systematycznie redukuj backlog i zachowaj manualne testy dla logiki oraz autoryzacji. Jeśli potrzebujesz ocenić obecny pipeline, porozmawiajmy o przeglądzie DevSecOps.

Źródła i dalsza lektura: NIST SP 800-218 — Secure Software Development Framework, OWASP Web Security Testing Guide, OWASP ASVS, OWASP API Security.