Secure Software Development Lifecycle (SSDLC), czyli cykl rozwoju bezpiecznego oprogramowania

Wprowadzenie

Bezpieczeństwo aplikacji jest jednym z najbardziej krytycznych elementów w dzisiejszym, szybko rozwijającym się świecie technologii. Błędy w kontekście bezpieczeństwa wiążą się ze stratami finansowymi oraz utratą zaufania klientów. Niemal codziennie słyszymy o poważnych naruszeniach, włamaniach czy atakach na aplikacje i systemy IT, skutkujących kradzieżą lub utratą danych lub przerwami w dostawie usług. Aby się zabezpieczyć i uniknąć luk w bezpieczeństwie, kwestie tego bezpieczeństwa muszą odgrywać istotną rolę w całym procesie powstawania aplikacji. 

Secure Software Development Lifecycle (SSDLC, S-SDLC lub Secure-SDLC), czyli cykl rozwoju bezpiecznego oprogramowania, wprowadza elementy bezpieczeństwa do tradycyjnego procesu tworzenia oprogramowania (Software Development Lifecycle - SDLC). Proces ten obejmuje wszystkie etapy tworzenia oprogramowania, zapewniając kompleksowe podejście do bezpieczeństwa na każdym kroku. Aby zrozumieć, które elementy zabezpieczeń są uwzględniane, najpierw przyjrzyjmy się, jak wygląda tradycyjne podejście SDLC.

Proces SDLC

Software Development Lifecycle (SDLC) to usystematyzowany proces, którego celem jest dostarczenie produktu, jakim jest oprogramowanie (lub w szerszym ujęciu - system IT), w sposób efektywny, ekonomicznie wydajny oraz spełniający oczekiwania klienta i użytkownika końcowego.

Proces ten składa się z kilku etapów:

1. Zbieranie i analiza wymagań - pierwszy etap, którego celem jest pozyskanie niezbędnych informacji dotyczących celu i zakresu projektu oraz wymagań i oczekiwań klienta. To na tym etapie na podstawie rozmów z klientami, użytkownikami końcowymi oraz na podstawie analizy rynku i obecnych rozwiązań określa się główne ramy i założenia projektowe.

2. Projektowanie - na tym etapie określa się, w jaki sposób projekt zostanie zrealizowany. Tworzona jest specyfikacja rozwiązania obejmująca jego architekturę, technologie oraz wymagane zasoby. Rozpisywana jest roadmapa projektu, priorytety zadań, jak również oceniane są ryzyka projektowe. Na bazie przygotowanego projektu określa się sposób jego realizacji.

3. Implementacja - na tym etapie zaczyna się realizacja projektu i na bazie specyfikacji powstaje oprogramowanie. Pisany jest kod źródłowy, tworzona jest infrastruktura, budowany jest ciąg integracji i dostarczania (CI/CD pipeline). Na tym etapie tworzone są również zależności do bibliotek zewnętrznych (3rd party) i budowany jest łańcuch dostaw (supply chain).

4. Testowanie - celem tego etapu jest przede wszystkim weryfikacja, czy oprogramowanie, dostarczane w fazie implementacji, spełnia wymagania biznesowe i projektowe, a przede wszystkim czy spełnia oczekiwania klienta. Testowaniu podlegają także elementy niefunkcjonalne oprogramowania, takie jak wydajność, stabilność czy bezpieczeństwo. 

5. Wdrożenie - na tym etapie gotowe rozwiązanie (lub jego część), po przejściu testów funkcjonalnych i niefunkcjonalnych i, przede wszystkim, po zaakceptowaniu przez klienta, jest wdrażane na środowisku produkcyjnym, by finalnie zostać udostępnionym użytkownikom końcowym.

6. Utrzymanie - to etap zapewniający wsparcie wdrożonego oprogramowania. Na tym etapie dostarczane są aktualizacje, poprawki i rozszerzenia funkcjonalne. 

W zależności od obranej metodologii etapy 3-5 mogą następować kaskadowo, tak że kolejny zaczyna się dopiero po zakończeniu poprzedniego (Waterfall), a pełne rozwiązanie dostarczane jest klientowi dopiero na końcu, po zakończeniu prac. Lub, jak ma to miejsce w przypadku metodyk zwinnych (Agile), gdy poszczególne fragmenty rozwiązania są dostarczane na bieżąco,, w sposób cykliczny, w krótkich iteracjach.

Problemy procesu w kontekście bezpieczeństwa

Głównym celem tradycyjnego procesu SDLC jest zapewnienie, aby produkt spełniał przede wszystkim wymagania funkcjonalne, aby był użyteczny dla użytkownika końcowego oraz aby jego wytworzenie wpisywało się w odpowiednie ramy czasowe i budżetowe. Oczywiście kwestie bezpieczeństwa pojawiają się w tracie procesu, ale ma to miejsce głównie w fazie testowania, kiedy pod uwagę brane są elementy niefunkcjonalne. 

