Jak weryfikować bezpieczeństwo oprogramowania open source? Identyfikacja luk w kodzie to kropla w morzu potrzeb

Idea open source początkowo nie budziła zbyt dużego zaufania organizacji, czego głównym powodem była obawa o jakość i bezpieczeństwo kodu. Regularna praca nad PR-em otwartego oprogramowania sprawiła, że użytkownicy zaczęli rozumieć jego istotę, a nawet zauważać przewagi nad rozwiązaniami komercyjnymi. Dziś z open source korzysta zdecydowana większość firm na całym świecie, choć nie każda robi to w sposób bezpieczny. Okazuje się bowiem, że jedynie 46 proc. organizacji posiada wewnętrzne instrukcje, listy kontrolne lub wytyczne dotyczące korzystania z OSS, a szkolenia dla programistów w zakresie bezpiecznego tworzenia oprogramowania są wymagane w co czwartej^[1]. Być może to właśnie brak świadomości jest powodem, dla którego większość firm podchodzi wybiórczo do analizy ryzyka open source, narażając się tym samym na ataki cybernetyczne. Jak to zmienić?

Jak organizacje dbają o bezpieczeństwo OSS?

Międzynarodowe raporty pokazują, że firmy w ograniczony sposób podchodzą do analizy bezpieczeństwa oprogramowania open source. Najczęściej podejmowanymi działaniami przed skorzystaniem z nowego komponentu są sprawdzenie poziomu aktywności społeczności projektowej (50 proc. odpowiedzi), badanie bezpośrednich zależności kodu (42 proc.) oraz sprawdzenie oceny repozytoriów lub statystyk pobrań pakietów (42 proc.)^[2]. Niespełna 40 proc. organizacji zwraca uwagę na częstotliwość nowych wydań i ocenia kod przy pomocy zautomatyzowanych narzędzi. W badaniu przeprowadzonym przez The Linux Foundation zaledwie co czwarta osoba przyznała, że sprawdza projekt pod kątem istniejącej w firmie polityki ryzyka.

Jak podkreśla Dariusz Świąder, prezes Linux Polska, dane nie pozostawiają złudzeń – większość organizacji na świecie nie posiada odpowiedniej, przekrojowej strategii dotyczącej bezpieczeństwa open source.

– To, co z pewnością jest widoczne w badaniach, to brak świadomości na temat czynników ryzyka w związku z wykorzystaniem przez organizacje oprogramowania open source. Firmy rzadko podchodzą strategicznie do tego problemu, np. wdrażając odpowiednie procedury i edukując zespół projektowy w zakresie cyberbezpieczeństwa. Gdy przychodzi do kwestii analizy danego komponentu lub rozwiązania open source, niektóre czynniki ryzyka są szczegółowo badane, inne zaś zupełnie pomijane. Przyczyna takiego podejścia często tkwi w kwestiach finansowych – samodzielne przeprowadzenie analizy wymaga sporych zasobów czasowych i wysoko rozwiniętych kompetencji, co wiąże się z wysokimi kosztami. Aby pomóc organizacjom dokonywać bardziej kompleksowej oceny zagrożenia, stworzyliśmy SourceMation – platformę umożliwiającą szybką i zautomatyzowaną analizę jakości kodu, podatności rozwiązania oraz wielu innych czynników, które powinny być brane pod uwagę podczas badania ryzyka oprogramowania open source. Platforma wspiera łańcuch wartości DevSecOps, dostarczając organizacjom cennych informacji w procesie szczegółowej analizy wdrażanego projektu – dodaje Dariusz Świąder, prezes Linux Polska.

Nie tylko luki w kodzie. Czynników ryzyka jest dużo więcej

