Ataki na łańcuch dostaw oprogramowania stają się coraz powszechniejsze i bardziej niszczycielskie. Na przykład, Gartner przewiduje, że do 2025 roku 45% wszystkich firm doświadczy naruszenia bezpieczeństwa. Ponadto, Cyberbezpieczeństwo podkreśla powagę tego zagrożenia, prognozując oszałamiające 138 miliardów dolarów strat rocznie do 2031 roku. Ogólnie rzecz biorąc, prognozy te podkreślają pilną potrzebę priorytetowego traktowania przez organizacje software supply chain security i wdrożyć solidne środki mające na celu ochronę poufnych danych, operacji i reputacji.
Ponieważ nowoczesne pipelinew dużym stopniu zależą od komponentów zewnętrznych, wzrostu liczby bibliotek innych firm, szybszych cykli rozwoju oprogramowania, złożonych łańcuchów dostaw, braku widoczności, nowych technik ataków, wdrażania oprogramowania jako usługi (SaaS) i ograniczonych zasobów – to wszystko napędza wzrost ataki na łańcuch dostaw oprogramowaniaDlatego organizacje muszą przyjąć kompleksowe i aktywne podejście, aby stawić czoła tym wyzwaniom i chronić swoje łańcuchy dostaw oprogramowania.
Czym jest atak na łańcuch dostaw oprogramowania?
ENISA definiuje Atak na łańcuch dostaw oprogramowania as „naruszenie określonego zasobu, np. infrastruktury dostawcy oprogramowania i oprogramowania komercyjnego, w celu pośredniego zaszkodzenia określonemu celowi lub celom, np. klientom dostawcy oprogramowania”. Innymi słowy, atak na łańcuch dostaw oprogramowania to złośliwe działanie wymierzone w łańcuch dostaw oprogramowania, mające na celu naruszenie bezpieczeństwa i wprowadzenie luk w zabezpieczeniach lub złośliwego oprogramowania do procesu rozwoju i dystrybucji. W rezultacie tego typu atak wykorzystuje powiązaną i często skomplikowaną sieć procesów, narzędzi i podmiotów zaangażowanych w tworzenie i dostarczanie oprogramowania.
Kluczowe komponenty i koncepcje związane z atakiem na łańcuch dostaw oprogramowania
Literatura dotycząca wywiadu cyberzagrożeń i bezpieczeństwa informacji często zawodzi ataki na łańcuch dostaw oprogramowania na odrębne kategorie w celu lepszej analizy i obrony. W związku z tym w tej sekcji przedstawiono pięć kluczowych pojęć zdefiniowanych przez Katalog wzorców ataków MITREW tym katalogu uporządkowano wzorce ataków na łańcuch dostaw, aby ułatwić analizę z wykorzystaniem różnych źródeł, w tym zagrożeń ze strony przeciwników zebranych przez NIST.
Akt ataku: Co
Atak to konkretne działanie, które polega na dostarczeniu do systemu szkodliwego ładunku lub intencji. W rezultacie powoduje to bezpośrednie szkody.
- Przykład 1: Złośliwe oprogramowanie wprowadzone do oprogramowania systemowego w trakcie procesu kompilacji.
- Przykład 2: Wymagania systemowe lub dokumenty projektowe zostały zmienione w sposób złośliwy.
Wektor ataku: Jak
Wektor ataku to metoda, której przeciwnicy używają do wykorzystywania luk w zabezpieczeniach lub przetwarzania słabych punktów. W konsekwencji pokazuje on, w jaki sposób atakujący uzyskują dostęp do powierzchni ataku i ją wykorzystują.
- Przykład 1: Atakujący modyfikuje kod źródłowy w zainfekowanym repozytorium.
- Przykład 2: Atakujący uzyskuje nieautoryzowany dostęp do wewnętrznej dokumentacji technicznej.
Dowiedz się więcej w naszym Słownik wektorów ataku w celu uzyskania dodatkowych spostrzeżeń.
Pochodzenie ataku: The Who
Źródło identyfikuje źródło ataku, a zatem wyjaśnia rolę, status lub relację atakującego z systemem.
- Przykład 1: Użytkownik z dostępem uprzywilejowanym do serwerów kompilacji modyfikuje skrypt.
- Przykład 2: Zewnętrzny sprawca zagrożenia przesyła zainfekowany pakiet do rejestru publicznego.
Cel ataku: Dlaczego
Cel wyjaśnia powód ataku. Przede wszystkim wskazuje, co przeciwnicy chcą osiągnąć.
- Zakłócenie: zatrzymanie usług lub kompilacji.
- Korupcja: obniżanie zaufania poprzez zmianę artefaktów lub kodu źródłowego.
- Ujawnienie: ujawnienie poufnych informacji lub własności intelektualnej.
Wpływ ataku: konsekwencje
Na koniec, wpływ opisuje rezultaty ataku, pokazując konsekwencje dla dostawców oprogramowania i klientów.
- Przykład 1: Każdy projekt wykorzystujący błędny program zostanie później uszkodzony.
- Przykład 2: Ludzie instalują złośliwe oprogramowanie w swoich systemach w pracy, nie zdając sobie z tego sprawy.
Najczęstsze ataki na łańcuch dostaw oprogramowania
Liczne rodzaje ataki na łańcuch dostaw oprogramowania istnieją, a organizacje muszą być świadome różnych wektorów zagrożeń na każdym etapie cyklu życia. Na podstawie struktura SLSA, Narodowy Instytut USA Standardi technologii (NIST), Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA)Zagrożenia te można podzielić na cztery kategorie: ryzyko źródłowe, kompilacji, pakietu i zależności.
Ataki na łańcuch dostaw oprogramowania na etapie źródłowym
- Prześlij zły kod → zobacz jak Żądanie Flask.Nadużycie or niebezpieczne błędy deserializacji tworzyć powierzchnie bezpośredniego ataku.
- Repozytorium źródeł kompromisu
- Kompilacja ze zmodyfikowanego źródła
- Napisz niebezpieczny kod
- Manipulowanie krytycznymi plikami → zgodnie z wyjaśnieniem w analiza tylnych drzwi chmod 777.
Ataki na łańcuch dostaw oprogramowania na etapie kompilacji
W Etap budowy, programiści kompilują i integrują kod w celu utworzenia wersji roboczej. Bo ta faza jest tak krytyczna, że istnieje ryzyko pominięcia kontroli bezpieczeństwa CI/CD pipeline, zmieniając kod po kontroli wersji lub narażając proces kompilacji. w konsekwencji, złośliwy kod może wkraść się do artefaktów niezauważony.
- Obejście CI/CD → połączony z Oprogramowanie złośliwe prekompilowane w GitHub.
- Modyfikuj kod po kontroli źródła
- Proces kompilacji kompromisu → złagodzony dzięki Wczesne wykrywanie ostrzeżeń DevSecOps.
- Repozytorium artefaktów kompromisowych
Ataki na łańcuch dostaw oprogramowania na etapie pakietu
Etap pakietu To moment, w którym składamy cały kod, aby stworzyć produkt finalny. Ten etap jest ryzykowny, ponieważ ktoś może użyć wadliwych pakietów lub zmienić źródła internetowe, z których je pobieramy. Atakujący mogą nawet przesyłać szkodliwe wersje popularnych pakietów na te strony.
- Użyj zagrożonego pakietu → objęte oceny skanera złośliwego oprogramowania.
- Rejestr pakietów kompromisowych
- Prześlij zmodyfikowany pakiet → przeanalizowano w Namso-gen – fałszywe oprogramowanie generujące złośliwe oprogramowanie.
Ataki na łańcuch dostaw oprogramowania w fazie zależności
W Etap zależnościDodajemy biblioteki i pakiety innych firm do naszego oprogramowania. Ten etap jest ryzykowny, ponieważ wszelkie problemy w tych częściach mogą łatwo i dyskretnie rozprzestrzenić się na resztę projektu.
- Użyj zagrożonej zależności → wyjaśnione Ryzyko DoS w przypadku ukrytych zależności.
- Nieaktualne lub podatne na ataki zależności
- Ryzyko zależności przechodniej
- Rejestry złośliwych pakietów → łagodzone za pomocą Narzędzia bezpieczeństwa DevOps oraz zarządzanie ryzykiem stron trzecich.
Typowe ryzyka w łańcuchu dostaw na każdym etapie SDLC
| STAGE | Typowe zagrożenia | Przykład |
|---|---|---|
| Źródło | • Przesyłanie złośliwego lub niebezpiecznego kodu • Manipulowanie krytycznymi plikami • Naruszenie repozytorium źródłowego | XcodeGhost (2015): złośliwy kod wstrzyknięty do kompilatora Xcode firmy Apple, rozprzestrzeniający się w aplikacjach iOS. |
| Buduj | • Omijanie CI/CD kontrole bezpieczeństwa • Modyfikowanie kodu po kontroli źródła • Naruszanie repozytoriów artefaktów | SolarWinds Orion (2020): atakujący zinfiltrowali kompilację pipeline, wstawiając furtkę do podpisanych aktualizacji oprogramowania. |
| Pakiet | • Przesyłanie zmodyfikowanych pakietów • Rejestry opakowań zatruć • Dystrybucja zagrożonych artefaktów | Strumień zdarzeń NPM (2018): atakujący umieścił tylne drzwi w popularnym pakiecie NPM pobranym tysiące razy. |
| Zależność | • Korzystanie z nieaktualnych lub podatnych na ataki zależności • Wykorzystanie zależności przechodnich • Publikowanie złośliwych pakietów podobnych do siebie | Tylne drzwi XZ Utils (2024): biblioteka kompresji ze złośliwym oprogramowaniem została niemal wprowadzona do dystrybucji Linuksa. |
Typowe techniki ataków na łańcuch dostaw oprogramowania
Według CISWedług raportów A i NIST ataki na łańcuch dostaw oprogramowania można podzielić na trzy główne kategorie.
Jednak ostatnie incydenty pokazują dodatkowe wektory, które deweloperzy muszą zrozumieć.
Poniżej przedstawiamy bardziej szczegółowo najistotniejsze techniki, podając praktyczne przykłady.
Przejmowanie aktualizacji
Atakujący łamią legalne mechanizmy aktualizacji, aby rozpowszechniać złośliwe oprogramowanie.
Na przykład atak NotPetya w 2017 r. wykorzystał ukraiński serwer aktualizacji oprogramowania podatkowego MEDoc, dostarczając
Niszczycielskie oprogramowanie typu wiper podszywające się pod łatkę. Aby bronić się przed tym ryzykiem, zespoły powinny stosować wykrywanie zagrożeń i reagowanie na nie dla DevOps praktyki sygnalizujące nietypowe zachowania w przepływach aktualizacji.
Podważanie podpisywania kodu
Technika ta polega na nadużywaniu lub kradzieży ważnych certyfikatów podpisu w celu nadania złośliwemu kodowi pozorów legalnego.
Znanym przypadkiem był atak na CCleaner w 2017 r., kiedy atakujący rozpowszechniali zainfekowane oprogramowanie podpisane ważnymi certyfikatami.
W związku z tym organizacje potrzebują ujednoliconych kontroli integralności, takich jak opisane w strategie platformy cyberbezpieczeństwa
Kompromitowanie kodu Open Source
Przeciwnicy umieszczają tylne drzwi w popularnych pakietach open-source, które później są wdrażane w tysiącach projektów.
Incydent EventStream NPM i tylne wejście XZ Utils (2024) ilustrują, jak istotny stał się ten wektor.
Deweloperzy powinni zapoznać się z takimi zasobami jak Najczęściej zadawane pytania dotyczące bezpieczeństwa NPM oraz incydenty związane z typosquattingiem pakietów aby dowiedzieć się, jak unikać zatruwających uzależnień.
Zamieszanie związane z zależnością
Atak ten, opisany po raz pierwszy przez Alexa Birsana w 2021 r., wykorzystuje kolizje nazw między wewnętrznymi i publicznymi rejestrami pakietów, co powoduje, że systemy kompilacji pobierają złośliwe wersje zamiast zaufanych pakietów wewnętrznych.
Typosquatting i złośliwe pakiety
Napastnicy publikują złośliwe pakiety o nazwach podobnych do nazw popularnych bibliotek (np. „requests” zamiast „requests”).
Programiści instalują je przypadkowo, wprowadzając złośliwe oprogramowanie do swoich projektów.
W artykule przeanalizowano rzeczywisty przykład Szkodliwe oprogramowanie Namso-gen i na naszej liście skanery złośliwego oprogramowania o otwartym kodzie źródłowym.
Buduj Pipeline Manipulowanie
Jak widać na przykładzie ataku na SolarWinds Orion, atakujący mogą zinfiltrować serwery kompilacji i wstrzyknąć złośliwy kod podczas kompilacji.
To sprawia, że cały podpisany łańcuch artefaktów jest niewiarygodny. Techniki zapobiegania obejmują monitorowanie CI/CD integralność z wczesne wykrywanie ostrzeżeń i analizowanie
GitHub wstępnie skompilował kampanie malware.
Jak wygląda atak na łańcuch dostaw oprogramowania: przypadek SolarWinds
Przede wszystkim atak na SolarWinds Orion jest najbardziej znanym przykładem naruszenia łańcucha dostaw oprogramowania. Pokazuje on, jak atakujący mogą krok po kroku poruszać się w procesie kompilacji i w rezultacie rozprzestrzeniać szkodliwy kod na tysiące użytkowników.
Najpierw atakujący włamali się do serwerów kompilacji SolarWinds.
Następnie po cichu dodali złośliwy kod do aktualizacji Oriona.
Ponieważ aktualizacje te zostały podpisane i dostarczone jako zaufane oprogramowanie, wiele firm zainstalowało je nie zdając sobie sprawy z ryzyka.
Ogółem atak dotknął ponad 18 000 organizacji, a atakujący uzyskali dostęp do bardzo wrażliwych systemów.
Z punktu widzenia programisty atak ten daje trzy proste lekcje:
- Obrona obwodowa nie wystarczy:atakujący zmienili kompilację pipeline sama.
- Ciągłe kontrole są kluczowe:bezpieczny build attestations, kontrole integralności i wykrywanie anomalii pomagają blokować próby manipulacji.
- Jedna zatruta kompilacja może stać się globalna:pojedynczy pipeline kompromis może doprowadzić do światowego kryzysu bezpieczeństwa.
Xygeni: najlepsza kompleksowa platforma AppSec
Ponieważ ataki na łańcuch dostaw oprogramowania mogą mieć miejsce na każdym etapie SDLC,
kompleksowa platforma AppSec, Xygeni, chroni etapy kodu źródłowego, kompilacji, pakietów i zależności. Zapewnia programistom i zespołom ds. bezpieczeństwa jedno miejsce, w którym można w prosty sposób zapobiegać zagrożeniom, wykrywać je i naprawiać. W rezultacie nie trzeba już żonglować wieloma narzędziami – Xygeni obejmuje cały cykl życia.
Ochrona stopnia źródłowego
Na etapie źródłowym ryzyko obejmuje niebezpieczne commits, zatrute repozytoria lub zmienione pliki. Xygeni skanuje kod w czasie rzeczywistym z głębokim SAST i wykrywanie tajemnic.
Blokuje również szkodliwe commits przez CI/CD guardrails.
W ten sposób problemy są zatrzymywane zanim opuszczą repozytorium.
Zbuduj ochronę sceny
Na etapie kompilacji atakujący mogą próbować ominąć pipelinelub zmieniać artefakty.
Xygeni zabezpiecza proces kompilacji z weryfikacją zgodną ze standardem SLSA, walidacją integralności i podpisami bezkluczykowymi. Monitoruje również nietypowe zachowania wewnątrz CI/CD W rezultacie zmodyfikowane kompilacje są natychmiast oznaczane i blokowane przed wydaniem.
Ochrona etapu pakietu
Na etapie pakietu, zainfekowane rejestry lub zmodyfikowane biblioteki często wprowadzają złośliwe oprogramowanie. Wykrywanie złośliwego oprogramowania i skanowanie licencji Xygeni przejrzyj każdy artefakt, podczas gdy AutoFix sugeruje bezpieczne ścieżki aktualizacji z analizą ryzyka remediacji. Tylko zweryfikowane i zgodne pakiety przechodzą dalej pipeline.
Ochrona etapu zależności
Kod stron trzecich jest najczęstszą powierzchnią ataku. Analiza składu oprogramowania firmy Xygeni (SCA) Robi więcej niż tylko listę luk CVE, ale sprawdza, czy ryzykowny kod rzeczywiście może zostać wykorzystany. Oznacza również ukryte złośliwe oprogramowanie i ryzykowne zależności przechodnie. Przede wszystkim zapewnia to, że programiści dostarczają wyłącznie bezpieczne zależności.
Tajemnice i bezpieczeństwo infrastruktury
Oprócz kodu i pakietów, ataki często wykorzystują wykradzione poufne informacje lub słabą infrastrukturę. Xygeni skanuje w poszukiwaniu ujawnionych kluczy, tokenów i danych uwierzytelniających w kodzie, konfiguracjach i warstwach Dockera. Może również weryfikować i automatycznie unieważniać ujawnione sekrety za pomocą Naprawa AutoFix, W tym samym czasie, IaC skanowanie zapobiega błędnym konfiguracjom, które atakujący mogliby później wykorzystać.
Inteligentniejsze wykrywanie i naprawianie
Większość narzędzi zatrzymuje się na alertach. Xygeni idzie dalej. Silnik AutoFix tworzy bezpieczne poprawki, pull requestslub wskazówki krok po kroku, w zależności od problemu. Widok ryzyka naprawczego pokazuje również, która wersja poprawki jest najbezpieczniejsza, dzięki czemu zespoły mogą rozwiązywać problemy bez dodawania nowych.
Jedna ujednolicona platforma
Ponieważ Xygeni łączy SAST, SCA, wykrywanie złośliwego oprogramowania, zarządzanie sekretami, IaC skanowanie, wykrywanie anomalii i bezpieczne sterowanie kompilacją na jednej platformie AppSec,
zapewnia pełne pokrycie na całym SDLCZarówno programiści, jak i zespoły ds. bezpieczeństwa zyskują jedno źródło prawdy z przejrzystym obrazem, praktycznymi rozwiązaniami i solidną ochroną przed atakami na łańcuch dostaw.
Biorąc wszystko pod uwagę, Xygeni – najlepsza platforma typu „wszystko w jednym” do zabezpieczania aplikacji, pomaga zespołom szybko tworzyć i zachować bezpieczeństwo. Chroniąc kod źródłowy, kompilację, pakiety i zależności oraz dodając automatyczne poprawki na każdym etapie, zapewnia zatrzymanie ataków na łańcuch dostaw oprogramowania, zanim dotrą one do środowiska produkcyjnego.
