To już trzeci odcinek z serii seria artykułów o najczęstszym rodzaju ataków na łańcuch dostaw oprogramowania: tych, które wykorzystują publiczny rejestr open-source komponenty oprogramowania. Po analizie w poprzednim odcinku „Anatomia złośliwych pakietów: jakie są trendy?„w jaki sposób źli aktorzy wprowadzają złośliwe zachowania do nowych lub istniejących opublikowanych komponentów, jesteśmy gotowi założyć kamizelki strażackie i zbadać, w jaki sposób możemy skutecznie zablokować złośliwe oprogramowanie dostarczane w ten sposób lub, alternatywnie, poradzić sobie z potencjalnie poważnym cyberincydentem, ponieważ podjęliśmy niewłaściwe podejście.
Większość specjalistów ds. bezpieczeństwa ma pomysły na to, jak sobie z tym zagrożeniem poradzić. Słyszeliśmy, jak menedżerowie ds. bezpieczeństwa bez wahania mówili: SCA Narzędzia już informują, kiedy dana wersja pakietu jest złośliwym oprogramowaniem. Albo że opierają się na znanych, wysoko ocenianych komponentach oprogramowania, gdzie każde złośliwe oprogramowanie zostałoby szybko wykryte i usunięte. Używają otwartych wersji drobnych/poprawek do automatycznego pobierania poprawek luk w zabezpieczeniach, co jest właściwym, zalecanym sposobem na zmniejszenie ryzyka związanego z zależnościami od oprogramowania open source, zgodnie z „łatać wcześnie, łatać często”.
W tym odcinku omówimy, dlaczego te idee są błędne i jak te błędne przekonania przyczyniają się do popularności tego mechanizmu ataku oraz do przytłaczającego ryzyka, z jakim borykają się organizacje. Na koniec omówimy, co działa, a także jaki jest wymagany nakład pracy i zasobów.
Wspólne nieporozumienia
Podczas naszej podróży z bezpieczeństwem oprogramowania obserwowaliśmy ewolucję technik ataków i szeroki wachlarz pomysłów osób dbających o bezpieczeństwo. Organizacje często nie rozumieją, co działa w walce z tym zagrożeniem, dlatego najpierw przyjrzymy się temu, co nie działa, podsumowując to w poniższej, niewyczerpującej, liście błędnych przekonań.
Fałszywy pogląd nr 1: SCA narzędzia już zgłaszają złośliwe komponenty
W rzeczy samej! Ale po fakcie… Kiedy prawdopodobnie jest już za późno, jeśli element został użyty w kompilacji oprogramowania, a źli aktorzy zyskali już przyczółek w deweloperze lub CI/CD hosta. Sekrety mogły zostać wykradzione, mogło zostać pobrane i zainstalowane dodatkowe złośliwe oprogramowanie, a być może przeciwnik rozprzestrzenił się bocznie i uzyskał już dostęp gdzie indziej.
Analiza składu oprogramowania (SCA) zostały zaprojektowane w celu identyfikacji potencjalnie znanych luk w zabezpieczeniach. Nowoczesne narzędzia doskonale sprawdzają się, zwiększając stosunek sygnału do szumu (SNR), określając, czy luka jest rzeczywiście osiągalna lub możliwa do wykorzystania. Są one jednak bezużyteczne w przypadku nowego złośliwego oprogramowania. Wyobraź sobie złośliwy komponent jako lukę typu zero-day: dopiero po wykryciu jego szkodliwego działania jest on zgłaszany do rejestru, który po weryfikacji przez zespół ds. bezpieczeństwa zostaje potwierdzony jako złośliwy i usunięty z rejestru. [1].
W tym momencie świat (w tym SCAs) wie, że instalacja lub używanie komponentu (lub niektórych wersji istniejącego komponentu) nie jest dobrym pomysłem. Dzieje się tak jednak, gdy komponent nie jest dostępny w rejestrze.Wiedza o tym, że mam luki w zabezpieczeniach komponentów firm trzecich, a nawet komponentów, które zostały sklasyfikowane jako złośliwe przez rejestr, jest dobra, ale niestety SCA lub powszechnie stosowane narzędzia audytowe nie są pomocne w tym kontekście. Dopóki SCANarzędzie /audit może naprawdę z wyprzedzeniem rozpoznać, że dany komponent jest złośliwy, zanim zostanie użyty w Twojej organizacji.
Pamiętaj, że każde rozwiązanie chroniące przed złośliwymi komponentami typu open source musi je wykrywać w lociemiędzy momentem opublikowania komponentu w rejestrze a momentem jego pierwszego użycia (wersji) w organizacji. Dotyczy to również komponentów przechodnich.
Błędne przekonanie nr 2: Kontrolowanie skryptów instalacyjnych w czasie kompilacji zapobiega złośliwemu zachowaniu komponentów typu open source
Różne menedżery pakietów oferują możliwość uruchamiania skryptów (zawartych w archiwum komponentów tarball) [2]), z uzasadnionych powodów, takich jak kompilowanie wymaganych elementów na różnych platformach, generowanie kodu lub uruchamianie testów. Powinniśmy zdawać sobie sprawę, że mogą one paść ofiarą nadużyć, jeśli w archiwum tarball znajdą się złośliwe skrypty lub jeśli atakujący może uruchomić złośliwy skrypt zamiast dobrego.
Wiedząc to, możemy skonfigurować menedżera pakietów tak, aby ignorował skrypty. Na przykład, za pomocą NPM –Ignore-scripts flaga (lub właściwość konfiguracji w .npmrc Plik) pomija skrypty podczas instalacji. Może to powodować pewne problemy, ponieważ uruchamianie skryptów jest powszechne w wielu ekosystemach: niektóre menedżery pakietów nie pozwalają nawet na wyłączenie wykonywania skryptów (wskazówka: monit „Które menedżery pakietów nie pozwalają na wyłączenie wykonywania skryptów instalacyjnych?” w twojej ulubionej sztucznej inteligencji). Ale to nie chroni w ogólności (musimy wymusić, aby konfiguracja pomijania wyłączeń była wszędzie).
A jeśli szkodliwe zachowanie nie znajduje się w skryptach instalacyjnych, lecz w oprogramowaniu uruchamianym w czasie rzeczywistym, to ta opcja sama w sobie nie zapewni nam ochrony.
Błędne przekonanie nr 3: Przypinanie wersji zapobiega instalacji złośliwych komponentów
Istnieje kompromis pomiędzy wczesnym i częstym łataniem otwarte wersje (umożliwiając menedżerowi pakietów automatyczną instalację nowych aktualizacji, gdy są dostępne w celu poprawy bezpieczeństwa) i wersja przypinana (posiadanie wszystkich bezpośrednich i przechodnich zależności dla oprogramowania w stałej wersji). Zasady bezpieczeństwa są uparte i czasami sprzeczne, jak to się dzieje w przypadku zasady „poprawiaj wcześnie, poprawiaj często” i „modernizacji nie należy traktować lekko”Niektóre menedżery pakietów automatycznie aktualizują zakresy serwerów w zalecany sposób. Świetnie, jeśli chcesz również otrzymywać złośliwe aktualizacje! Tak, komponenty muszą być aktualizowane, aby otrzymywać poprawki bezpieczeństwa, które jak najszybciej usuwają luki w zabezpieczeniach, ale… nigdy nie pozwól menedżerowi pakietów robić tego automatycznie.
Błędne przekonanie nr 4: Korzystanie z zaufanych komponentów jest bezpieczne. Każda złośliwa wersja zostałaby natychmiast wykryta, ujawniona i usunięta.
Dlaczego komponent jest godny zaufania? Być może dlatego, że jest bardzo popularny, z wieloma osobami wyszukującymi luki w zabezpieczeniach, dużą liczbą współpracowników odpowiedzialnych za jego utrzymanie, z wieloma głównymi opiekunami, którzy skrupulatnie weryfikują wszystkie pull requestsRzeczywistość jest zupełnie inna. Niektóre istotne komponenty są utrzymywane przez jednego, nieodpłatnego programistę. Powszechnie stosowane frameworki mają kilku stałych współpracowników, z szybko zmniejszającą się liczbą commits per konserwator (popularne projekty mają długi ogon współpracowników, którzy wykonują pewne działania „drive-by” commit i nigdy nie wracają). A popularnych projektów, które mają tylko jednego opiekuna, jest mnóstwo.
Wyobraź sobie, że mówisz „Och, używamy Spring Boot / Angular / React / PyTorch / oficjalnych obrazów bazowych Docker, więc ryzyko, o którym mówisz, jest dość niskie”. Być może to prawda, my, dostawcy zabezpieczeń, ciągle straszymy, a ingerowanie w pracę zespołów programistycznych w celu zminimalizowania kontrowersyjnego ryzyka to nonsens. Możesz mieć ochotę od razu przejść do akapitu o akceptacji ryzyka (w następnej sekcji) i po sprawie. Niestety, najpopularniejsze komponenty są celem ataków, na przykład popularne Biblioteka PyTorch została zaatakowana w przeszłości.
„Natychmiast znalezione, ujawnione i usunięte”. Usunięcie nowego złośliwego komponentu z rejestru publicznego zajmuje kilka dni. Rejestry ostrożnie podchodzą do usuwania wersji komponentu, dla dobra ogółu. Z naszego doświadczenia wynika, że po zgłoszeniu przez nas, mediana czasu usunięcia przez rejestr zainfekowanej wersji wynosi 39 godzin, czyli ponad półtora dnia. Zdarzają się złośliwe komponenty, które są usuwane z rejestru tydzień po naszym pierwszym zgłoszeniu. W niektórych przypadkach komponent jest usuwany dopiero po zgłoszeniu incydentu związanego z tym komponentem przez ofiarę lub firmę zajmującą się reagowaniem na incydenty.
Co NIE działa przeciwko złośliwym komponentom
Każde niesprecyzowane podejście zakończy się całkowitą porażką. To pewne, nie zapewniasz skutecznych środków zaradczych na ryzyko związane z tym zagrożeniem.
Tradycyjne SCA Narzędzia informują o znanym złośliwym oprogramowaniu, ale mają duże okno narażenia. Jeśli nie wykonują proaktywnego wykrywania złośliwego oprogramowania z wymuszonym blokowaniem szkodliwych komponentów, nie działają przeciwko temu zagrożeniu.
Wyłączenie skryptów instalacyjnych mogłoby pomóc, ale musi być egzekwowane wszędzie tam, gdzie komponent musi zostać zainstalowany. To samo dotyczy przypinania wersji, ponieważ wersji nie można przypinać z bezpiecznego stanu początkowego na zawsze.
Założenie, że popularne komponenty otrzymują wystarczającą uwagę, aby nie można było im narzucić niezamierzonego zachowania w ataku na łańcuch dostaw bez niemal natychmiastowego wykrycia, które zapobiegnie jakimkolwiek szkodom, jest naiwne i ryzykowne. Nie chcesz przecież żyć na krawędzi, prawda?
Jeśli zatrzymasz się w tym miejscu, to akceptacja ryzyka to jedyne, co możesz zrobić: To jest decisjon, który należy udokumentować w modelu zagrożeń/ocenie ryzyka, w tym uzasadnienie akceptacji ryzyka i jego potencjalne konsekwencje. Zwiększ świadomość, komunikując to kierownictwu i innym zainteresowanym stronom. Niektóre przypadkowość Można to zaplanować, gdy złośliwy komponent zostanie zainstalowany lub dodany do oprogramowania, ale jest to trudne, ponieważ atakujący mają wiele ścieżek do wykorzystania. Szczegóły ataku na łańcuch dostaw opartego na użyciu złośliwego komponentu drastycznie zmienią publiczne ujawnienie incydentu, co prawdopodobnie jest obowiązkowe w ramach regulacyjnych Twojej organizacji. Możesz również zwrócić się do kompensujące sterowanie or ryzyko transferowe np. z ubezpieczeniem.
Istnieją jednak środki kontroli, które przeciwdziałają temu zagrożeniu i należy je rozważyć, jeśli nie jesteś zadowolony z akceptacji ryzyka. Czytaj dalej.
Co działa przeciwko atakom wykorzystującym złośliwe komponenty
Solidna wersja obsługi
Przypinanie wersji z kontrolowanym i świadomym zwiększaniem liczby wersji to właściwy sposób, aby zrównoważyć potrzebę usuwania luk w zabezpieczeniach bez ryzyka zainfekowania złośliwym oprogramowaniem. Należy jednak pamiętać o błędnym przekonaniu nr 3: samo przypinanie wersji nie wystarczy do zablokowania złośliwego kodu pochodzącego z nowych wersji, ponieważ w przyszłości konieczne będzie aktualizowanie wersji w każdej bezpośredniej lub pośredniej zależności. W takiej sytuacji potrzebne są wystarczająco silne dowody na to, że wszystkie zmodyfikowane wersje nie zawierają złośliwego oprogramowania.
Wczesne ostrzeżenie
Jednym ze sposobów rozwiązania problemu złośliwych komponentów jest system wczesnego ostrzegania (nazwany tutaj Wczesne ostrzeganie przed złośliwym oprogramowaniem lub MEW), w którym nowe publikowane wersje (nowych lub istniejących komponentów) są analizowane przez silnik detekcji, który po znalezieniu wystarczającej ilości dowodów może sklasyfikować nową wersję jako potencjalnie złośliwą.
Automatyzacja jest tutaj niezbędna, ponieważ ręczne sprawdzanie wszystkich nowych komponentów przy obecnym tempie publikacji jest niemożliwe. Dlatego mechanizm detekcji musi łączyć różne techniki, w tym analizę statyczną, dynamiczną i wydajnościową, analizę reputacji użytkowników oraz dowody pochodzące z rozbieżności między metadanymi komponentu a zawartością archiwum tarball lub między archiwum tarball a repozytorium źródłowym, z którego komponent rzekomo pochodzi.
Tam jest ciemna strefa między momentem publikacji a momentem analizy zawartości komponentu przez silnik, ale nie powinien on przekraczać kilku minut. Schemat można zmodyfikować, na przykład czekając na analizę nowych komponentów przed zezwoleniem na ich instalację i użycie w kompilacji oprogramowania. pipelines lub analizować je na żądanie, gdy jest to potrzebne. Komponent w danej wersji jest niezmienny. [3], więc należy ją przeanalizować tylko raz.
Pełna automatyzacja nie jest możliwa i konieczne jest przeprowadzenie przeglądu bezpieczeństwa pod kątem potencjalnie złośliwych komponentów. Uważaj na zwolenników cyfrowego panaceum:Sztuczna inteligencja i uczenie maszynowe nie są na tyle rozwinięte, aby same decydowały o tym, czy podejrzany komponent zawiera złośliwe oprogramowanie. Oczywiście, uczenie maszynowe odgrywa kluczową rolę w mechanizmie detekcji, klasyfikując komponent wejściowy na podstawie zebranych dowodów, ale po „poddaniu kwarantannie” komponentu, decydujące znaczenie ma ręczna weryfikacja przez zespół ds. bezpieczeństwa z doświadczeniem w zakresie złośliwych komponentów. Potwierdza ona potencjalne złośliwe oprogramowanie lub ponownie klasyfikuje je jako bezpieczne. Czas ten wynosi około godzin.
Rejestr raportuje o złośliwej wersji/komponentach; następnie rejestr przeprowadza weryfikację w celu potwierdzenia i przystępuje do publicznego ujawnienia oraz usunięcia z rejestru. Niektóre rejestry przechowują pakiet bezpieczeństwa. Zakres czasowy to liczba dni lub tygodni od publikacji, czyli „czas oczekiwania"lub"okno ekspozycji' dla większości złośliwych komponentów.
Czy można stwierdzić, czy wersja komponentu jest złośliwa?
Aby więc zapewnić wczesne ostrzeganie, musimy udzielić satysfakcjonującej odpowiedzi na pytanie: Skąd mogę wiedzieć, że biblioteka lub pakiet (nie) jest złośliwy? Jak zebrać wystarczającą ilość dowodów na złośliwe zachowanie? Możliwe, ale trudne, ponieważ przeciwnicy wykazują się dużą pomysłowością, aby uniknąć wykrycia. Istnieją różne podejścia, każde z zaletami i wadami.
Analiza statyczna Może badać wszystkie ścieżki wykonywania, sprawdzać techniki stosowane przez atakujących bez uruchamiania komponentu oraz wykonywać zadania wstępnego przetwarzania, takie jak de-obfuskacja czy deszyfrowanie. Ponieważ atakujący próbują ukryć swoje intrygi, próby zaciemniania kodu są rzeczywiście dowodem na obecność złośliwego oprogramowania (należy jednak pamiętać, że legalne komponenty zaciemniają kod w celu ochrony własności intelektualnej, co jest sprzeczne z „open source”). Tylko niewielka część wysoce zaawansowanych ataków z silnym zaciemnianiem wymaga sandboxingu, ale takie silne zaciemnianie jest wyraźnym sygnałem złośliwości. Należy pamiętać, że konwencjonalne SAST Narzędzia te zaprojektowano tak, aby wykorzystywały nieumyślne luki w zabezpieczeniach, a nie do złośliwych celów, jak np. tylne drzwi.
Analiza dynamiczna Uruchamia komponent i analizuje odpowiedź, instrumentując środowisko wykonawcze, zazwyczaj zapewniając środowisko sandboxowe. Złośliwe zachowanie wyzwolone w pewnych warunkach może pozostać niewykryte: należy pamiętać, że złośliwe oprogramowanie może wykorzystywać techniki unikania, takie jak Unikanie wirtualizacji/piaskownicy aktywować tylko wtedy, gdy nie jest poddawane kontroli, a także jest oznaką złośliwej aktywności dla każdego silnika analizy statycznej.
Analiza możliwości Uwzględnia, co robi komponent: gdzie się łączy, do których plików uzyskuje dostęp, które polecenia lub programy są uruchamiane, jakie operacje wejścia/wyjścia terminala lub urządzenia są wykonywane, a także które wywołania systemowe są wywoływane. Ten odcisk palca zachowania można porównać (dla istniejącego komponentu) między wersjami, tak aby w przypadku wykrycia nieoczekiwanego zachowania, dowód ten mógł wzbudzić podejrzenie potencjalnej złośliwej aktywności wstrzykniętej do nowej wersji. To podejście jest zgodne z procedurami selekcji, które analitycy bezpieczeństwa stosują w przypadku potencjalnego złośliwego oprogramowania: inspekcja przy użyciu smyczki lub podobnych narzędzi. To podejście wykrywa złośliwe zachowania niezależnie od warunków wyzwalających i działa, gdy kod źródłowy nie jest dostępny.
Analiza kontekstu Gromadzi informacje o tym, jak i przez kogo dany komponent został opublikowany. Kampanie hakerów często wykorzystują nowe konta użytkowników, które nie podlegają żadnemu rygorystycznemu procesowi weryfikacji. Śledzenie wcześniejszej aktywności może dać wgląd w tożsamość użytkownika, głównie w przypadku anomalii, które mogą wskazywać na potencjalne zagrożenie. Reputację trudno zdobyć i łatwo stracić! Użytkownik bez wcześniejszej aktywności jest neutralny, ale karma goni za złoczyńcami. Należy uważnie śledzić hakerów, czyli zwykłych użytkowników, których dane do publikacji zostały skradzione.
Inną informacją kontekstową są wszelkie rozbieżności między repozytorium źródłowym rzekomo użytym do utworzenia archiwum tarball komponentu a zawartością samego archiwum tarball. Należy również przestrzegać dobrych praktyk, takich jak tworzenie tagów lub wydań w repozytorium źródłowym, które odpowiadają wersjom komponentu opublikowanym w rejestrze publicznym. Gdy repozytorium źródłowe znajduje się w określonym miejscu, commit jest oznaczony tagiem release, a następnie nagle jedna wersja go nie spełnia, to samo w sobie stanowi mocny dowód na to, że komponent może być skażony: osoba atakująca mogła naruszyć konto użyte do opublikowania komponentu, ale nie ma uprawnień do zapisu w repozytorium kodu źródłowego). Wiele ataków jest rutynowo wykrywanych za pomocą tych reguł: na przykład Atak na księgę główną Można je łatwo wykryć w ten sposób. Analiza kontekstowa identyfikuje zatem takie anomalie w procesie publikacji.
Zapora zależności
Innym podejściem jest posiadanie kompleksowej białej listy komponentów dla wszystkich grafów zależności używanych w oprogramowaniu, dzięki czemu w każdej kompilacji pipeline W Twojej organizacji można instalować i używać wyłącznie zatwierdzonych wersji komponentów.zapora„jest egzekwowane za pomocą wewnętrznego rejestru, w którym przechowywane są pliki tar dla dozwolonych wersji komponentów (w pamięci podręcznej lub na serwerze proxy). Należy pamiętać, że żadna biała lista nie będzie działać, jeśli nie dysponujesz technologią umożliwiającą klasyfikowanie każdej nowej wersji jako w miarę bezpiecznej, aby można ją było dodać do białej listy.
Należy pamiętać, że wczesne ostrzeganie (szybkie wykrywanie tak szybko, jak to możliwe po opublikowaniu nowej wersji) musi być połączone z jakimś sposobem proaktywnego wykorzystania tych informacji w celu zablokowania komponentu mającego wpływ na kompilację pipelinelub maszyn programistów [4]. Nazywamy to „zapora zależności„: mechanizm kwarantanny chroniący zautomatyzowane kompilacje przed złośliwymi pakietami. Wewnętrzne rejestry pakietów i obrazów są skuteczne w izolowaniu organizacji od zewnętrznego zła, ale do skuteczności kwarantanny potrzebne są wystarczająco silne dowody.
Sandboxing środowiska wykonawczego
Alternatywnym podejściem do wykrywania w momencie publikacji jest analiza zachowania w czasie wykonywania. Chodzi o to, aby przechwycić oczekiwane zachowanie oprogramowania i wykryć (lub zablokować) wszelkie wykryte anomalie. Ten sposób działania wiąże się z problemem konieczności instrumentacji środowiska wykonawczego w celu monitorowania lub blokowania i jest obiecującą koncepcją, która zostanie dodana do arsenału mechanizmów ochrony przed złośliwym oprogramowaniem.
Ustalanie kompleksowej strategii
Zalecana strategia musi łączyć różne techniki w procesie tworzenia oprogramowania, przejmując kontrolę nad aktualizacjami wersji w celu blokowania przychodzących złośliwych komponentów. Musimy uwzględnić przypinanie wersji, aby uniknąć automatycznej infekcji podczas aktualizacji i uzyskać poprawki dla istotnych luk w zabezpieczeniach; musimy również zapewnić szybką i skuteczną ocenę bezpośrednich i pośrednich zależności podczas aktualizacji wersji, aby uzyskać wystarczające dowody na to, że nie są one zainfekowane złośliwym oprogramowaniem. Kompilacje oprogramowania zależne od znanych złośliwych komponentów muszą być blokowane. I wszystkie te zasady muszą być egzekwowane.
W miarę możliwości stosuj przypinanie wersji, ponieważ zwiększa to powtarzalność kompilacji. Przypinanie wersji z kontrolowanymi, ręcznie zatwierdzonymi podbiciami wersji, wspomagane przez technologię pomocniczą, powinien ocenić, czy aktualizacja wprowadza złośliwe oprogramowanie lub je psuje, i pogodzić aktualizację w celu naprawy luk w zabezpieczeniach z unikaniem infekcji złośliwym oprogramowaniem. Narzędzia mogą tu pomóc, (1) ustalając priorytety luk, które są naprawdę istotne (dostępne i podatne na wykorzystanie, z wysokim ryzykiem stania się celem atakujących), (2) wybierając wersje docelowe, które są zgodne z bieżącym wykorzystaniem komponentów i nie psują oprogramowania, (3) wybierając wersje docelowe, które nie zawierają złośliwego zachowania, oraz (4) sprawiając, że aktualizacja wersji dla bezpośrednich i pośrednich zależności jest błyskawiczna, poprzez sugerowanie zmian w plikach manifestu, które można szybko zatwierdzić. Krok (3) wymaga szczegółowych informacji o złośliwych komponentach jak najbliżej czasu ich publikacji.
Ten proces aktualizacji zależności musi być egzekwowane oraz zweryfikowana wszędzie. Proces musi być udokumentowany, a wszystkie zaangażowane strony powinny zostać przeszkolone, ponieważ często rozwój i tworzenie/wdrażanie oprogramowania jest zlecane na zewnątrz. CI/CD pipelines należy odpowiednio zmodyfikować, aby automatyzacja nie pozwoliła na wprowadzenie złośliwej zależności pośredniej do kompilacji: guardrails Zalecanym sposobem jest zablokowanie kompilacji, jeśli istnieje wystarczająco dużo dowodów na potencjalne złośliwe oprogramowanie w zależności.
Jeśli w Twojej organizacji działa wewnętrzny rejestr pełniący funkcję proxy bezpieczeństwa, w którym przechowywane są dozwolone wersje komponentów, musisz uzyskać informacje o złośliwych komponentach (oprócz innych kryteriów) w celu weryfikacji żądanego komponentu przed dodaniem go do listy dozwolonych wersji.
Korzystanie z oprogramowania typu open source w sposób bezpieczny nie jest łatwe, należy w pełni uwzględnić czynnik złośliwego oprogramowania i włożyć podobny wysiłek w zarządzanie lukami w zabezpieczeniach.
Ostatnia uwaga: Pochodzenie źródłowe, w formie atestów oprogramowania, generowanych w czasie kompilacji komponentu, to kolejny kluczowy element w procesie śledzenia artefaktu (pliku tarball komponentu) ze źródłami i procesem kompilacji, który go wygenerował. Należy zauważyć, że to powiązanie między migawką źródłową + środowiskiem kompilacji a powiązanym artefaktem oprogramowania (podpisanym przez zaufany system kompilacji) samo w sobie nie zapobiega złośliwemu zachowaniu komponentu, ale utrudnia cyberprzestępcom wstrzykiwanie złośliwego oprogramowania. Uczynienie walidacji pochodzenia powszechnym wymogiem dla korzystania z komponentów open source zajmie dużo czasu i tylko niedawno dodane do NPM. Uodpornienie zaufanych systemów kompilacji i wdrażania na manipulacje lub umożliwienie wykrywania wszelkich manipulacji w kompilacji to zupełnie inna historia, wykraczająca poza zakres tego wpisu.
Dalsze czytanie
Następny odcinek Złośliwe pakiety Open Source: podejście Xygeni przedstawi strategię, którą stosujemy w Xygeni dla naszego Wczesne ostrzeganie przed złośliwym oprogramowaniem (MEW). Nowe wersje pakietów w publicznych rejestrach pakietów i obrazów są skanowane, a dowody są pozyskiwane za pomocą kombinacji analizy statycznej, dynamicznej, analizy możliwości i analizy kontekstowej. Dowody, w połączeniu z reputacją użytkowników i historią zmian w repozytoriach kodu źródłowego, umożliwiają w pełni zautomatyzowaną klasyfikację komponentu do kategorii wysokiego ryzyka i potencjalnie złośliwych. System uczy się na podstawie wcześniejszych dowodów zebranych z pakietów, aby zminimalizować liczbę fałszywych trafień.
Subskrybowane organizacje otrzymują powiadomienie ostrzegawcze dotyczące komponentów, z których korzystają, bezpośrednio lub pośrednio, w przypadku sklasyfikowania złośliwej wersji. Następnie nasi analitycy przeprowadzają ręczną analizę, która potwierdza lub odrzuca klasyfikację. W przypadku potwierdzonego złośliwego oprogramowania, rejestr publiczny jest powiadamiany, aby mógł przeprowadzić własną analizę i zazwyczaj usunąć złośliwą wersję lub podjąć dodatkowe działania, takie jak zablokowanie lub usunięcie konta użytkownika.
Wyjaśnimy, jak pomagamy NPM, PyPI, GitHub i innym kluczowym infrastrukturom w ekosystemie open source skrócić czas, przez jaki nowy, opublikowany złośliwy komponent pozostaje aktywny, dopóki nie zostanie potwierdzony jako malware i usunięty z rejestru. A także, w jaki sposób organizacje mogą skorzystać z systemu MEW, aby uzyskać znacznie lepszą ochronę przed atakami na łańcuch dostaw oprogramowania z wykorzystaniem komponentów open source.
- [1] W każdym razie użytkownicy komponentu muszą sprawdzić, czy archiwum komponentu jest gdzieś buforowane lub zarejestrowane, np. w wewnętrznym rejestrze, aby wyeliminować problem.
- [2] Spakowany komponent zawiera manifest, który deklaruje jego zawartość i metadane, kod źródłowy lub skompilowany, skrypty instalacyjne oraz dodatkowe elementy, takie jak zestawy testów, zgodnie z formatem pakietu i zazwyczaj w formie skompresowanej. Nazywa się to „archiwum komponentu”.
- [3] Nawet jeśli osoba naruszająca zasady może zmodyfikować opublikowany komponent z powodu naruszenia samego rejestru, zwykły kryptograficzny kod może wykryć każdą zmianę w pliku tarball po zakończeniu analizy.
- [4] Należy pamiętać, że niektóre złośliwe komponenty są uruchamiane w czasie instalacji, więc mogą one wpłynąć na węzły deweloperskie, które nieświadomie uruchomią „npm install X” zawierające złośliwy komponent.
