SSDLC a odpowiedzialność za szkody wyrządzone przez software

Odpowiedzialność za szkody wynikłe z wadliwego oprogramowania w kontekście Secure Software Development Life Cycle (SSDLC)

Rozwój technologii informatycznych wkracza coraz głębiej we wszystkie dziedziny życia, wywołując wiele pytań i wątpliwości w zakresie podstaw odpowiedzialności za szkody wyrządzone błędami w oprogramowaniu. „Oprogramowanie” to nie tylko „software” w klasycznym ujęciu, w którym program zostaje zainstalowany na urządzeniu użytkownika końcowego, ale również – a nawet przede wszystkim – coraz popularniejszy model dostarczania oprogramowania jako serwisu (Software as a Service), w którym użytkownik może korzystać z dostarczanej przez producenta aplikacji webowej na różnych urządzeniach za pośrednictwem przeglądarki internetowej lub klienta aplikacji.

Aplikacje webowe są przedmiotem ataków cybernetycznych, których celem jest kradzież baz danych zawierających wrażliwe dane użytkowników (np. numery kart kredytowych, numery urzędowe, nazwiska i adresy, informacje o stanie zdrowia itp.). Następstwem kradzieży danych mogą być szkody wyrządzone użytkownikom aplikacji. Tym samym producenci aplikacji mogą być pociągani do odpowiedzialności, zwłaszcza gdy zostanie wykazane, że wyciek danych był wynikiem podatności zawartej w oprogramowaniu aplikacji (np. SQLI – sql injection, SSRF – server side request forgery, XSS – cross site scripting itp.).

OWASP Top 10 jest modelowym przykładem raportu zawierającego najczęściej występujące i najbardziej krytyczne podatności aplikacji webowych. Fundacja Open Web Application Security Project co cztery lata publikuje raport, stanowiący poradnik oraz metodologię chronienia się przed najbardziej powszechnymi technikami omijania zabezpieczeń. Producenci aplikacji chcąc uchronić się przed odpowiedzialnością muszą aktywnie minimalizować ryzyko podatności. Skuteczny atak cybernetyczny na aplikację webową to nie tylko straty materialne i wizerunkowe dla producenta aplikacji, ale również straty po stronie użytkowników, którzy następnie mogą dochodzić roszczeń od producenta.

Podstawy odpowiedzialności za program komputerowy

Kwestia podstaw odpowiedzialności nie jest oczywista. Wśród potencjalnych podstaw odpowiedzialności wskazuje się najczęściej regulację dotyczącą tzw. produktu niebezpiecznego. Jest to szczególny reżim odpowiedzialności, najczęściej zaliczany do odpowiedzialności z tytułu czynu niedozwolonego (ex delicto), choć mający również cechy odpowiedzialności umownej (ex contractu). Zasady odpowiedzialności za produkt wynikają z Dyrektywy Rady z dnia 25 lipca 1985 r. w sprawie zbliżenia przepisów ustawowych, wykonawczych i administracyjnych Państw Członkowskich dotyczących odpowiedzialności za produkty wadliwe (85/374/EWG).

Określona w Dyrektywie odpowiedzialność za produkt niebezpieczny uregulowana jest w przepisach art. 449¹ – 449¹⁰ kodeksu cywilnego (k.c.). Trzeba zastrzec, że ta podstawa odpowiedzialności nie jest oczywista. Jest wątpliwe, czy za produkt niebezpieczny można uznać program komputerowy lub aplikację webową, które nie są „rzeczami ruchomymi” ani nie są „materialne”. Tymczasem Dyrektywa w Artykule 2 definiuje „produkt” jako „każdą rzecz ruchomą, z wyjątkiem surowców rolnych i produktów łowiectwa”. Analogicznie, wg art. 449¹ § 2 k.c. „przez produkt rozumie się rzecz ruchomą (…)”, natomiast art. 45 k.c. wyraźnie zastrzega, że „rzeczami w rozumieniu niniejszego kodeksu są tylko przedmioty materialne”.

Odpowiedzialność za produkt niebezpieczny ułatwia poszkodowanym dochodzenie roszczeń. Jest oparta o zasadę ryzyka, nie wymaga więc dowodzenia winy. Poszkodowany musi tylko udowodnić szkodę i związek przyczynowy między wadliwością programu (aplikacji) a szkodą. Do zasadniczych sposobów obrony producentów należy dowodzenie, że niebezpiecznych właściwości produktu nie można było przewidzieć, uwzględniając stan nauki i techniki w chwili wprowadzenia go do obrotu.

