SAST vs SCA

Różnice w skrócie

	SAST	SCA
Rozwinięcie	Statyczne testowanie bezpieczeństwa aplikacji (static application security testing)	Analiza składu oprogramowania (software composition analysis)
Analizuje	Państwa własny kod źródłowy	Komponenty open source i zewnętrzne
Znajduje	Wstrzyknięcia, niebezpieczną obsługę danych wejściowych, niebezpieczne wzorce	Znane podatności, problemy licencyjne, przestarzałe pakiety
Opiera się na	Regułach lub modelach tego, jak wygląda zły kod	Bazach opublikowanych biuletynów
Znalezisko pojawia się, gdy	Zmienia się Państwa kod	Zmienia się zależność lub zostaje opublikowany nowy biuletyn
Typowy szum	Fałszywe alarmy dotyczące kodu, który w rzeczywistości jest bezpieczny	Prawdziwe dopasowania, które nie mają znaczenia przy Państwa sposobie użycia pakietu
Poprawka	Zmiana własnego kodu	Aktualizacja lub wymiana komponentu

Co robi SAST

Narzędzie SAST odczytuje kod źródłowy bez jego uruchamiania i śledzi przepływ danych. Jeśli dane od użytkownika docierają do zapytania do bazy danych bez sanityzacji, zgłasza plik i wiersz. Ponieważ działa na Państwa kodzie, może znaleźć błędy, których nikt nigdy nie opublikował. Jest też źródłem narzekań na fałszywe alarmy, ponieważ rozważa, co kod mógłby zrobić, a nie co faktycznie robi.

Co robi SCA

Skan SCA identyfikuje komponenty projektu i wyszukuje je w danych o podatnościach i licencjach. Nie analizuje Państwa logiki. Wie, że dana wersja ma opublikowany błąd, więc jego wyniki są zwykle oparte na faktach, ale mówi mniej o tym, czy ten błąd ma dla Państwa znaczenie, chyba że narzędzie dodaje analizę osiągalności. Pełny obraz przedstawia strona czym jest analiza składu oprogramowania.

Dlaczego potrzebne są oba

Te dwa rodzaje błędów są niezależne. Kod bez żadnych znalezisk SAST nadal może dostarczyć podatną zależność, a czyste drzewo zależności nie mówi nic o wstrzyknięciu SQL we własnym handlerze.

Różni się też moment. Znalezisko SAST pojawia się, gdy ktoś zmienia kod, więc większość z nich wychwytuje kontrola w pull requeście. Znalezisko SCA może się pojawić dla wydania dostarczonego kilka miesięcy temu, w dniu publikacji nowego biuletynu, bez żadnego commita, który cokolwiek by uruchomił. Dlatego SCA potrzebuje czegoś, co nadal sprawdza to, co zostało dostarczone.

Miejsce DAST

Dynamiczne testowanie bezpieczeństwa aplikacji (dynamic application security testing) atakuje działającą aplikację z zewnątrz, tak jak zrobiłby to prawdziwy napastnik. Znajduje to, co ujawnia się dopiero w czasie działania, na przykład problemy z uwierzytelnianiem i konfiguracją, bez czytania kodu.

	SAST	SCA	DAST
Potrzebuje	Kodu źródłowego	Manifestów, obrazów lub zapisu buildu	Działającej aplikacji
Działa	Przy pull requestach	Przy pull requestach, w buildach i po wydaniu	W środowisku testowym
Najlepsze do	Błędów w Państwa kodzie	Znanych zagrożeń w zależnościach	Błędów czasu działania i konfiguracji

Od czego zacząć?

W większości zespołów od SCA. Szybko się je konfiguruje, działa od kilku sekund do kilku minut i obejmuje największą część tego, co Państwo dostarczają, ponieważ współczesna aplikacja to w większości zależności. Następnie warto dodać SAST przy pull requestach i dostroić je do reguł istotnych dla Państwa stosu technologicznego. DAST warto dodać, gdy będą Państwo mieli stabilne środowisko testowe.

Jedna platforma czy kilka narzędzi?

Platformy takie jak Snyk, Checkmarx i GitHub Advanced Security łączą SAST i SCA, co oznacza jedną umowę i jeden workflow. Osobne narzędzia mogą być mocniejsze w swoich obszarach. Ważniejsze są jednak dane wejściowe: oba rodzaje skanerów pracują na tym, co zadeklarowane lub napisane, i żaden nie widzi tego, co build faktycznie pobrał.

Czego nie obejmuje żadne z nich

SAST i SCA odczytują pliki. Żadne z nich nie obserwuje buildu, więc kod pobierany przez hook instalacyjny, pakiety przywrócone z cache CI i same narzędzia buildu mogą pozostać niewidoczne. Właśnie tej luki dotyczy bezpieczeństwo łańcucha dostaw oprogramowania.

CRACI obejmuje tę część, a skanowanie kodu pozostawia narzędziom stworzonym do tego celu. Celowo nie wykonuje SAST ani skanowania sekretów, a obok niego działa wiele doskonałych narzędzi SAST. To runner GitHub Actions, który zapisuje w SBOM to, co pobiera każde zadanie, i nadal sprawdza SBOM-y dostarczonego oprogramowania względem nowych podatności. Zob. najlepsze narzędzia SCA i miejsce CRACI obok nich.

SAST vs SCA: najczęściej zadawane pytania

Jaka jest różnica między SAST a SCA?

SAST analizuje kod pisany przez Państwa zespół pod kątem błędów takich jak wstrzyknięcia. SCA analizuje komponenty open source i zewnętrzne, od których Państwo zależą, pod kątem znanych podatności i problemów licencyjnych.

Czy SCA zastępuje SAST?

Nie. Analizują inny kod. SCA nie znajdzie błędu w Państwa własnej logice, a SAST nie powie, że zależność ma opublikowaną podatność.

Jaka jest różnica między SAST, DAST i SCA?

SAST odczytuje kod źródłowy. SCA sprawdza zależności. DAST testuje działającą aplikację z zewnątrz. Każde z nich znajduje problemy, których dwa pozostałe nie widzą.

Czy Snyk to SAST czy SCA?

Jedno i drugie. Snyk zaczynał od skanowania zależności open source, a dziś oferuje też SAST oraz skanowanie kontenerów i infrastruktury jako kodu.

Czy SonarQube to SAST czy SCA?

SonarQube jest znany przede wszystkim ze statycznej analizy własnego kodu, czyli SAST. Co jeszcze zawierają poszczególne edycje, warto sprawdzić w ich aktualnej ofercie.

Co najpierw, SAST czy SCA?

SCA to zwykle szybszy zysk, ponieważ łatwo je skonfigurować i obejmuje największą część tego, co Państwo dostarczają. SAST wymaga więcej dostrajania, aby ograniczyć fałszywe alarmy.