Naukowcy zajmujący się danymi oddzwaniają od użycia kodu Open Source ze względu na obawy dotyczące bezpieczeństwa

Luki w komponentach open source — takie jak szeroko rozpowszechnione wady ujawnione 10 miesięcy temu w Log4j 2.0 — zmusiły analityków danych do ponownej oceny kodu open source często używanego w analizach i tworzeniu modeli uczenia maszynowego.

Według raportu Anacondy, firmy zajmującej się platformą do nauki o danych, w ubiegłym roku 40% ankietowanych analityków danych, analityków biznesowych i studentów ograniczyło korzystanie z komponentów open source, podczas gdy jedna trzecia utrzymała się na stałym poziomie, a tylko 7 % włączyło do swoich projektów więcej otwartego kodu źródłowego. Większość ankietowanych nie podlega działowi technologii informatycznych (18%), ale pracuje we własnym zespole zajmującym się analizą danych lub badawczo-rozwojowym (47%), według „Anacondy”Stan nauki o danych w roku 2022” raport opublikowany w zeszłym tygodniu.

Chociaż programiści i informatycy rozpoczęli już sprawdzanie bezpiecznego kodu, obawy dotyczące bezpieczeństwa oprogramowania typu open source to stosunkowo nowy trend w świecie nauki o danych, mówi Peter Wang, współzałożyciel i dyrektor generalny Anaconda.

„Widzimy ogromną część osób pracujących w organizacjach, w których dział IT przyjął bardzo rygorystyczne podejście do oprogramowania open source i języka Python” – mówi. „To nie są doświadczeni programiści. … Są to naukowcy zajmujący się danymi i ludzie zajmujący się uczeniem maszynowym, którzy być może nie są zbyt doświadczonymi programistami, którzy do przeprowadzania analiz wykorzystują wszystko, co tylko mogą pobrać, a następnie przekazują to działowi IT”.

Bezpieczeństwo komponentów open source – i ogólnie łańcucha dostaw oprogramowania – stało się w ciągu ostatnich dwóch lat główną kwestią rozważaną przez twórców oprogramowania, firmy i rządy krajowe. Na przykład w maju Amerykański Narodowy Instytut Standardów i Technologii (NIST) wydał wytyczne dotyczące zagrożeń związanych z łańcuchem dostaw oprogramowania. Ponadto rośnie liczba dostawców oprogramowania przyłączyli się do fundacji Linux Foundation Open Software Security Foundation (OpenSSF).

Ogólnie rzecz biorąc, dojrzałość wysiłków organizacji na rzecz bezpieczeństwa wzrosła. Około połowa firm posiada politykę bezpieczeństwa typu open source, która prowadzi do lepszych wyników w zakresie wskaźników gotowości do zapewnienia bezpieczeństwa, – wynika z czerwcowego sondażu. Ponadto wysiłki mające na celu kontrolę ryzyka związanego z oprogramowaniem open source wzrosły o 51% w ciągu ostatnich 12 miesięcy, stwierdzono w badaniu dojrzałości bezpieczeństwa na 21 XIX.

„[B]iorąc pod uwagę łańcuchy dostaw oprogramowania, większość przedsiębiorstw przyjmuje podejście do bezpieczeństwa aplikacji oparte na ryzyku” – powiedział Jason Schmitt, dyrektor generalny Synopsys Software Integrity Group, w oświadczeniu ogłaszającym badanie. „Takie podejście uwzględnia fakt, że bezpieczeństwo nie ogranicza się do bazy kodu; obejmuje proces tworzenia oprogramowania, podczas którego przeglądy bezpieczeństwa i testowanie „przenoszą się wszędzie”, aby stale poprawiać wyniki w zakresie bezpieczeństwa”.

Twórcy rozszerzają wykorzystanie Open Source 

Z innych danych wynika, że ​​producenci oprogramowania nie odnotowują żadnego spadku wykorzystania oprogramowania open source. Zamiast tego organizacje programistyczne skupiają się na poprawie bezpieczeństwa oprogramowania typu open source i wykorzystaniu bezpieczeństwa jako głównego przewodnika przy wyborze komponentów.