W przypadku braku możliwości skorzystania z przepisów o odpowiedzialności za produkt niebezpieczny – pozostając w reżimie odpowiedzialności ex delicto – poszkodowanym pozostają tylko zasady ogólne, wyrażone zasadą „Kto z winy swej wyrządził drugiemu szkodę, obowiązany jest do jej naprawienia” (art. 415 k.c.). Konieczne jest wówczas udowodnienie nie tylko szkody, ale również winy producenta w stworzeniu wadliwego programu (aplikacji) oraz związku przyczynowego między szkodą a zawinionym działaniem lub zaniechaniem producenta.

Obok podstaw odpowiedzialności ex delicto możliwa jest również odpowiedzialność ex contractu, tj. wynikająca z naruszenia umowy (naruszenie zobowiązania do dostarczenia niewadliwego programu/aplikacji). W rachubę wchodzą (i) odpowiedzialność z tytułu gwarancji i rękojmi oraz (ii) ogólna odpowiedzialność za niewykonanie lub nienależyte wykonanie zobowiązania.

W przypadku odpowiedzialności ex contractu producenci najczęściej wyłączają lub starają się wyłączyć odpowiedzialność za nienależyte wykonanie umowy, ewentualnie wprowadzają do umów klauzule ograniczające ich odpowiedzialność. W obrocie profesjonalnym powszechnie stosowane są umowy, w których wyłącza się odpowiedzialność za wady programów/aplikacji w zakresie rękojmi. W obrocie konsumenckim ograniczane są zasady odpowiedzialności na podstawie gwarancji. Utrudnia to (choć nie uniemożliwia) dochodzenie roszczeń, powodując konieczność oceny narzucanych przez producentów umów przez pryzmat przepisów o nieuczciwych klauzulach umownych.

Wzorzec staranności przy tworzeniu programów

Niezależnie od podstawy odpowiedzialności, ewentualne dochodzenie roszczeń przeciwko producentowi programu lub aplikacji z tytułu szkód wyrządzonych przez błędy w oprogramowaniu będzie się wiązało z koniecznością odtworzenia zobiektywizowanego, abstrakcyjnego modelu (wzorca) „rozsądnego producenta programu (aplikacji)”.

Model ten posłuży do zweryfikowania, czy przy tworzeniu programu/aplikacji, która wyrządziła szkodę poszkodowanemu, pozwany producent dochował niezbędnych zasad bezpieczeństwa w celu wykrycia wszelkich podatności przed wprowadzeniem programu/aplikacji do obrotu, a także czy należycie monitorował działanie programu/aplikacji oraz reagował na wykrywane w toku jego działania podatności. Z punktu widzenia producentów niezwykle istotne jest więc wdrażanie przy tworzeniu programów/aplikacji najlepszych praktyk w zakresie cyberbezpieczeństwa.

SDLC, SSDLC i SSDF

Tworzenie programów i aplikacji webowych – podobnie jak wytwarzanie produktów materialnych – opiera się o wiedzę i współdziałanie wielu osób. Skutkiem pandemii covid-19 było ogromne przyspieszenie rozwoju technologii teleinformatycznych, a co za tym idzie, ataków cybernetycznych. Agresja Rosji przeciwko Ukrainie zwróciła uwagę świata na grupy hakerskie działające na polecenie rządów i przyspieszyła finansowanie budowy cyberarmii. W efekcie imperatyw zapewnienia cyberbezpieczeństwa stał się istotny jak nigdy dotąd.

Rozwój i wytwarzanie programów i aplikacji podlega cyklowi, opisywanemu w koncepcji SDLC (Software Development Life Cycle). SDLC opisuje ustrukturyzowany proces tworzenia oprogramowania.

Istnieje wiele modeli SDLC. Każdy model składa się z pięciu do siedmiu odrębnych faz, w zależności od modelu oraz konkretnego celu w zakresie rozwoju oprogramowania. Zasadnicze fazy SDLC są związane z projektowaniem, tworzeniem (kodowaniem), testowaniem i wdrażaniem oprogramowania.

