Testy penetracyjne a statyczna analiza kodu – co wybrać?

Od dawna naturalną strategią zapewnienia bezpieczeństwa aplikacji są testy penetracyjne. Ciągły rozwój różnych technik ataków ujawnia jednak niedomagania takiego podejścia. Coraz większą akceptację w środowiskach związanych z bezpieczeństwem aplikacji zdobywa podejście mówiące o konieczności adresowania kwestii bezpieczeństwa u źródła, czyli w kodzie aplikacji. Statyczna analiza kodu zaczyna być postrzegana jako atrakcyjna alternatywa wykrywania podatności bezpieczeństwa już na poziomie kodu źródłowego aplikacji.

Czym są testy penetracyjne?

Testy penetracyjne są metodyką łączącą podejście manualne z automatycznym. Jak sama nazwa sugeruje esencją tego rodzaju testów są próby ataku na aplikację przez ekspertów z dziedziny bezpieczeństwa z wykorzystaniem wiedzy eksperckiej, gotowych exploitów oraz zestawu narzędzi automatycznie testujących istnienie znanych podatności. Wyniki tych prób ataku są następnie przekazywane organizacji zlecającej testy i docelowo trafiają do zespołów deweloperskich w celu wyeliminowania podatności.

Takie podejście daje zazwyczaj bardzo dobre rezultaty i identyfikuje wiele luk bezpieczeństwa jednak zawsze jest obarczone ryzykiem niekompletności. Nawet najlepsi eksperci wspomagając się narzędziami do automatyzacji swojej pracy mogą nie wykryć wszystkich podatności. Istotnym ograniczeniem jest również czas. Czas pracy specjalisty jest bezpośrednio związany z kosztem testów i zawsze jest ograniczony. Ograniczony jest też czas przewidziany w projekcie na testy, każdy projekt ma deadline’y. Te ograniczenia powodują, że nie da się w pełni zasymulować działań i strategii potencjalnych ataków.

Testy penetracyjne zazwyczaj realizowane są na podstawie gotowych, predefiniowanych list znanych zagrożeń czy exploitów. Często bazy te są niekompletne i nieaktualne i nie obejmują wszystkich zagrożeń. Przygotowanie kompleksowego planu testów adekwatnego do sytuacji jest zazwyczaj zbyt kosztowne i czasochłonne. To kolejne duże ograniczenie podejścia opierającego się wyłącznie na testach penetracyjnych.

Analiza statyczna z wykorzystaniem SAST (Static Application Security Testing)

SAST to zupełnie inne podejście do testów bezpieczeństwa. Polega ono na analizie kodu źródłowego, bytecode’u lub postaci binarnej. W ramach SAST, do którego należy też SCA (Static Code Analysis) nie czeka się z testami na gotową, uruchomioną aplikację i testowanie aspektów bezpieczeństwa rozpoczyna się na bardzo wczesnym etapie, kiedy zaczyna powstawać kod. Podatności bezpieczeństwa wykrywane są jeszcze przed zbudowaniem aplikacji. To kluczowa różnica pomiędzy SAST i testami penetracyjnymi.

Organizacje wykorzystujące SAST zapewniają sobie bezpieczeństwo na poziomie samego procesu wytwórczego tworząc sSDLC (secure Software Development Life Cycle) i w sam proces wytwórczy wbudowują elementy związane z testami bezpieczeństwa. Rozwiązania SAST mogą być integrowane z pipeline’ami CI/CD, narzędziami do śledzenia zgłoszeń oraz z IDE programistów. Taki ekosystem powoduje, że testy bezpieczeństwa odbywają się na bieżąco a nie tylko w ramach jednego z końcowych etapów projektu.

Testy typu White Box, którymi są testy realizowane z wykorzystaniem SAST pozwalają osiągnąć wysoką skuteczność wykrywania podatności bezpieczeństwa we wszystkich warstwach aplikacji, nie tylko tych ewidentnie wyeksponowanych na potencjalne ataki. Dobrze wdrożone i skonfigurowane narzędzia pozwalają też osiągnąć niski poziom fałszywych alarmów, czyli zgłoszeń których obsługa konsumuje nasze zasoby, a które ostatecznie okazują się nie być prawdziwymi zagrożeniami bezpieczeństwa.

