Czy przyszłość Open Source jest zagrożona?

Oprogramowanie open source (OSS) jest podstawą dzisiejszej architektury aplikacji. Przyspieszając wprowadzanie oprogramowania na rynek i zmniejszając obciążenie często przepracowanych programistów, open source ugruntowało swoją rewolucyjną pozycję w krajobrazie DevOps. Chociaż kopiowanie i wklejanie w otwartym kodzie źródłowym głęboko zmienia rozwój nowoczesnych aplikacji, nadal stanowi poważne zagrożenie bezpieczeństwa zarówno dla organizacji, jak i osób prywatnych. Zwalczanie tego wymaga albo całkowitej czarnej listy otwartego kodu źródłowego, albo proaktywnego wdrażania środków zaradczych, takich jak rozwiązanie WAF nowej generacji.

Kod strony trzeciej ma kluczowe znaczenie dla rozwoju aplikacji

Biblioteki to niezwykle przydatne magazyny kodu źródłowego komponentów aplikacji internetowych lub mobilnych. Biblioteki te mogą być typu open source – dostępne dla wszystkich bez żadnych kosztów – lub zastrzeżone, co blokuje kod za opłatą. Chociaż open source przypisuje sobie wiele chwały, zastrzeżony kod również odgrywa rolę w nieprzerwanym funkcjonowaniu aplikacji korporacyjnych.

To oprogramowanie innych firm, jeśli jest używane w sposób odpowiedzialny, zapobiega konieczności ciągłego wymyślania koła na nowo. To drastycznie poprawia wydajność procesu rozwoju, jednocześnie pomagając w produkcji wysokiej jakości produktu końcowego. Ostatecznie bezpłatne i liberalne korzystanie z kodu open source tworzy pętlę pozytywnych opinii, umożliwiając programistom szybsze wydawanie ich minimalnego opłacalnego produktu, co toruje drogę do szybkiego gromadzenia i wdrażania opinii i oceny użytkowników. Chociaż deweloperzy są głęboko świadomi krytycznej pozycji open source w procesie DevOps, kierownictwo często jest zaskoczone, gdy dowiaduje się, że 80% kodu obsługującego nowoczesne aplikacje pochodzi z wcześniej istniejącego kodu.

Mroczne niebezpieczeństwo zależności przechodnich

Nie jest nowością, że otwarty kod źródłowy wiąże się z ryzykiem. Niedawne powszechne słabości, takie jak Log4j i HeartBleed, nieodwołalnie umieściły ryzyko open source na mapie. To, co pozostaje coraz większym obszarem zrozumienia, to sama częstotliwość korzystania z oprogramowania typu open source oraz ukradkowy sposób, w jaki luki w zabezpieczeniach mogą wkraść się do aktywnego projektu. Pomimo ciągłego ryzyka związanego z projektami open source, przeprowadzono bardzo niewiele badań dotyczących konkretnego rodzaju ryzyka, jakie stwarza open source. Naukowcy z Endor Labs postanowili to zmienić, wyjaśniając pochodzenie głównych zagrożeń OSS.

W oprogramowaniu zależności przechodnie opisują wyjątkowo pośredni związek między dwoma komponentami. Załóżmy na przykład, że Twój zespół programistów dodaje pakiet B do trwającego projektu. Z kolei pakiet B automatycznie pobiera pakiet C. W tym scenariuszu, podczas gdy rozwijające się oprogramowanie ma bezpośredni związek z pakietem B, pakiet C pozostaje ukryty w tle – integralny, ale w dużej mierze niewidoczny. Frustrujące dla wszelkich prób bezpieczniejszych praktyk programistycznych jest fakt, że tylko 5% zależności oprogramowania open source jest ręcznie wybieranych do wdrożenia w procesie DevOps. W ten sposób większość zależności jest po prostu automatycznie wciągana do bazy kodu. Opisuje źródło przechodniej luki w zabezpieczeniach. Niedawny raport Endor Labs wykazał, że zdumiewające 95% luk w zabezpieczeniach open source pochodzi z zależności przejściowych .

