Bezpieczny cykl wytwarzania oprogramowania, SAST i DAST

Bezpieczny cykl życia oprogramowania (SSDLC) integruje działania związane z bezpieczeństwem z każdą fazą tworzenia oprogramowania — od wymagań, przez projektowanie, programowanie, testowanie i wdrażanie, po utrzymanie. Tradycyjny SDLC traktuje bezpieczeństwo jako kontrolę na końcowym etapie, co jest kosztowne i nieskuteczne. Filozofia bezpiecznego SDLC zakłada wykrywanie i usuwanie luk tak wcześnie, jak to możliwe, ponieważ usterki wykryte podczas projektowania kosztują znacznie mniej niż te znalezione w środowisku produkcyjnym.

Shift left oznacza przeniesienie działań związanych z bezpieczeństwem na wcześniejszy etap procesu tworzenia oprogramowania (w lewo na osi czasu), zamiast dodawania ich na końcu. W praktyce oznacza to uwzględnianie wymagań bezpieczeństwa w historyjkach użytkownika, przeprowadzanie modelowania zagrożeń podczas projektowania, wykonywanie przeglądów kodu i analiz SAST w trakcie programowania oraz uruchamianie DAST przed wydaniem. Zespoły stosujące podejście shift left wykrywają luki wtedy, gdy ich usunięcie jest najtańsze — podczas programowania, a nie w środowisku produkcyjnym.

Modelowanie zagrożeń polega na systematycznym identyfikowaniu i dokumentowaniu zagrożeń bezpieczeństwa podczas fazy projektowania. Model STRIDE dzieli zagrożenia na: podszywanie się, manipulowanie, zaprzeczalność, ujawnienie informacji, odmowę usługi oraz podniesienie uprawnień. PASTA (Process for Attack Simulation and Threat Analysis) to metodologia skoncentrowana na ryzyku, która symuluje cele osoby atakującej. Modele zagrożeń pozwalają ustalić priorytety działań ograniczających ryzyko, zanim zostanie napisana choćby jedna linia kodu.

SAST (testowanie typu white-box) analizuje kod źródłowy, kod bajtowy lub pliki binarne bez uruchamiania aplikacji, wyszukując wzorce programistyczne powiązane ze znanymi lukami. Narzędzia SAST mogą szybko przeskanować całą bazę kodu i zgłaszać problemy, takie jak zakodowane na stałe dane uwierzytelniające, miejsca podatne na SQL injection oraz niebezpieczna deserializacja. Działają w środowisku IDE lub w potoku CI i wskazują plik oraz numer wiersza, co ułatwia usunięcie problemu.

Jednym z kluczowych ograniczeń SAST jest skłonność do generowania fałszywych alarmów — oznaczania kodu jako podatnego, mimo że w rzeczywistości jest bezpieczny. Zmęczenie nadmiarem alertów powoduje, że programiści odrzucają wyniki bez ich sprawdzenia. Narzędzia SAST nie potrafią także wykrywać problemów z konfiguracją środowiska uruchomieniowego, błędów uwierzytelniania zależnych od działania w czasie wykonywania ani luk w wywołaniach zewnętrznych interfejsów API. SAST jest najbardziej skuteczny w połączeniu ze szkoleniem programistów, dzięki któremu wyniki są prawidłowo analizowane i ustalane są dla nich priorytety.

DAST (testowanie typu black-box) testuje uruchomioną aplikację, wysyłając ładunki ataku do jej punktów końcowych HTTP i analizując odpowiedzi pod kątem oznak podatności. DAST nie wymaga dostępu do kodu źródłowego — testuje aplikację tak, jak zrobiłaby to osoba atakująca. Doskonale wykrywa problemy występujące w czasie wykonywania, takie jak obejście uwierzytelniania, XSS odzwierciedlane w odpowiedziach oraz błędna konfiguracja serwera. Do narzędzi DAST należą OWASP ZAP, Burp Suite i Netsparker.

SAST i DAST wzajemnie się uzupełniają, a nie konkurują ze sobą. SAST wcześnie wykrywa problemy na poziomie kodu i integruje się z IDE, ale nie ma wglądu w działanie aplikacji w czasie wykonywania. DAST wykrywa luki występujące w czasie wykonywania i nie wymaga kodu źródłowego, ale nie może przeskanować ścieżek kodu, które nie zostaną uruchomione przez jego automatyczne sondy. Jednoczesne stosowanie obu podejść — SAST w potoku CI i DAST wobec środowiska testowego — maksymalizuje pokrycie luk w całym cyklu SDLC.

IAST łączy elementy SAST i DAST, instrumentując aplikację w czasie wykonywania. Agent IAST działa wewnątrz aplikacji (na serwerze) i obserwuje wykonywanie kodu, gdy przez aplikację przepływa ruch testowy. Może śledzić skażone dane wejściowe użytkownika przez ścieżki kodu aż do wrażliwych miejsc docelowych, wykrywając luki przy mniejszej liczbie fałszywych alarmów niż czysty SAST. IAST jest szczególnie skuteczny w aplikacjach Java i .NET oraz naturalnie integruje się z uruchamianiem testów funkcjonalnych.

Analiza składu oprogramowania (SCA) identyfikuje biblioteki open source i zależności zewnętrzne w aplikacji oraz porównuje je z bazami danych luk (NVD, OSV). Ponieważ współczesne aplikacje mogą korzystać z setek zależności — z których wiele jest dodawanych tranzytywnie — narzędzia SCA, takie jak OWASP Dependency-Check, Snyk i Renovate, są niezbędne do wykrywania znanych CVE, zanim osoby atakujące wykorzystają je w łańcuchu dostaw.

Integracja narzędzi bezpieczeństwa z potokami CI/CD gwarantuje, że żaden kod nie trafi do środowiska produkcyjnego bez przejścia kontroli bezpieczeństwa. Typowy potok DevSecOps uruchamia: SAST przy każdym zatwierdzeniu zmian, SCA po zmianach zależności, skanowanie obrazów kontenerów przed przesłaniem ich do rejestru, skanowanie IaC dla Terraform/CloudFormation oraz DAST wobec wdrożenia w środowisku testowym. Niespełnienie kontroli bezpieczeństwa blokuje kompilację, wzmacniając kulturę bezpieczeństwa domyślnego.

Narzędzia automatyczne nie mogą zastąpić prowadzonego przez człowieka przeglądu kodu skoncentrowanego na logice bezpieczeństwa. Przegląd wykonywany przez współpracowników powinien potwierdzać, że: kontrole uwierzytelniania i autoryzacji znajdują się we właściwych miejscach, obsługa błędów nie ujawnia poufnych informacji, funkcje kryptograficzne używają zatwierdzonych algorytmów i parametrów, a logiki biznesowej nie można obejść. Security champions w zespołach programistycznych — programiści przeszkoleni w zakresie bezpieczeństwa — wypełniają lukę między zespołem bezpieczeństwa a zespołem inżynieryjnym.

Sprawdź swoją znajomość zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.

W tej lekcji dowiedział się Pan / dowiedziała się Pani, że: bezpieczny cykl SDLC integruje bezpieczeństwo ze wszystkimi fazami tworzenia oprogramowania, zamiast dodawać je na końcu, SAST analizuje kod bez jego wykonywania, a DAST testuje uruchomione aplikacje, a SCA identyfikuje podatne zależności open source, natomiast kontrole bezpieczeństwa CI/CD automatycznie egzekwują wymagania. Następnie omówimy usługi katalogowe LDAP i Active Directory.