Analiza statyczna a testy penetracyjne: 7 powodów by wybrać SAST/SCA

1 – Zwrot z inwestycji (ROI)

Testy penetracyjne to przedsięwzięcie, które zazwyczaj trzeba cyklicznie powtarzać by zapewnić oczekiwany poziom bezpieczeństwa aplikacji. Każdy przebieg testów penetracyjnych to dodatkowe koszty. Testy penetracyjne wykonywane są dopiero kiedy aplikacja jest albo wydaje się być gotowa do wdrożenia produkcyjnego. Jeśli testy wykażą podatności, to musimy zaplanować ich usunięcie i powtórzyć testy. To zajmuje cenny czas, w którym aplikacja mogłaby już przynosić nam korzyści.

Pomimo tego, że testy penetracyjne są dobrym narzędziem do podniesienia poziomu bezpieczeństwa aplikacji a w niektórych sektorach są wręcz narzucone regulacjami, to poleganie wyłącznie na nich może mieć poważne konsekwencje zarówno techniczne jak i finansowe. Włączenie SAST do strategii zapewnienia bezpieczeństwa daje korzyści finansowe między innymi dzięki temu, że podatności wykrywane są bardzo wcześnie, dzięki czemu ich wyeliminowanie jest łatwe i tanie.

Dzięki SAST można uniknąć nieprzewidzianych, czasem wielokrotnych powtórek cyklu testowania, poprawek i retestów. Takie nieprzewidziane cykle to nie tylko dodatkowy koszt samych retestów, ale także utracone korzyści i często wymierne straty spowodowane opóźnieniami we wdrożeniu produkcyjnym aplikacji.

2 – Oszczędność czasu pracowników

Testy penetracyjne zazwyczaj wykonywane są przez specjalistów spoza organizacji. Finalnym produktem ich pracy jest raport opisujący odkryte podatności. Podatności te następnie zespół wytwórczy musi zrozumieć, zidentyfikować ich źródło w kodzie aplikacji i wprowadzić zmiany potrzebne do wyeliminowania zagrożenia. Niejednokrotnie okazuje się to mozolnym i czasochłonnym zadaniem zajmującym czas programistów.

Wykorzystując SAST drastycznie redukujemy czas programisty potrzebny do wykonania poprawki. Błąd identyfikowany jest bezpośrednio w kodzie, nie trzeba go szukać. Defekty wykrywane są na najwcześniejszym możliwym etapie, co skutkuje redukcją koszów ich usunięcia. Skanowanie kodu automatycznie wykonywane na bieżąco podczas tworzenia kodu aplikacji powoduje, że nasz cykl wytwórczy jest zorientowany na bezpieczeństwo i realizujemy w ten sposób proces sSDLC (secure Software Develompent Life Cycle).

3 – Krótsze czasy wprowadzania poprawek

Rozwiązania SAST wskazują podatność w kodzie źródłowym, ale dodatkowo mogą zasugerować optymalne miejsce wprowadzenia poprawki. Dzięki temu często za pomocą jednej zmiany w kodzie można wyeliminować dziesiątki podatności, które bez takiej sugestii mniej doświadczony zespół mógłby adresować niezależnie. Testy penetracyjne nie oferują takich możliwości.

Od napisania kodu przez programistę do otrzymania raportu z testów penetracyjnych mogą minąć tygodnie a nawet miesiące. Nawet jeśli poprawkę będzie przygotowywał autor oryginalnego kodu, to często musi ten kod ponownie przeczytać, przeanalizować i zrozumieć. Jeśli poprawkę ma przygotować inny programista to proces ten może się istotnie wydłużyć.

Dzięki SAST wyniki testów trafiają do programisty na bieżąco, poprawki może przygotować autor kodu nie musząc go sobie przypominać.

4 – Lepsza trafność