Dane zostały zebrane na podstawie raportu Core Infrastructure Census II, który zawiera listę najpopularniejszych bezpłatnych programów typu open source. Dane te zostały następnie wzbogacone o inne źródła, które umożliwiły badaczom firmy Endor przeskanowanie popularnych menedżerów pakietów i bibliotek OSS. Naukowcy odkryli, że spośród 254 pakietów wymienionych w danych Spisu II większość cierpi na średnio 14 zależności przechodnich. W próżni liczba 14 może nie wydawać się szokująco wysoka, ale większość aplikacji opiera się na dziesiątkach – jeśli nie setkach – bezpośrednich zależności; ich przechodnie odpowiedniki skalują się wykładniczo.

Główne zaniepokojenie zgłaszane przez naukowców wynika z powszechnego niedoceniania problemu przez branżę. Kierownictwo nadal zmniejsza ilość kodu źródłowego używanego w procesie rozwoju — przechodnie zależności nie są jeszcze nawet na radarze. Sama głębia problemów związanych z bezpieczeństwem nadal czai się pod powierzchnią, zwiększając promień wybuchu typosquattingu i ataków polegających na zdalnym wykonywaniu kodu. Jeśli ciągłe ponowne wykorzystywanie kodu open source ma w pełni wykorzystać jego potencjał, bezpieczeństwo musi stać się wyższym priorytetem w procesie DevOps.

Jak chronić się przed ukrytymi lukami w zabezpieczeniach

Proces utrzymywania bezpiecznego stosu technologii nigdy nie był bardziej złożony. Ponieważ alerty o poprawkach szybko stają się przytłaczające, nadszedł czas, aby zabezpieczenia przedsiębiorstwa nadały priorytet automatycznej ochronie bez poprawek. Tradycyjne środki, które priorytetowo traktują bezpieczeństwo obwodowe obok analizy statycznej i dynamicznej, opierają się na ręcznych aktualizacjach, co oznacza, że ​​nie ma ochrony przed dniami zerowymi. Kod backdoora, którego użyli atakujący w ramach niesławnego ataku SolarWinds, nie został wykryty przez żadną analizę statyczną, ponieważ technicznie nie zawierał żadnych błędów.

Identyfikacja i blokowanie prób wykorzystania wymaga niewielkiego pakietu oprogramowania blokującego. Aby najpierw pomóc w zdefiniowaniu i ochronie granic aplikacji, można wdrożyć zaporę aplikacji sieci Web (WAF) nowej generacji. Siedząc na granicy między zewnętrznym a wewnętrznym, WAF monitoruje cały ruch przepływający do i z aplikacji. Aspekt nowej generacji umożliwia temu WAF automatyczne dostosowywanie i wdrażanie nowych zasad. Zautomatyzowane wdrażanie tej ciągłej ewolucji uwalnia znaczną ilość czasu i energii dla zespołu bezpieczeństwa, które w innym przypadku zostałyby wyczerpane przez oldschoolowy WAF.

Podczas gdy WAF kontroluje wszelkie zewnętrzne próby wykonania kodu, Runtime Application Self Protection (RASP) chroni przed wewnętrznymi słabościami i wstrzyknięciami kodu. Ten poziom ochrony ocenia wszystkie ładunki (takie jak zapytania SQL i polecenia systemu operacyjnego) w czasie rzeczywistym. Ten proces nie wymaga podpisów ani fazy uczenia się i odbywa się całkowicie w kontekście aplikacji. Ponieważ działa to w aplikacji, obejmuje prawie wszystkie konteksty. Oznacza to, że nawet jeśli exploit pozwala na naruszenie granicy, osoba atakująca nie może się poruszać w bok, ponieważ każde podejrzane zachowanie aplikacji powoduje zamknięcie RASP. Spowoduje to zakończenie podejrzanej aktywności i powiadomienie zespołów ds. bezpieczeństwa. W ten sposób RASP jest uzupełnieniem WAF nowej generacji; podczas gdy WAF pomaga powstrzymać zły ruch, ryzyko stwarzane przez ukryte, przejściowe exploity jest ograniczane przez RASP. Dzięki tym komponentom chroniącym stos technologii, obciążenie, jakie OSS obecnie nakłada na bezpieczeństwo, jest znacznie zmniejszone.