7 faz SDLC to: (1) Planowanie, (2) Analiza wymagań i wykonalności, (3) Projektowanie i prototypowanie, (4) Rozwój (kodowanie), (5) Testowanie, (6) Wdrażanie, (7) Utrzymanie.

Coraz częściej mówi się jednak o SSDLC – Secure Software Development Life Cycle, kładąc w ten sposób nacisk na wymóg zapewnienia bezpieczeństwa aplikacji. SSDLC obejmuje wdrażanie procesów bezpieczeństwa na wszystkich etapach cyklu życia aplikacji.

Mnogość SDLC i rozwój SSDLC prowadzi do tworzenia SSDF – Secure Software Development Framework – rozumianego jako zbiór najlepszych praktyk bezpiecznego tworzenia oprogramowania, opartych na dokumentach opracowywanych przez takie organizacje jak OWASP, BSA, SAFEcode.

https://csrc.nist.gov/Projects/ssdf

Zgodnie z założeniami przedstawionymi przez NIST, postępowanie zgodne z SSDF ma pomóc producentom oprogramowania zmniejszyć ilość luk w wytwarzanych programach, zmniejszyć potencjalny wpływ wykorzystania niewykrytych lub nierozwiązanych luk w zabezpieczeniach oraz adresować główne przyczyny luk, zapobiegając ich powrotowi.

NIST zwraca uwagę, że niewiele modeli cyklu życia oprogramowania (SDLC) szczegółowo zajmuje się kwestią bezpieczeństwa i rekomenduje dodanie i zintegrowanie praktyk opisywanych w SSDF do każdej implementacji SDLC.

Metodologie SSDLC

Istnieje wiele metodologii SSDLC. Są one odrębne od przyjętej w danej organizacji kultury organizacyjnej (DevOps, DevSecOps) oraz metodyki wytwarzania oprogramowania (Waterfall, Scrum, Agile), choć są z nimi związane.

Do najbardziej znanych należą:

1. Microsoft SDL (Security Development Lifecycle)
2. OWASP S-SDLC Project

Microsoft SDL

Microsoft SDL to zbiór praktyk związanych z bezpieczeństwem, pogrupowanych według tradycyjnych faz cyklu życia oprogramowania.

SDL kładzie duży nacisk na zrozumienie przyczyn i skutków luk w zabezpieczeniach. Zespół programistów musi wykonać obowiązkowe działania związane z bezpieczeństwem, aby zachować zgodność z procesem Microsoft SDL.

Praktyki Microsoft SDL są szeroko opisane w oficjalnej dokumentacji:

https://www.microsoft.com/en-us/securityengineering/sdl/practices

https://docs.microsoft.com/pl-pl/windows/security/threat-protection/msft-security-dev-lifecycle

OWASP S-SDLC

OWASP S-SDLC dąży do stworzenia „bram jakości bezpieczeństwa” („security quality gates”) w celu wspierania tworzenia wysokiej jakości i bezpiecznego oprogramowania w całym potoku. Odbywa się to przez podejście Agile Security, w którym sprinty poświęcone są tematyce bezpieczeństwa (przykłady sprintów to np. przegląd kodu, uwierzytelnianie, autoryzacja, walidacja danych wejściowych, ocena zagrożeń technicznych i podatności). „Bramy jakości bezpieczeństwa” obejmują sprinty skupione wokół podobnych elementów do tych widocznych w Microsoft SDL.

Podejście OWASP S-SDLC opiera się silnie na „modelu dojrzałości”, w szczególności OWASP SAMM.

OWASP SAMM (Software Assurance Maturity Model) to otwarta platforma pomagająca organizacjom w formułowaniu i wdrażaniu strategii bezpieczeństwa oprogramowania dostosowanej do specyficznych ryzyk występujących w danej organizacji. Pomaga ocenić istniejące praktyki bezpieczeństwa programowania, zdefiniować i zmierzyć działania dla zachowania bezpieczeństwa oraz zbudować program zapewnienia bezpieczeństwa.

Podsumowując, bezpieczeństwo programów/aplikacji jest współcześnie krytycznym elementem dla każdego producenta, a jego zaniedbanie stwarza ogromne ryzyko wizerunkowe, gospodarcze oraz prawne.