Wynika to niestety z faktu, że często bezpieczeństwo traktowane jest jako dodatek i nie stanowi integralnej części z pozostałymi aspektami projektowanego systemu. Zazwyczaj na pierwszy plan wysuwają się funkcjonalność (functionality) i użyteczność (usability) oraz odpowiednie odnalezienie balansu pomiędzy nimi. Natomiast w zakresie bezpieczeństwa często dla klienta wystarczające będzie stwierdzenie: “no i żeby było bezpiecznie”. W fazie projektowania, w specyfikacji, sprowadza się to do “wprowadzenia standardowych zabezpieczeń” lub “implementacji w zgodzie ze standardami” (cokolwiek te sformułowania znaczą). Zespoły programistyczne, często niewystarczająco przeszkolone w zakresie bezpieczeństwa, skupiają się na dostarczeniu przede wszystkim głównych funkcjonalności, mając napięty grafik i będąc w tradycyjnym niedoczasie, powierzchownie traktując lub w ogóle pomijając kwestie zabezpieczeń. I dopiero w fazie testowania, kiedy testerzy dochodzą do testów bezpieczeństwa, okazuje się, że jest problem. A czasami, w jeszcze gorszym przypadku, podatności wychodzą na jaw dopiero w fazie utrzymania. 

Zbyt późne wykrycie błędów uniemożliwia ich łatwe, skuteczne i tanie naprawienie.

Znana zasada względnego kosztu naprawy błędów [Rys. 1] pokazuje, że ten koszt może wzrosnąć nawet stukrotnie, jeśli błąd nie zostanie w porę zidentyfikowany.

Rys 1. Względny koszt naprawy błędów

Rozwiązanie w postaci SSDLC

SSDLC integruje praktyki związane z bezpieczeństwem na każdym etapie procesu tworzenia oprogramowania, przypisując do każdego z nich specyficzne cele i zadania związane z ochroną aplikacji. Przyjrzyjmy się więc poszczególnym fazom i praktykom, które wprowadza ten bezpieczny odpowiednik tradycyjnego cyklu SDLC:

1. Zbieranie i analiza wymagań - na tym etapie kluczową rolę odgrywa ocena ryzyka (Risk Assessment), która musi uwzględniać zagrożenia związane z cyberbezpieczeństwem. W kontekście biznesowym, mając odpowiednio zdefiniowane ryzyka, można wyspecyfikować wymagania bezpieczeństwa i odpowiednie jego polityki, które muszą być spełnione przez aplikację.

2. Projektowanie - na tym etapie polityki bezpieczeństwa są integrowane z projektem. Wykonuje się modelowanie zagrożeń (Threat Modeling) i na tej podstawie wdraża do projektu odpowiednie techniki przeciwdziałania im, jak np. szyfrowanie danych, kontrola dostępu, zabezpieczenie sieci, itp. Na zakończenie etapu projektowania powinien zostać wykonany przegląd bezpieczeństwa architektury systemu i przygotowanej specyfikacji. 

3. Implementacja - w tej fazie najważniejszą rzeczą w kontekście bezpieczeństwa jest przestrzeganie praktyk bezpiecznego programowania (secure coding). Aspekty bezpieczeństwa muszą być uwzględnione na każdym kroku poświęconym jakości powstającego kodu. Począwszy od wytycznych dot. jakości kodu (coding guidelines), które muszą uwzględniać praktyki bezpieczeństwa, przez przeglądy kodu (code review) w trakcie wprowadzania zmian, uwzględniające identyfikację potencjalnych problemów związanych z bezpieczeństwem, po statyczną analizę kodu - SAST (Static Aplication Security Testing), wraz z użyciem narzędzi testujących bezpieczeństwo bibliotek zewnętrznych - SCA (Software Composition Analysis), zapewniających bezpieczeństwo łańcucha dostaw.

4. Testowanie - na tym etapie cały kod i aplikacja mogą być testowane w ujęciu całościowym. Wykonywana jest dynamiczna analiza bezpieczeństwa aplikacji z użyciem narzędzi DAST (Dynamic Application Security Testing). Obok analizy dynamicznej zalecane jest, aby również analiza statyczna (SAST) wraz z analizą zależności (SCA) zostały wykonane przez dedykowane zespoły testerskie, posiadające wiedzę z zakresu bezpieczeństwa. Na tym etapie bardzo istotną rolę odgrywają testy penetracyjne, które wraz ze skanami podatności pozwolą zidentyfikować błędy bezpieczeństwa w aplikacji przed jej wdrożeniem. 

5. Wdrożenie - w tej fazie powinny być kontynuowane  testy penetracyjne, mające na celu weryfikację już nie tylko samej aplikacji, ale bezpieczeństwa całej platformy, środowiska uruchomieniowego i sieci. W tym celu stosuje się przegląd bezpieczeństwa konfiguracji tych elementów oraz wdraża systemy monitorujące ich bezpieczeństwo.

