Yunus twierdzi, że sprzedawcy powinni realizować skuteczne programy wzajemnej weryfikacji w przypadku każdego otwartego kodu źródłowego, z jakiego korzystają, przeprowadzać analizy statyczne i dynamiczne oraz testować jego odporność na błędne dane, aby zapewnić jego możliwie jak największą bezbłędność, a więc bezpieczeństwo. Firmy powinny zatem poważnie zastanowić się nad swoim procesami w obszarze kontroli i zapewnienia jakości.

Kwestionuje jednak to, czy kod OpenSSL powinien był zostać napisany w niskopoziomowym języku, takim jak C, sugerując, że używanie języka pozbawionego funkcji zarządzania pamięcią w tak podatnej na zagrożenia aplikacji niemal ociera się o „wykroczenie”. Jednak Jeffrey Hammond, analityk ds. bezpieczeńswa w Forrester Research, ma jednak odmienne zdanie. Zwraca uwagę na fakt, że kluczowym warunkiem kodu OpenSSL jest wydajność, ponieważ musi on radzić sobie z ogromnym wolumenem pakietów danych. Język programowania umożliwiający dostęp do pamięci sprawia, że jest ono bardziej podatne na poszczególne rodzaje ataków, ale jednocześnie zyskuje na wydajności. A ta zawsze idzie w parze z odpowiedzialnością.

Zobacz również:

• Google udostępnia AI Gemma dla developerów

Testowanie kodów typu open source ma swoje ograniczenia

Nie ulega wątpliwości, że przeprowadzanie wymagających testów bezpieczeństwa otwartego kody źródłowego to niezwykle czasochłonne zadanie wymagające umiejętności na naprawdę wysokim poziomie. To jeden z problemów, z jakimi borykają się projekty w tym obszarze, ale też powód w pewnym stopniu usprawiedliwiający Seggelemanna lub jakiegkolwiek innego pracownika zespołu OpenSSL.

Doskonale ilustruje to inny projekt w zakresie kodu open source, mianowicie program szyfrujący TrueCrypt. Projekt ten był dostępny publicznie od początku jego powstania przed dziesięcioma laty, ale dopiero niedawno przeprowadzono na nim prawidłową analizę bezpieczeństwa. Tylko i wyłącznie dzięki zbiórce funduszy na ten cel w serwisach Indiegogo i Fundfill, która przyniosła łącznie około 60 tysięcy dolarów.

Wstępna analiza tego programu, jedynie w obszarze ładowania wstępnego i sterownika jądra Windowsa, wykazała 11 błędów i niską jakość kodu źródłowego. Kompilacja programu TrueCrypt ze źródła opierała się o przestarzałe (21-letnie) i nieautoryzowane narzędzia tworzenia szyfru, które mogły zostać złośliwie zmodyfikowane, a do których trudno uzyskać dostęp z zaufanych źródeł. Testerzy stwierdzili, że nawet w tym wąskim zakresie kod nie spełniał standardów bezpieczeństwa.

Alarmujący jest jednak fakt, że tego rodzaju błędy ujrzały światło dziennie dopiero na skutek zebrania funduszy potrzebnych do wynagrodzenia specjalistów, którzy są w stanie przeprowadzić audyt oprogramowania. Oczywiście, w ostatniej dekadzie można było sprawdzić ten kod, ale prawda jest taka, że brakowało czasu, umiejętności i zasobów (w tym finansowych) do prawidłowego wykonania tego zadania.

W najbliższej przyszłości kod OpenSSL będzie musiał zmierzyć się z nowymi, rosnącymi problemami wynikającymi z jego rozwoju pod nazwą LibreSSL, za który odpowiada zespół OpenBSD. LibreSSL ma stanowić uproszczoną wersję kodu OpenSSL. Już w pierwszym tygodniu trwania nowego projektu usunięto ponad 90 tysięcy wierszy ze starego kodu, w tym wiersze obsługujące takie systemy operacyjne, jak VMS i OS/2.

Powiedzmy sobie jasno, takie zmiany sprawiają, że użytkownicy są wyjątkowo podatni na działania złośliwych hakerów, którzy mogą zechcieć wykorzystać słabe punkty modyfikacji wprowadzonych w kodzie LibreSSL. Tym bardziej, że porównanie elementów usuniętych i podmienionych między obiema wersjami jest stosunkowo łatwe. Zakładamy, oczywiście, że dotychczasowy OpenSSL będzie w stanie podążać za postępem LibreSSL.

Brak przejrzystości nigdy nie jest dobrym sposobem na zapewnienie bezpieczeństwa. Nie zmienia to jednak faktu, że po ujawnieniu błędów trzeba je natychmiast naprawić. Nie wiadomo jeszcze, czy zajmie się tym zespół OpenSSL, ani czy oprogramowanie i sprzęt korzystający kodu OpenSSL zostaną prawidłowo i szybko zaktualizowane do jego najnowszej wersji.