Podatności bezpieczeństwa w kodzie
Oprogramowanie systemu operacyjnego, oprogramowanie aplikacyjne czy firmware w systemie wbudowanym to elementarne składniki każdej infrastruktury cyfrowej. Jednak rosnące przyspieszenie i presja terminów w projektach cyfryzacji często prowadzą do zaniedbania imperatywnych aspektów bezpieczeństwa informacji. Wymagania dotyczące rozwoju oprogramowania są zazwyczaj skoncentrowane na funkcjach i podkreślają aspekty konstruktywne, więc destrukcyjne spojrzenie na potencjalne luki bezpieczeństwa jest najczęściej diametralnie różne od rzeczywistych celów rozwoju: wielu programistom po prostu również brakuje uporządkowanego i wyostrzonego spojrzenia na cyberbezpieczeństwo.
W tych warunkach zespoły programistów mają trudności z ciągłym przeglądaniem i konsekwentnym zabezpieczaniem kodowania swojego oprogramowania, czego dowodem jest wiele luk w zabezpieczeniach, które organizacja non-profit MITRE Corporation publikuje co roku na swojej liście CVE (Common Vulnerabilities and Exposures). Regularne łatki bezpieczeństwa nawet znanych producentów oprogramowania są wskaźnikiem syzyfowej pracy nad likwidacją błędów istotnych dla bezpieczeństwa, nie mówiąc już o ich identyfikacji, zanim jeszcze zostaną wprowadzone na rynek.
Kod open source - przypadek szczególny
Podczas kodowania samodzielnie tworzonego oprogramowania programiści chętnie sięgają po biblioteki i moduły open source. Praktyczne zalety są oczywiste: jeśli nie musisz wymyślać koła na nowo, korzystasz z tego zastrzyku technologii, szybszego rozwoju, niższych kosztów rozwoju, większej przejrzystości dzięki otwartemu kodowi źródłowemu i większej interoperacyjności dzięki otwartym standardom i interfejsom.
Często mówi się również, że kod z otwartego źródła oferuje wysoki stopień bezpieczeństwa, ponieważ kod został zatwierdzony przez wielu użytkowników, a inteligencja roju społeczności open source umożliwia szybkie i skuteczne usuwanie błędów.
W praktyce to zaufanie musi być obecnie oceniane w sposób zróżnicowany i krytyczny. Najpoważniejszym przykładem jest luka bezpieczeństwa zero-day Log4Shell w szeroko stosowanej bibliotece logowania Log4J dla aplikacji Java, która została odkryta w listopadzie 2021 roku. Być może słyszeliście o czerwonym poziomie alertu wydanym przez niemiecki Federalny Urząd Bezpieczeństwa Informacji (BSI) dla Log4Shell. Biblioteka Log4J, dystrybuowana jako niezawodnie działający quasi-standard za pośrednictwem Apache Foundation, zadomowiła się w wielu systemach od 2013 roku - w tym w znanych usługach internetowych, takich jak Amazon AWS.
Złożoność tych dobrze rozwiniętych i również utrzymywanych bibliotek implicite zapewnia potężne funkcjonalności, z których importujący deweloper jest często nieświadomy w swoim własnym połączonym nowym rozwoju, ale które mogą być wykorzystane przez atakujących.
Innym czynnikiem braku bezpieczeństwa komponentów open source są tak zwane ataki łańcucha dostaw, czyli zamierzone wbudowane podatności przez złośliwe podmioty, które podają się za część społeczności open source i pomagają w rozwoju kodu. Taka podatność jest dla hakerów niezwykle skutecznym sposobem na zaatakowanie dużej liczby organizacji będących kolejnymi użytkownikami. Nic więc dziwnego, że ten wektor ataku gwałtownie rośnie: w badaniu Sonatype zdiagnozowano wzrost o 650% przy porównaniu lat 2020 i 2021.