Wprowadzenie do problemu / definicja
GitHub i ekosystem npm wprowadziły dodatkowe zabezpieczenia mechanizmu trusted publishing po ujawnieniu luki, która mogła umożliwić publikację nowych wersji cudzych pakietów bez przejmowania poświadczeń maintainerów. Problem dotyczył sposobu wiązania zaufania między pakietem a repozytorium wykorzystywanym w procesie CI/CD, a więc bezpośrednio wpisywał się w ryzyka związane z bezpieczeństwem łańcucha dostaw oprogramowania.
W praktyce oznacza to, że nawet nowoczesny model publikacji oparty na krótkotrwałych tokenach i OIDC może zostać osłabiony, jeśli relacja zaufania zostanie powiązana z niewłaściwym identyfikatorem zasobu. To właśnie ten błąd stał się osią całego problemu.
W skrócie
Badacze wykazali, że w określonych warunkach zaufane publikowanie mogło zostać oparte na nazwie repozytorium w formacie owner/repository, zamiast na jego trwałym identyfikatorze. Taka różnica otwierała drogę do przejęcia procesu publikacji po zmianie nazwy, transferze lub usunięciu repozytorium.
- Zagrożonych mogło być ponad 1,5 tys. pakietów npm.
- Łączna liczba pobrań tych paczek przekraczała 10 mln.
- Atak nie wymagał kradzieży sekretów ani obejścia MFA.
- GitHub wdrożył wygasanie nowej konfiguracji trusted publisher po 48 godzinach, jeśli nie nastąpi pierwsza poprawna publikacja.
- Dodatkowo ograniczono użycie tokenów trusted publishing dla wybranych zdarzeń w GitHub Actions.
Kontekst / historia
Trusted publishing powstało jako bezpieczniejsza alternatywa dla klasycznego modelu publikacji pakietów z użyciem statycznych tokenów. Zamiast długo żyjących sekretów mechanizm wykorzystuje krótkotrwałe tokeny OIDC generowane przez platformę CI/CD, co redukuje ryzyko wycieku poświadczeń i poprawia kontrolę nad pochodzeniem publikowanych artefaktów.
Założenie było prawidłowe: publikacja pakietu miała być powiązana z konkretnym workflow oraz repozytorium kontrolowanym przez maintainera. Problem ujawnił się jednak w fazie poprzedzającej pierwszą poprawną publikację. W tym okresie relacja zaufania mogła opierać się na nazwie repozytorium, która nie jest trwała i może zostać ponownie zajęta przez inną osobę.
To istotny szczegół, ponieważ nazwa repozytorium może zostać zwolniona w wyniku zmiany nazwy projektu, jego transferu do innej organizacji albo usunięcia. Jeśli taki identyfikator tekstowy zostanie następnie przejęty przez atakującego, istnieje ryzyko niezamierzonego odziedziczenia relacji zaufania.
Analiza techniczna
Rdzeń podatności sprowadzał się do różnicy między dwiema formami identyfikacji repozytorium: czytelną nazwą owner/repository oraz niezmiennym identyfikatorem numerycznym. Z perspektywy bezpieczeństwa tylko drugi z tych identyfikatorów powinien być podstawą zaufania, ponieważ pozostaje stały mimo zmian administracyjnych.
Według opisu problemu przed pierwszą udaną publikacją konfiguracja mogła jednak zostać powiązana wyłącznie ze slugiem repozytorium. To oznaczało możliwość nadużycia w sytuacji, gdy dawny slug stał się ponownie dostępny.
Scenariusz ataku był relatywnie prosty. Jeśli maintainer wcześniej skonfigurował trusted publisher, a później repozytorium zostało przemianowane, przeniesione lub usunięte, atakujący mógł:
- utworzyć nowe repozytorium pod zwolnioną nazwą,
- uruchomić workflow publikacji generujący token OIDC,
- wykorzystać token w procesie wymiany na uprawnienie publikacyjne,
- uzyskać czasowo ważny token pozwalający opublikować nową wersję legalnego pakietu.
Kluczowe jest to, że taki atak nie wymagał kompromitacji konta maintainera, kradzieży sekretów ani przełamania wieloskładnikowego uwierzytelniania. Wystarczało wykorzystanie błędnego zakotwiczenia zaufania w zmiennej nazwie repozytorium.
W odpowiedzi wdrożono dwa ważne mechanizmy ochronne. Po pierwsze, nowa konfiguracja trusted publisher wygasa po 48 godzinach, jeśli nie dojdzie do pierwszej poprawnej publikacji. Po drugie, po udanej pierwszej publikacji relacja zostaje związana z trwałą tożsamością repozytorium. Dodatkowo ograniczono możliwość użycia tokenów trusted publishing w wybranych scenariuszach automatyzacji, aby zmniejszyć powierzchnię nadużyć.
Konsekwencje / ryzyko
Ryzyko dla organizacji korzystających z npm jest poważne, ponieważ dotyczy integralności pakietów uznawanych za zaufane. Gdyby atak został skutecznie przeprowadzony, efektem mogłaby być publikacja złośliwej wersji legalnego pakietu pod jego prawidłową nazwą i z wykorzystaniem istniejącej reputacji projektu.
Szczególnie niebezpieczne jest to w środowiskach, gdzie aktualizacje zależności są pobierane automatycznie, a proces budowania nie wymusza dodatkowej walidacji pochodzenia artefaktów. W takich warunkach pojedyncza złośliwa publikacja może uruchomić efekt domina obejmujący stacje deweloperskie, pipeline’y CI/CD, systemy produkcyjne oraz kolejne artefakty budowane na bazie skażonej zależności.
- Możliwe jest uruchomienie nieautoryzowanego kodu w środowisku ofiary.
- Atakujący może próbować kraść sekrety i tokeny z procesów build.
- Złośliwa paczka może modyfikować pipeline publikacyjny lub wdrożeniowy.
- Istnieje ryzyko osadzenia backdoora i dalszego ruchu bocznego w infrastrukturze.
- Maintainerzy narażają się na utratę reputacji i zaufania użytkowników.
Rekomendacje
Organizacje utrzymujące pakiety npm powinny przeprowadzić audyt konfiguracji trusted publishing i zweryfikować, czy wszystkie relacje zaufania wskazują na aktualnie kontrolowane repozytoria. Szczególną uwagę należy poświęcić projektom, które w ostatnim czasie były przemianowywane, przenoszone między organizacjami lub usuwane i odtwarzane.
- Przeprowadzić pełny przegląd konfiguracji trusted publisher dla wszystkich pakietów npm.
- Usuwać i odtwarzać relacje zaufania po zmianie nazwy, transferze lub usunięciu repozytorium.
- Monitorować niestandardowe publikacje i budować alerty dla nietypowych wersji release.
- Weryfikować provenance i pochodzenie artefaktów tam, gdzie wspierają to narzędzia.
- Ograniczyć automatyczne aktualizacje zależności bez dodatkowej kontroli bezpieczeństwa.
- Stosować polityki dopuszczania pakietów oparte na zaufanych maintainerach, podpisach i attestation.
- Utrzymywać inwentaryzację krytycznych zależności oraz ich ścieżek publikacji.
Dla zespołów AppSec i DevSecOps to przypomnienie, że rezygnacja ze statycznych sekretów nie rozwiązuje wszystkich problemów bezpieczeństwa publikacji. Model bezsekretowy poprawia odporność, ale nadal wymaga poprawnego mapowania tożsamości i ścisłej kontroli bindingów zaufania.
Warto także rozszerzyć procedury repozytoryjnego hygiene i offboardingu. Każda zmiana administracyjna wokół projektu open source powinna uruchamiać checklistę bezpieczeństwa obejmującą rejestry pakietów, workflow publikacyjne, powiązania OIDC oraz zależne procesy automatyzacji.
Podsumowanie
Opisana luka pokazuje, że bezpieczeństwo łańcucha dostaw zależy nie tylko od siły uwierzytelniania, ale również od poprawnego związania zaufania z właściwą i trwałą tożsamością zasobu. W tym przypadku problemem nie był wyciek sekretu, lecz błędne oparcie modelu zaufania na nazwie repozytorium, która mogła zostać przejęta po zmianach administracyjnych.
Wdrożone poprawki znacząco ograniczają możliwość nadużyć, jednak incydent pozostaje ważnym ostrzeżeniem dla maintainerów i organizacji opierających publikację pakietów na automatyzacji CI/CD. Regularne audyty bindingów trusted publishing, kontrola zmian w repozytoriach oraz twarda walidacja pochodzenia artefaktów powinny stać się stałym elementem praktyk bezpieczeństwa.