Eksperci nie mają wątpliwości – weryfikacja bezpieczeństwa oprogramowania open source powinna uwzględniać wiele różnorodnych aspektów, a pominięcie tych najbardziej istotnych oznacza narażenie organizacji na cyberataki. Oprócz standardowej analizy kodu w celu identyfikacji błędów, które zwiększają podatność oprogramowania na ataki, konieczne jest także zbadanie całego otoczenia projektu. Należy wziąć pod uwagę możliwość opóźnień w dostarczaniu poprawek bezpieczeństwa, wycofania wsparcia przez autorów czy braku obsługi zagrożeń zero-day. Duże znaczenie ma także ryzyko zmian w licencjach, co skutkuje niekompatybilnością lub ograniczeniem dostępu do kodu. Twórcy otwartego kodu mogą w końcu w każdym momencie podjąć decyzję o jego zamknięciu, co mimo krytyki społeczności open source czasami faktycznie się zdarza.

Coraz większy wpływ na sposób weryfikacji bezpieczeństwa oprogramowania open source ma także niestabilna sytuacja geopolityczna na świecie. Z tego względu analiza ryzyka powinna obejmować także pochodzenie geograficzne kodu i informacje o jego twórcach. Zbadanie tych czynników pozwala zabezpieczyć organizację m.in. przed wprowadzeniem złośliwego kodu przez obce podmioty czy atakiem na łańcuch dostaw oprogramowania. Jak wskazuje Radosław Klewin, Senior Solutions Architect w Linux Polska, kompleksowa analiza ryzyka jest dzisiaj jedynym sposobem na bezpieczeństwo informatyczne organizacji.

– Poza identyfikacją potencjalnych zagrożeń, każda firma planująca wdrożenie rozwiązania open source powinna także obserwować zmiany w licencjach i dokładnie przeanalizować ewentualne słabości w łańcuchu logistycznym oprogramowania. Czynników jest wiele, co nie tylko wiąże się z dużymi nakładami pracy, lecz także może rodzić problemy w zakresie prawidłowej interpretacji otrzymanych wyników. Dlatego w przypadku SourceMation zdecydowaliśmy się na wdrożenie prostego i czytelnego wskaźnika ryzyka oprogramowania open source, który opracowaliśmy na podstawie nowatorskiej metody analizy rozwiązań informatycznych SCARE (ang. Software Component Analysis for Risk Engineering). Indeks SourceMation prezentuje wyniki analizy w skali 1-10, biorąc pod uwagę wiele atrybutów oprogramowania, m.in. obciążenie projektami, liczbę linii, styl i kompatybilność kodu, strefę czasową czy poziom długu technologicznego. W razie jakichkolwiek problemów z interpretacją danych użytkownik może skorzystać z naszej pomocy – SourceMation to także Centrum Indywidualnego Wsparcia Technicznego, które jest tworzone przez ekspertów w zakresie open source i bezpieczeństwa IT – wyjaśnia Radosław Klewin, Senior Solutions Architect w Linux Polska.

Opracowanie strategii kluczem do sukcesu 

Jak sprawić, by organizacje zmieniły swoje podejście do analizy ryzyka związanego z wdrożeniem rozwiązań open source? Badania pokazują, że zdecydowanie bardziej kompleksowym i rygorystycznym podejściem cechują się te firmy, które posiadają OSPO lub opracowały jasną strategię wykorzystania OSS. Według raportu The Linux Foundation 61 proc. z nich testuje bezpieczeństwo i podatności oprogramowania przed jego zastosowaniem (w przypadku organizacji bez strategii odsetek ten wynosi zaledwie 26 proc.), a 70 proc. dokonuje przeglądu kodu (czynność tę podejmuje niespełna co druga firma z drugiej grupy)^[3].

Większa jest również świadomość w zakresie zasad wykorzystania otwartego kodu. Co trzeci pracownik firmy, która nie posiada OSPO lub strategii dotyczącej bezpieczeństwa open source, nie wie, w jaki sposób jego organizacja weryfikuje bezpieczeństwo OSS. Odsetek ten w przypadku przedsiębiorstw ze strategicznym podejściem wynosi zaledwie 5 proc.

 

^[1] The Linux Foundation, World of Open Source, Global Spotlight 2023

^[2] The Linux Foundation, World of Open Source, Global Spotlight 2023

^[3] The Linux Foundation, World of Open Source, Global Spotlight 2023