Testy penetracyjne mogą nie wykrywać wszystkich podatności ze względu na stare lub niekompletne listy podatności z których korzystają podczas gdy większość narzędzi SAST aktualizuje swoje bazy automatycznie. Nieaktualne bazy podatności mogą też generować fałszywe alarmy i skutkować wskazywaniem podatności, które nigdy się nie zmaterializują. Bez analizy kodu źródłowego nie można też wykryć podatności manifestujących się tylko w pewnych warunkach lub w określonym czasie. Przykładem może być pozostawiony w kodzie backdoor aktywny tylko przez minutę w ciągu doby albo tyko jednego dnia w miesiącu.

Niektóre narzędzia SAST pozwalają na zaawansowaną konfigurację i dostrojenie reguł używanych przez narzędzia skanujące do konkretnego przypadku. Pozwala to z jednej strony implementować własne, specyficzne reguły bezpieczeństwa i weryfikować je na bieżąco podczas skanowania a z drugiej strony praktycznie wyeliminować fałszywe alarmy, których obsługa też kosztuje.

5 – Wartość edukacyjna dla programistów

Dzięki integracji z IDE, prostocie i gotowym wskazówkom SAST pozwala zaangażować w proces usuwania podatności wszystkich programistów, także tych mniej doświadczonych. Takie zaangażowanie podnosi świadomość programistów w kwestiach bezpieczeństwa i wytwarza nawyki tworzenia bezpiecznego kodu. Testy penetracyjne nie mają takiego waloru edukacyjnego.

6 – Integracja z narzędziami i procesem wytwórczym

SAST doskonale wpisuje się w sam proces wytwarzania oprogramowania. Pluginy do IDE pozwalają na szybkie i łatwe eliminowanie podatności co oszczędza czas programistów i specjalistów do spraw bezpieczeństwa. Integracja z pipeline’ami CI/CD pozwala na takie ustawienie procesu wytwórczego, że potencjalne podatności bezpieczeństwa nie trafiają nawet na środowisko testowe, bo blokowane są commity z niebezpiecznym kodem.

Poleganie wyłącznie na testach penetracyjnych, które rozpoczynają się dopiero po uruchomieniu gotowej aplikacji może prowadzić do nieprzewidzianych opóźnień w produkcyjnym uruchomieniu aplikacji lub jej nowej wersji.

7 – Funkcjonalność QA

Testy penetracyjne koncentrują się tyko na wykrywaniu podatności bezpieczeństwa podczas gdy SAST oferuje znacznie więcej. Dzięki analizie kodu źródłowego aplikacji możliwa jest identyfikacja martwego, czyli nieużywanego kodu czy nawet błędów logicznych w samej aplikacji i są to funkcjonalności jakich testy penetracyjne nie dostarczą.

Analiza statyczna czy testy penetracyjne?

Czy znając niewątpliwe zalety podejścia SAST powinniśmy zrezygnować z testów penetracyjnych i zastąpić je statyczną analizą kodu? Nie! Testy penetracyjne są bardzo dobrą metodą zapewnienia bezpieczeństwa aplikacji i są podatności związane z infrastrukturą czy konfiguracją serwerów, które nie mają źródła w kodzie aplikacji.

Testy penetracyjne mają swój sens i zalety, są często wymagane przez zewnętrzne regulacje i wewnętrzne procedury. Mają jednak swoje ograniczenia i organizacje, w których wytwarzanie bezpiecznego oprogramowania jest priorytetem coraz częściej decydują się na włączenie testów SAST w swoje procesy wytwórcze.

SAST pozwala zredukować koszty usuwania podatności bezpieczeństwa, pomaga budować i utrwalać dobre praktyki tworzenia bezpiecznego kodu w zespołach dzięki walorom edukacyjnym. Zastosowanie statycznej analizy kodu zabezpiecza przed ryzykiem nieplanowanych opóźnień w projektach. Same testy penetracyjne mogą być wykonywane rzadziej, bez nieplanowanych powtórek i stają bardziej potwierdzeniem, że nasz bezpieczny proces wytwórczy działa, a nie źródłem bolesnych niespodzianek tuż przed planowanym wdrożeniem.

Chcesz poprawić bezpieczeństwo swojego oprogramowania? Zamów analizę swojego kodu!

Autor: Łukasz Rauer, Technology Consulting Solution Manager w Altkom Software