Red team vs blue team
Napastnicy rzadko celują w Państwa firmę. Celują w pakiet, akcję lub narzędzie buildu, od których zależą firmy na całym świecie, a potem próbują exploitu na wszystkich naraz. Nie potrzebują listy Państwa zależności. Państwo jej potrzebują.
Atak na łańcuch dostaw oprogramowania przejmuje coś, z czego powstaje produkt, na przykład pakiet open source, komponent CI/CD lub system buildu, zamiast atakować sam produkt. Współczesne oprogramowanie to w większości cudzy kod: większość pochodzi z pakietów open source, a większość z nich to zależności przechodnie, których nikt w zespole nie wybrał. Przejęcie jednego powszechnie używanego komponentu daje dostęp do każdej organizacji, która na nim buduje.
To zmienia sposób wybierania celów przez napastników. Nie badają zależności jednej firmy. Wybierają pakiet lub narzędzie o dużym zasięgu, a następnie wykorzystują je wszędzie i patrzą, co odpowie.
Ujawniona zostaje luka w popularnym pakiecie open source, a napastnicy wykorzystują ją w każdym produkcie zawierającym podatną wersję, zwykle jako zależność przechodnią, której nikt nie wybrał bezpośrednio.
Napastnik przejmuje konto opiekuna lub robak kradnie tokeny publikacji, a następnie wychodzi zatruta wersja zaufanego pakietu. Działa ona w chwili, gdy build ją instaluje, jak w przypadku robaka npm Shai-Hulud.
Współtwórca z czasem zdobywa zaufanie w projekcie open source, a potem przemyca złośliwy kod do wydania, które przejmują dystrybucje i produkty downstream, jak w przypadku tylnej furtki w xz utils.
Pakiety o nazwach zbliżonych do popularnych wyłapują literówki. Dependency confusion idzie dalej: publiczny pakiet o tej samej nazwie co wewnętrzny pakiet firmy zostaje zainstalowany zamiast niego.
Zostaje przejęta akcja GitHub lub inne narzędzie buildu, a każdy korzystający z nich pipeline uruchamia kod napastnika, mając w zasięgu swoje sekrety, jak w przypadku tj-actions i Codecov.
Zmieniony zostaje sam build albo artefakt jest podmieniany między buildem a wdrożeniem, więc czyste drzewo źródłowe nadal daje przejęte wydanie, jak w przypadku SolarWinds.
SolarWinds to najbardziej znany atak na łańcuch dostaw: złośliwy kod umieszczony na etapie buildu i dostarczony klientom jako zwykła aktualizacja. Najnowsze ataki celują natomiast w rejestry pakietów i pipeline'y CI, gdzie jeden przejęty pakiet lub akcja dociera do każdego buildu, który z nich korzysta. Od najnowszych:
Samorozprzestrzeniający się robak, który uruchamia się po instalacji zainfekowanego pakietu npm, kradnie tokeny npm, GitHub i chmury oraz publikuje zainfekowane wersje innych pakietów ofiary. Większość infekcji miała miejsce w CI.
Jak sprawdzić swoje buildy →CISA poinformowała, że każda wersja tej popularnej akcji GitHub była przejęta przez trzy dni, a sekrety zostały ujawnione w logach workflow. Workflow odwołujące się do niej przez tag uruchamiały kod napastnika.
Andres Freund znalazł tylną furtkę w wersjach xz 5.6.0 i 5.6.1, gdy zauważył, że logowania SSH zużywają zbyt dużo CPU. Wprowadzono ją do samego projektu upstream.
Luka w Apache Log4j 2 pozwalała napastnikowi kontrolującemu logowany komunikat uruchomić dowolny kod, z oceną CVSS 10.0. Dla większości zespołów najtrudniejsze było ustalenie, które aplikacje zawierają log4j-core, zwykle jako zależność zależności.
Napastnicy zmienili skrypt Bash Uploader uruchamiany przez zespoły w pipeline'ach CI, tak aby wysyłał środowisko CI, w tym poświadczenia, tokeny i klucze, na serwer poza infrastrukturą Codecov. Działał niezauważony od 31 stycznia, aż klient zgłosił to 1 kwietnia.
Napastnicy mieli długotrwały, ukryty dostęp do procesu buildu SolarWinds Orion i umieścili złośliwy kod w wydaniach Orion od 2019.4 do 2020.2.1 HF1, które klienci instalowali jako zwykłe aktualizacje. CISA wydała w odpowiedzi dyrektywę nadzwyczajną.
Red team vs blue team
Każdy etap słowami napastnika, a obok odpowiedź obrony.
Etap 1 z 3
Nie trzeba znać celu. Wybieramy pakiet, a cele wybierają się same.
Red team
Nie potrzebujemy ich lockfile. Popularne pakiety siedzą głęboko w drzewie przechodnim niemal wszystkiego, a większość zespołów nie potrafi powiedzieć, które z nich dostarcza. Publiczne ślady zawężają wybór: wersje w bundlach JavaScript i nagłówkach HTTP, publiczne repozytoria i obrazy kontenerów. A tego, co ich build pobiera poza lockfile, jak plik binarny pobierany przez skrypt postinstall czy warstwy pod ich obrazem bazowym, ich skaner nigdy nie widział, więc nikt tego nie łata.
Blue team
CRACI widzi ruch wchodzący do każdego buildu i rejestruje każdy pobierany pakiet i plik, łącznie z ukrytymi zależnościami, które pomijają narzędzia oparte na lockfile, na każdym poziomie drzewa przechodniego. Państwa SBOM pochodzi z buildu, który dostarczono, więc mają Państwo listę, której napastnik nigdy nie potrzebował, zanim ktokolwiek zacznie jej szukać.
SBOM-y z czasu buildu →Red team
Nowy biuletyn mówi nam dokładnie, które wersje są podatne. Budujemy exploit, skanujemy wszystko, co odpowiada, a skan mówi nam, kim są. Zaczynamy tego samego dnia, gdy ich zespół wciąż pyta na Slacku: „Czy nas to dotyczy?”.
Blue team
CRACI na bieżąco ponownie ocenia monitorowane SBOM-y względem nowych danych o podatnościach. Historia buildów pokazuje, które buildy zawierały podatną zależność, bezpośrednią lub przechodnią, dzięki czemu wiedzą Państwo, gdzie ją dostarczono i jak długo.
Czy nas to dotyczy? →Etap 2 z 3
Wykorzystujemy lukę, zanim zostanie załatana, albo pomijamy lukę i jedziemy ich pipeline'em.
Red team
AI zamienia biuletyn i diff poprawki w działający atak, zanim ich zespół bezpieczeństwa zdąży zająć się zgłoszeniem. Ujawnienie to dla nas strzał startowy. Ich planowanie sprintu jest w przyszłym tygodniu.
Blue team
Bramki polityk mogą blokować każdy build zawierający określoną CVE, dzięki czemu podatna wersja przestaje być dostarczana w chwili, gdy Państwo tak zdecydują, niezależnie od tego, jak głęboko w drzewie się znajduje.
Naprawa CVE →Red team
Workflow ufają tagom takim jak @v4, a tagi można przenosić. Wystarczy przejąć jedną popularną akcję GitHub, a każdy workflow, który jej używa, uruchomi nasz kod z ich sekretami w zasięgu.
Blue team
CRACI zapisuje akcje GitHub uruchamiane przez workflow w SBOM buildu, przypięte do commita, który faktycznie został uruchomiony. Gdy akcja zostanie przejęta, widzą Państwo, które buildy uruchomiły zły kod, zamiast zgadywać na podstawie tagu.
Checklista bezpieczeństwa CI/CD →Etap 3 z 3
Zabieramy sekrety i zostajemy na dłużej.
Red team
Złośliwe wydanie pakietu uruchamia swój skrypt instalacyjny w ich buildzie, tam gdzie znajdują się tokeny i poświadczenia chmurowe. Runnery CI zwykle mają dostęp do całego internetu, więc sekrety odlatują na nasz serwer, zanim ktokolwiek się dowie, że pakiet jest zły.
Blue team
Polityka ruchu wychodzącego z domyślną odmową pozwala buildowi łączyć się z jego źródłami pakietów i celami publikacji, a blokuje wszystko inne. Złośliwe oprogramowanie wysyłające Państwa sekrety na host napastnika zostaje zablokowane, nawet jako pacjent zero ataku, którego nikt wcześniej nie widział, a Państwo otrzymują alert o naruszeniu polityki.
Polityki ruchu wychodzącego →Red team
Długo działające runnery self-hosted to prezent: wystarczy podłożyć coś w przestrzeni roboczej lub cache narzędzi i poczekać, aż kolejne zadanie i kolejny zestaw sekretów przyjdą do nas same.
Blue team
Każde zadanie CRACI działa we własnej izolowanej maszynie wirtualnej, więc nic, co pozostawi jedno zadanie, nie czeka na kolejne. Nie ma też floty runnerów, którą musieliby Państwo łatać i utwardzać.
Runnery zarządzane a self-hosted →Po ujawnieniu
Napastnik nie musi wiedzieć, że używają Państwo danej zależności. Próbuje exploitu wszędzie i patrzy, co odpowie. Państwa zespół musi wiedzieć, gdzie ta zależność została dostarczona. Różnica polega na tym, czy trzeba tego szukać, a wyścigów co roku przybywa: zob. ile CVE publikuje się każdego dnia.
Red team
Blue team, bez zapisu buildu
Blue team, z CRACI
Żadne pojedyncze zabezpieczenie nie zatrzyma każdego ataku na łańcuch dostaw. Po nałożeniu tych warstw każdy z powyższych etapów staje się trudniejszy. Szczegóły dotyczące pipeline zawiera checklista bezpieczeństwa pipeline CI/CD.
Napastnicy obserwują każdy biuletyn i próbują exploitu na wszystkich w dniu ujawnienia podatności. Nigdy nie potrzebowali listy Państwa zależności. Państwo jej potrzebują. CRACI daje Państwa zespołowi tę listę, pochodzącą z samego buildu, i zamyka drzwi, na które liczą napastnicy: otwarty ruch wychodzący i współdzielone runnery.
To atak na kod, narzędzia lub usługi, z których powstaje produkt, takie jak pakiet open source, komponent CI/CD lub system buildu, a nie na sam produkt. Jedno przejęcie dociera do każdej organizacji korzystającej z danego komponentu.
Robak Shai-Hulud (od 2025 r.) rozprzestrzeniał się przez zainfekowane pakiety npm i kradł sekrety CI. Atak na tj-actions/changed-files (CVE-2025-30066) przejął popularną akcję GitHub. Tylną furtkę w xz utils (CVE-2024-3094) przemycono do biblioteki kompresji w projekcie upstream. Log4Shell (CVE-2021-44228) wykorzystał lukę w powszechnie używanej bibliotece logowania Java. Bash Uploader firmy Codecov (2021) zmieniono tak, aby wysyłał poświadczenia CI na zewnętrzny serwer, a SolarWinds Orion (2020) dostarczał złośliwy kod umieszczony na etapie buildu.
SolarWinds. W 2020 r. napastnicy z ukrytym dostępem do procesu buildu SolarWinds Orion umieścili złośliwy kod w jego wydaniach, a klienci zainstalowali go jako zwykłą aktualizację. Pokazało to, że czyste drzewo źródłowe nie wystarcza: sam build musi być godny zaufania i możliwy do zweryfikowania.
Zwykle nie i nie muszą tego wiedzieć. Większość ataków jest wymierzona w pakiet, a nie w firmę: gdy pojawi się biuletyn, napastnicy próbują exploitu na wszystkim, co może działać na podatnej wersji, i patrzą, co odpowie. Publiczne ślady, takie jak wersje w bundlach JavaScript czy repozytoria open source, pomagają im celować. Asymetria polega na tym, że Państwo tej listy potrzebują: aby wiedzieć, czy problem Państwa dotyczy, trzeba wiedzieć, co dostarczył każdy build, łącznie z tym, co pobrał poza lockfile.
Żadne pojedyncze zabezpieczenie nie zatrzyma ich wszystkich. Należy prowadzić SBOM tego, co dostarcza każdy build, i monitorować go względem nowych biuletynów, przypinać zależności i GitHub Actions, blokować podatne wersje na etapie buildu, ograniczać, z czym mogą się łączyć zadania CI, izolować zadania i ograniczać ich sekrety oraz weryfikować, czy wdrożone artefakty są tymi, które Państwo zbudowali.
Należy commitować lockfile i instalować z niego w CI, a także wyłączyć skrypty instalacyjne tam, gdzie build ich nie potrzebuje (--ignore-scripts w npm). Warto prowadzić zapis tego, które wersje pakietów faktycznie zainstalował każdy build, aby móc szybko sprawdzić stan po ogłoszeniu nowej fali, takiej jak Shai-Hulud. Należy ograniczyć, z czym mogą się łączyć zadania CI, aby złośliwy skrypt instalacyjny nie mógł wysłać Państwa tokenów na zewnątrz, i zrotować każdy token, do którego mogła dotrzeć zainfekowana wersja.
W ćwiczeniach bezpieczeństwa red team odgrywa napastnika, a blue team się broni. Ta strona stosuje ten sam podział: każdy etap ataku na łańcuch dostaw słowami napastnika, a obok odpowiedź obrony.
Znane tak. Złośliwe wydanie z opublikowaną CVE, takie jak tylna furtka w xz, jest oznaczane jak każda inna podatność, a bramka polityki może blokować zawierające je buildy. CRACI nie analizuje zachowania pakietów ani nie ocenia ich reputacji, więc zupełnie nowy złośliwy pakiet pozostaje nieoznaczony, dopóki nie pojawi się biuletyn. Do tego służy polityka ruchu wychodzącego: przy domyślnej odmowie build może się łączyć tylko z potrzebnymi hostami, więc pakiet nie może wysłać Państwa sekretów na zewnątrz, nawet w ataku, którego nikt wcześniej nie widział.