W "2021 Stan łańcucha dostaw oprogramowania” na przykład firma Sonatype ustaliła, że ​​cztery najważniejsze ekosystemy open source — Maven Central Repository (Java), Node.js (JavaScript), Python Package Index (Python) i galeria NuGet (.NET) — obejmują 37 milionów projektów i komponentów open source, co stanowi wzrost o 20% rok do roku. Zapotrzebowanie na te komponenty również rośnie: pobrano ponad 2.2 biliona komponentów, co stanowi wzrost o 73% w skali roku.

Zgłaszane przez społeczność analityki danych odejście od pakietów open source prawdopodobnie wskazuje na większą świadomość kwestii bezpieczeństwa, a mniej na temat odrzucania komponentów open source w fazie rozwoju, mówi Tracy Miranda, szefowa ds. open source w Chainguard.

Chociaż zespoły zajmujące się analizą danych i zespoły programistyczne mogły inaczej reagować na główne problemy związane z bezpieczeństwem — takie jak Log4j 2.0 — W przypadku odchodzenia od jednego pakietu open source firmy mają niewiele innego wyjścia niż przyjęcie innego pakietu, którego twórcy położyli większy nacisk na bezpieczeństwo, mówi.

„Firmy wykorzystują oprogramowanie open source do zwiększenia swojej szybkości, więc jeśli ograniczają, to do czego zmierzają? Pisanie kodu we własnym zakresie? Używasz spakowanych wersji innych firm?” Miranda mówi, dodając zamiast tego: „Myślę, że możemy spodziewać się, że firmy będą bardziej zwracały uwagę na jakość wykorzystywanego oprogramowania typu open source, zwłaszcza w odniesieniu do funkcji bezpieczeństwa”.

Analitycy danych nadrabiają zaległości

Rozdźwięk między obiema stronami wynika prawdopodobnie z różnych odbiorców różnych badań. Ankieta Anacondy skupiała się na specjalistach zajmujących się analizą danych, jak widać po wyborze języków programowania przez respondentów — 58% korzystało z Pythona, 42% z SQL, a tylko 26% z JavaScript. 

Lepszą miarą nastrojów twórców oprogramowania jest „StackOverflow”Ankieta dla deweloperów 2022”, z którego wynika, że ​​chociaż 58% „osób uczących się kodowania” używa Pythona, tylko 44% profesjonalnych programistów pisze w tym języku. Z drugiej strony, według ankiety przeprowadzonej przez StackOverflow, 68% profesjonalnych programistów używa JavaScript.

Ponadto, choć specjaliści zajmujący się analizą danych pracują w firmach, które w przeważającej mierze (87%) zezwalają na oprogramowanie typu open source, około jedna czwarta (26%) ma minimalny nadzór działu IT nad wyborem oprogramowania typu open source, jak stwierdzono w raporcie Anaconda. W kolejnych 18% firm dział IT określa jedynie około połowy dostępnych komponentów open source.

Opiekunowie najważniejszych projektów – których są setki, jeśli nie tysiące – muszą korzystać z bezpiecznych zależności, testować własny kod i weryfikować wiarygodność współpracowników. Opiekunowie powinni również opublikować kartę wyników bezpieczeństwa — inicjatywa utworzona przez Google, obecnie zarządzana przez Open Source Security Foundation (OpenSSF), która przyznaje projektowi ocenę bezpieczeństwa na podstawie prawie 20 różnych kryteriów.

Chociaż świadomość prawdopodobnie rośnie, nie ma szybkiego rozwiązania, mówi Miranda.

„Rzeczywistość jest taka, że ​​bezpieczniejsze opcje nie istniały wcześniej” – mówi. „Przycinanie niepotrzebnych zależności w celu zmniejszenia powierzchni ataku jest rozsądne, ale trudne do wykonania, gdy drzewo zależności jest duże”.