Nowa klasa słabości workflow CI/CD może pozwolić atakującym wykorzystać złośliwe pull requesty do naruszenia bezpieczeństwa łańcucha dostaw oprogramowania.
Słabość, nazwana Cordyceps, została ujawniona przez Elada Megeda, founding engineera i badacza bezpieczeństwa w firmie Novee. Dotyczy tego, jak zautomatyzowane workflow przetwarzają niezaufane dane z pull requestów w repozytoriach kodu.
Pull requesty odgrywają kluczową rolę we współczesnym tworzeniu oprogramowania. Pozwalają programistom proponować zmiany, recenzować kod, uruchamiać automatyczne kontrole i scalać aktualizacje z główną gałęzią. Jednak gdy workflow CI/CD działają ze zbyt szerokimi uprawnieniami albo przetwarzają niezaufane dane bez odpowiedniej izolacji, pull request może stać się czymś więcej niż propozycją zmiany w kodzie.
Może stać się ścieżką ataku.
Cordyceps pokazuje, że zagrożenie często nie wynika z jednego uszkodzonego komponentu. Wynika z tego, jak ze sobą oddziałują zaufana automatyzacja, sekrety, tokeny, komentarze, wyzwalacze workflow i zewnętrzni współtwórcy.
Czym jest Cordyceps?
Cordyceps to klasa słabości łańcucha dostaw oprogramowania, która dotyczy workflow CI/CD obsługujących pull requesty.
Problem pojawia się wtedy, gdy workflow przetwarzają dane z pull requestów kontrolowane przez atakującego, a jednocześnie dysponują podwyższonymi uprawnieniami, kluczami podpisującymi, tokenami dostępu lub innymi wrażliwymi poświadczeniami.
W wielu repozytoriach workflow CI/CD potrzebują szerokiego dostępu, aby wykonywać swoje zadania. Mogą budować kod, uruchamiać testy, publikować pakiety, podpisywać wydania, aktualizować wyniki kontroli, komentować pull requesty lub uzyskiwać dostęp do projektów w chmurze.
Taki dostęp jest potężny.
Jeśli atakujący zdoła wpłynąć na sposób uruchamiania tych workflow, może być w stanie wykonać kod, wykraść poświadczenia, sfałszować wyniki kontroli, obejść bramki scalania, opublikować złośliwe pakiety lub zaatakować dalszych użytkowników.
Workflow może robić dokładnie to, do czego został skonfigurowany. Podatność tkwi w samym zestawieniu elementów: niezaufane dane przekraczają granicę zaufania, której nikt nie poddał audytowi.
Dlaczego pull requesty stanowią ryzyko dla łańcucha dostaw oprogramowania
Pull requesty są projektowane tak, aby przyjmować dane od zewnętrznych współtwórców, zwłaszcza w projektach open source.
Ta otwartość jest zaletą, ale tworzy ryzyko, gdy automatyzacja traktuje zawartość pull requestów, komentarze, metadane lub gałęzie jako zaufane.
Atakujący mogą przygotować złośliwe pull requesty wymierzone w:
- wyzwalacze workflow
- komentarze przetwarzane przez automatyzację
- nazwy gałęzi
- ścieżki plików
- skrypty kompilacji
- polecenia testowe
- zmienne środowiskowe
- manifesty zależności
- konfigurację CI
- generowane artefakty
- polecenia botów
Jeśli workflow reaguje na takie dane z wysokimi uprawnieniami, atakujący może uzyskać dostęp do zasobów, które powinny być dostępne wyłącznie dla zaufanych opiekunów projektu.
Jest to szczególnie niebezpieczne, ponieważ systemy CI/CD często znajdują się tuż obok procesu wydawniczego.
Co odkryła firma Novee
Firma Novee poinformowała, że jedno skanowanie oznaczyło 654 repozytoria jako potencjalnie podatne na wykorzystanie przez słabości typu Cordyceps.
Spośród nich około 300 potwierdzono jako w pełni możliwe do wykorzystania w celu osiągnięcia takich skutków, jak:
- wykonanie kodu kontrolowanego przez atakującego
- kradzież poświadczeń
- wstrzyknięcie poleceń
- eskalacja uprawnień
- naruszenie łańcucha dostaw oprogramowania
- publikowanie złośliwych pakietów
- sfałszowane kontrole CI
- obejście bramek scalania
- podszywanie się pod boty
- możliwości socjotechniczne
Do podatnych repozytoriów miały należeć zarówno projekty dużych organizacji, jak i mniejszych zespołów.
Ma to znaczenie, ponieważ ataki na łańcuch dostaw oprogramowania skalują się. Słabość w jednym repozytorium może wpłynąć na każdą organizację, która korzysta z jego kodu, pakietów, akcji lub artefaktów.
Przykłady skutków
Novee opisała kilka głośnych przykładów.
W repozytorium Azure Sentinel firmy Microsoft badacze ustalili, że komentarz w pull requeście mógł sprawić, iż środowisko CI Microsoftu uruchamiało kod kontrolowany przez atakującego i umożliwiało kradzież klucza GitHub App bez daty wygaśnięcia.
W Google AI Agent Development Kit pull request mógł rzekomo uruchomić kod atakującego w środowisku CI Google i dać uwierzytelnioną kontrolę nad powiązanym projektem Google Cloud, w tym uprawnienia do repozytorium Google Cloud.
Novee opisała również ataki typu zero-click przez pull requesty dotyczące Apache Doris, Cloudflare Workers SDK oraz projektu Black należącego do Python Software Foundation.
Microsoft i Google miały potwierdzić wpływ problemu. Cloudflare i Apache wprowadziły zabezpieczenia lub poprawki.
Novee zaznaczyła, że nie ma dowodów, by te wzorce workflow były szeroko wykorzystywane na dużą skalę, ale skala narażenia pokazuje, dlaczego projektowanie workflow CI/CD wymaga większej uwagi.
Dlaczego workflow CI/CD są tak potężne
Workflow CI/CD to nie tylko skrypty automatyzujące.
Często mają dostęp do:
- tokenów repozytorium
- poświadczeń chmurowych
- sekretów do publikowania pakietów
- kluczy podpisujących
- uprawnień do wdrażania
- kluczy GitHub App
- magazynów artefaktów
- wewnętrznych rejestrów
- uprzywilejowanych botów
- środowisk produkcyjnych lub testowych (staging)
Oznacza to, że podatny workflow może stać się bezpośrednią drogą od pull requesta do wrażliwej infrastruktury.
Złośliwy PR nie musi zostać scalony, aby wyrządzić szkody, jeśli workflow uruchamia się przed scaleniem i ma dostęp do sekretów lub uprzywilejowanych działań.
Na tym polega sedno problemu: automatyzacja działająca przed scaleniem często przetwarza niezaufane dane, mając jednocześnie zbyt duże zaufanie.
„Kod workflow to kod”
Jedną z najważniejszych lekcji płynących z Cordyceps jest to, że kod workflow trzeba traktować jak kod aplikacji.
Konfiguracja CI/CD jest często pisana w YAML, ale nadal steruje wykonywaniem, uprawnieniami, sekretami, ścieżkami wdrażania i granicami zaufania.
Organizacje często dokładnie recenzują kod aplikacji, a pliki workflow traktują jak konfigurację operacyjną.
To błąd.
Kilka linijek YAML może zdecydować, czy pull request od nieznanego współtwórcy uruchomi uprzywilejowaną automatyzację.
Pliki workflow zasługują na taką samą recenzję, modelowanie zagrożeń, testowanie i przypisanie odpowiedzialności jak kod produkcyjny.
Dlaczego agenci AI do kodowania mogą pogłębić problem
Meged ostrzegał, że agenci AI do kodowania skalują ten problem.
Narzędzia AI potrafią szybko generować konfiguracje CI/CD, ale mogą też wielokrotnie powielać niebezpieczne wzorce.
Jeśli programiści proszą AI o utworzenie workflow i akceptują wynik bez zrozumienia granic zaufania, te same błędy mogą rozprzestrzenić się w wielu repozytoriach.
Jest to szczególnie ryzykowne, ponieważ bezpieczeństwo CI/CD wymaga kontekstu.
Workflow, który jest bezpieczny dla wewnętrznych gałęzi, może być niebezpieczny dla publicznych pull requestów. Token, który jest nieszkodliwy w zadaniu tylko do odczytu, może być katastrofalny w zadaniu publikującym. Bot uruchamiany komentarzem może być przydatny dla opiekunów projektu, ale niebezpieczny, gdy może go wywołać każdy.
Kod workflow generowany przez AI trzeba recenzować równie starannie jak kod pisany przez ludzi.
Typowe wzorce Cordyceps
Problemy typu Cordyceps mogą występować na różne sposoby, w zależności od konstrukcji repozytorium.
Typowe ryzykowne wzorce to między innymi:
- uruchamianie niezaufanego kodu z pull requestów z uprawnieniami do zapisu
- udostępnianie sekretów workflow wyzwalanym przez zewnętrznych współtwórców
- niebezpieczne używanie
pull_request_target - wykonywanie poleceń na podstawie komentarzy w PR
- ufanie nazwom gałęzi, ścieżkom plików lub metadanym
- używanie poleceń botów bez sprawdzania autoryzacji autora
- pozwalanie workflow na publikowanie artefaktów z niezaufanego kodu
- przyznawanie szerokich tokenów repozytorium lub organizacji
- używanie długotrwałych poświadczeń bez daty wygaśnięcia
- mieszanie zadań walidacyjnych z uprzywilejowanymi zadaniami wdrożeniowymi
- traktowanie kontroli generowanych przez CI jako wiarygodnych bez ochrony samego workflow
Szczegóły są różne, ale sedno problemu pozostaje takie samo: niezaufane dane znajdują się zbyt blisko uprzywilejowanej automatyzacji.
Dlaczego skanery mogą to przeoczyć
Cordyceps może być trudny do wykrycia dla tradycyjnych skanerów, ponieważ każdy pojedynczy komponent może wyglądać na działający poprawnie.
Workflow wyzwala się zgodnie z konfiguracją. Token ma uprawnienia, które mu przypisano. Bot przetwarza komentarze tak, jak zaprojektowano. Zadanie kompilacji działa normalnie.
Słabość staje się widoczna dopiero wtedy, gdy cały przepływ zostanie przeanalizowany jako system.
Zespoły bezpieczeństwa muszą zadać sobie pytania:
- Kto może wyzwolić ten workflow?
- Jaki kod on wykonuje?
- Jakie ma uprawnienia?
- Do jakich sekretów ma dostęp?
- Czy niezaufani użytkownicy mogą wpływać na polecenia?
- Czy wyniki niezaufanych zadań mogą wpływać na zadania zaufane?
- Czy ten workflow może cokolwiek publikować, podpisywać, scalać lub wdrażać?
- Czy pull request może zmienić pliki, którym workflow później ufa?
To ryzyko kompozycji, a nie tylko ryzyko związane z kodem.
Co mogliby zrobić atakujący
W razie wykorzystania słabości typu Cordyceps mogłoby dojść do poważnych skutków dla łańcucha dostaw oprogramowania.
Atakujący mogliby być w stanie:
- wykradać tokeny GitHub
- wykradać poświadczenia chmurowe
- uzyskiwać dostęp do sekretów rejestrów pakietów
- publikować złośliwe pakiety
- modyfikować artefakty wydań
- fałszować pomyślne kontrole CI
- obchodzić ochronę gałęzi
- podszywać się pod boty lub opiekunów projektu
- wstrzykiwać złośliwe zależności
- naruszać bezpieczeństwo projektów w chmurze
- wdrażać złośliwy kod
- uzyskiwać dostęp do prywatnych repozytoriów
- przemieszczać się do infrastruktury organizacji
W projektach open source skutki mogą rozprzestrzenić się na dalszych użytkowników. W przedsiębiorstwach może to zagrozić wewnętrznym systemom kompilacji, ścieżkom wdrażania i środowiskom produkcyjnym.
Zalecenia dotyczące ochrony
Organizacje powinny zacząć od inwentaryzacji workflow, które działają na niezaufanych danych.
Kluczowe pytania to między innymi:
- Które workflow działają na pull requestach z forków?
- Które workflow używają
pull_request_target? - Które workflow przetwarzają komentarze w PR?
- Które workflow mają uprawnienia do zapisu?
- Które workflow mają dostęp do sekretów?
- Które workflow publikują pakiety lub artefakty?
- Które workflow wdrażają do środowisk chmurowych?
- Które boty mogą być uruchamiane przez osoby niebędące opiekunami projektu?
Po zidentyfikowaniu ryzykownych workflow zespoły powinny ograniczyć uprawnienia i rozdzielić strefy zaufania.
Zalecane mechanizmy kontroli obejmują:
- stosowanie zasady najmniejszych uprawnień dla tokenów workflow
- unikanie udostępniania sekretów zadaniom niezaufanych pull requestów
- rozdzielenie zadań kompilacji i testów od zadań publikowania i wdrażania
- wymaganie zatwierdzenia przez opiekuna projektu, zanim uruchomią się uprzywilejowane workflow
- unikanie wykonywania kodu kontrolowanego przez PR w kontekstach uprzywilejowanych
- weryfikowanie, kto dodał komentarze w PR, zanim zostaną na ich podstawie wykonane jakiekolwiek działania
- przypinanie akcji firm trzecich do zaufanych skrótów (SHA) commitów
- wymaganie recenzji kodu dla zmian w workflow
- ochronę plików workflow za pomocą CODEOWNERS
- rotację długotrwałych poświadczeń
- stosowanie tokenów krótkotrwałych, gdzie to możliwe
- audyt uprawnień GitHub App
- ograniczenie workflow publikujących pakiety
- monitorowanie uruchomień workflow pod kątem nietypowych poleceń
Celem jest zapewnienie, że niezaufani współtwórcy nie mogą bezpośrednio dotrzeć do zaufanej automatyzacji.
Bezpieczna obsługa automatyzacji pull requestów
Automatyzację pull requestów należy projektować wokół granic zaufania.
Bezpiecznym wzorcem jest uruchamianie niezaufanego kodu z PR w ograniczonym zadaniu, bez sekretów i z minimalnymi uprawnieniami.
Działania uprzywilejowane, takie jak publikowanie, podpisywanie, wdrażanie lub zapis do repozytoriów, powinny być wykonywane dopiero po zatwierdzeniu przez zaufanego opiekuna projektu i wyłącznie z zaufanego kodu.
Organizacje powinny też unikać sytuacji, w której niezaufana treść steruje wykonywaniem poleceń.
Na przykład komentarze w PR nie powinny wyzwalać potężnych workflow, chyba że autor komentarza został zweryfikowany jako opiekun projektu lub zatwierdzony współtwórca.
Nawet wtedy workflow powinien starannie weryfikować dane wejściowe.
Dlaczego sama ochrona gałęzi nie wystarcza
Ochrona gałęzi jest ważna, ale może nie chronić w pełni przed nadużyciem workflow CI/CD.
Jeśli atakujący mogą fałszować kontrole CI, kraść tokeny lub wpływać na uprzywilejowaną automatyzację przed scaleniem, ochrona gałęzi może zostać obejścia lub osłabiona.
Ochronę gałęzi należy łączyć z:
- chronionymi plikami workflow
- ograniczonymi uprawnieniami workflow
- wymaganymi recenzjami zmian w CI
- bezpiecznymi zakresami tokenów
- bramkami zatwierdzania dla zewnętrznych współtwórców
- podpisanymi procesami wydawniczymi
- pochodzeniem artefaktów (provenance)
- monitorowanymi workflow wdrożeniowymi
Ochrona łańcucha dostaw oprogramowania musi obejmować całą drogę od pull requesta do wydania.
Zalecenia dla CISO
CISO powinni traktować workflow CI/CD jako krytyczne zasoby bezpieczeństwa.
Praktyczne kroki obejmują:
- utworzenie inwentarza wszystkich workflow CI/CD
- sklasyfikowanie workflow według poziomu uprawnień
- zidentyfikowanie workflow wyzwalanych niezaufanymi danymi
- przegląd wszystkich workflow, które mają dostęp do sekretów
- egzekwowanie zasady najmniejszych uprawnień dla wszystkich tokenów CI/CD
- wymaganie przeglądu bezpieczeństwa dla zmian w workflow
- określenie odpowiedzialności za bezpieczeństwo workflow
- uwzględnienie CI/CD w modelowaniu zagrożeń
- monitorowanie automatyzacji deweloperskiej pod kątem nadużyć
- stosowanie zaufanych narzędzi do wykrywania ryzykownych wzorców workflow na dużą skalę
- szkolenie zespołów inżynierskich w zakresie granic zaufania w CI/CD
Kluczowa zmiana sposobu myślenia jest prosta: kod workflow to kod i można go wykorzystać tak samo jak kod.
Podsumowanie
Cordyceps pokazuje, jak złośliwe pull requesty mogą stać się drogą do workflow CI/CD i łańcuchów dostaw oprogramowania.
Problemem nie jest jedna konkretna luka CVE ani jeden uszkodzony produkt jakiegoś dostawcy. To klasa słabości konfiguracji i granic zaufania, która może pojawić się wszędzie tam, gdzie programiści automatyzują obsługę pull requestów.
Workflow może „działać zgodnie z założeniami” i mimo to być niebezpieczny.
Dla obrońców przekaz jest jasny: przeglądaj workflow CI/CD z taką samą dokładnością jak kod aplikacji. Ustal, gdzie niezaufane dane spotykają się z uprzywilejowaną automatyzacją, ogranicz uprawnienia, chroń sekrety i wymagaj zatwierdzenia przed uruchomieniem zadań wysokiego ryzyka.
We współczesnych łańcuchach dostaw oprogramowania pull request to nie tylko mechanizm współpracy. Może też być powierzchnią ataku.