6. Utrzymanie - faza utrzymania wymaga ciągłego dbania o bezpieczeństwo i stałego jego monitorowania w zakresie logów i zdarzeń związanych z bezpieczeństwem. Dodawanie nowych funkcjonalności otwiera przestrzeń na pojawienie się nowych zagrożeń, dlatego ważne jest systematyczne i cykliczne przeprowadzanie audytów i testów bezpieczeństwa, a w przypadku wykrycia nowych luk właściwe zarządzanie podatnościami i odpowiednia polityka aktualizacji i poprawek.

Poniżej znajduje się podsumowanie praktyk bezpieczeństwa w zakresie każdego etapu SDLC:

Etap	Praktyki bezpieczeństwa
Zbieranie i analiza wymagań	- Ocena ryzyka - Określenie wymagań bezpieczeństwa - Tworzenie polityki bezpieczeństwa
Projektowanie	- Modelowanie zagrożeń - Stosowanie odpowiednich wzorców projektowych - Przegląd bezpieczeństwa architektury
Implementacja	- Wytyczne dotyczące bezpiecznego kodowania - Przeglądy bezpieczeństwa kodu - Analiza statyczna kodu (SAST) - Analiza zależniości (SCA)
Testowanie	- Analiza dynamiczna aplikacji (DAST) - Analiza statyczna (SAST) - Analiza zależności (SCA) - Testy penetracyjne - Skany podatności
Wdrożenie	- Testy penetracyjne - Przegląd bezpieczeństwa konfiguracji - Monitoring bezpieczeństwa
Utrzymanie	- Monitoring bezpieczeństwa - Audyty bezpieczeństwa - Zarządzanie podatnościami - Aktualizacje i poprawki bezpieczeństwa

Balans

Integracja praktyk bezpieczeństwa na każdym kroku cyklu tworzenia oprogramowania jest doskonałym przykładem stosowania strategii przesunięcia w lewo (shift-left), czyli uwzględnienia aspektów bezpieczeństwa najwcześniej jak się da. Pozwala to już na etapie analizy wymagań i projektowania odpowiednio uwzględnić te aspekty i, wraz z funkcjonalnością i użytecznością, odpowiednio je zbalansować. Znana zasady współzależności między tymi elementami mówi, że nic nie jest za darmo i zawsze coś jest kosztem czegoś. Przedstawia się to zazwyczaj w postaci trójkąta równoramiennego z reprezentacją każdego z elementów na wierzchołku. Wyważenie wymagań w kontekście bezpieczeństwa, funkcjonalności i użyteczności przestawia się jako punkt wewnątrz tego trójkąta. Im punkt ten znajduje się bliżej jednego z wierzchołków, tym więcej uwagi poświęcamy danemu elementowi i tym staje się on ważniejszy. Niestety ceną jest obniżenie jakości pozostałych.

Rys. 2. Triada funkcjonalność - użyteczność - bezpieczeństwo

Dobrym przykładem jest dostęp do konta w aplikacji (np. w serwisie webowym). Najwygodniejszym byłoby po prostu wpisanie nazwy użytkownika, ale oczywiście taki sposób nie zapewniałby prawie żadnego poziomu bezpieczeństwa. Dlatego wprowadzamy hasło, co w oczywisty sposób pogarsza wygodę procesu logowania. Idąc dalej, wprowadzenie uwierzytelnienia dwuskładnikowego (2FA - Two Factor Authentication) zwiększa nam jeszcze bardziej bezpieczeństwo, ale znów dzieje się to kosztem wygody, czyli użyteczności.

Obrazowo możemy to zatem przedstawić na trójkącie jako zmianę położenia punktu względem odpowiednich wierzchołków (odległość od wierzchołka funkcjonalności nie ulega zmianie, gdyż funkcjonalnie nic się nie zmienia - użytkownik nadal, w procesie logowania, uzyskuje dostęp do swojego konta):

Rys. 3. Zmiana położenia punktu funkcjonalności wraz z wprowadzaniem elementów bezpieczeństwa.

Położenie punktu jest oczywiście umowne i chodzi wyłącznie o obrazowe przedstawienie zależności. Zwiększenie bezpieczeństwa zawsze odbije się na funkcjonalności i/lub użyteczności. Dlatego tak ważne jest, aby już od samego początku projektu, od pierwszej fazy, świadomie to bezpieczeństwo wdrażać i uwzględniać jego koszt w kontekście całego projektu.

Zakończenie

Nieodpowiednie zaadresowanie aspektów bezpieczeństwa w systemach i oprogramowaniu IT może prowadzić do negatywnych skutków wizerunkowych, finansowych i prawnych.

W dobie ciągłych zagrożeń cybernetycznych wdrażanie procesu SSDLC jest nie tylko koniecznością, ale także kluczowym elementem proaktywnego podejścia do bezpieczeństwa i powinno stanowić podstawę procesu tworzenia oprogramowania w każdej organizacji.

Jeśli Twoja firma lub organizacja rozważa wdrożenie SSDLC lub potrzebuje wsparcia w doskonaleniu istniejących procesów bezpieczeństwa, zapraszamy do kontaktu.