Ataki na łańcuch dostaw oprogramowania: jak chronić pipeline CI/CD

Utworzone przez Dawid Bakaj • sobota, 30.08.2026, 23:15 • Cyberzagrozenia i ataki – analiza przypadkow

18 maja 2026 roku, w ciagu zaledwie 48 godzin, cyberprzestepcy przeprowadzili piec niezaleznych atakow na lancuch dostaw oprogramowania, ktore jednoczesnie uderzyly w rozszerzenie VS Code z 2,2 miliona instalacji, popularne GitHub Actions, pakiety npm z 1,5 miliona pobran tygodniowo oraz pakiet PyPI nalezacy do Microsoftu. Rezultat? Wykradzione sekrety z tysiecy pipeline’ow CI/CD, skompromitowane konto pracownika GitHuba i eksfiltracja 3 800 wewnetrznych repozytoriow. To nie byl jednostkowy incydent – w pierwszej polowie 2026 roku odnotowano 59 kampanii supply-chain i 657 zlosliwych pakietow, co stanowi 2,6-krotny wzrost liczby kampanii i 4,5-krotny wzrost wolumenu pakietow w porownaniu z calym rokiem 2025. Pipeline CI/CD stal sie najgoretsza powierzchnia ataku w cyberbezpieczenstwie.

Czym jest atak na łańcuch dostaw oprogramowania?

Atak na lancuch dostaw oprogramowania (software supply chain attack) polega na kompromitacji zaufanego komponentu w procesie tworzenia lub dystrybucji oprogramowania. Zamiast atakować docelową organizację bezpośrednio, przestępcy infiltrują narzędzia, biblioteki lub infrastrukturę, której ta organizacja ufa i z niej korzysta.

Współczesny proces wytwarzania oprogramowania (SDLC) opiera się na rozbudowanym łańcuchu zależności:

• Rejestry pakietów (npm, PyPI, Maven) – tysiące bibliotek open-source w każdym projekcie
• Pipeline’y CI/CD (GitHub Actions, GitLab CI, Jenkins) – automatyzacja budowania, testowania i wdrażania
• Narzędzia deweloperskie (IDE, rozszerzenia, CLI tools) – środowisko pracy programistów
• Rejestry kontenerów (Docker Hub, GHCR) – obrazy bazowe i zależności runtime
• Infrastruktura chmurowa (AWS, Azure, GCP) – środowiska produkcyjne

Kompromitacja dowolnego z tych ogniw pozwala atakującemu na dotarcie do tysięcy organizacji za pośrednictwem jednego zhakowanego komponentu. To fundamentalna różnica w porównaniu z tradycyjnymi atakami – zamiast łamać zabezpieczenia każdej ofiary osobno, wystarczy zatruć jedno źródło, któremu wszyscy ufają.

Ewolucja zagrożeń – od SolarWinds do Shai-Hulud

Ataki na łańcuch dostaw nie są zjawiskiem nowym, ale ich skala, częstotliwość i wyrafinowanie rosną w tempie wykładniczym. Poniższa tabela przedstawia kluczowe incydenty, które ukształtowały współczesny krajobraz zagrożeń:

Widoczna jest wyraźna ewolucja – od pojedynczych, zaawansowanych ataków państwowych (SolarWinds) po zautomatyzowane, wielowektorowe kampanie uderzające jednocześnie w wiele warstw ekosystemu deweloperskiego. Szczegółową analizę jednego z takich incydentów znajdziesz w naszym artykule o ataku na łańcuch dostaw PyTorch Lightning.

Anatomia współczesnego ataku – case study: 48 godzin w maju 2026

Między 18 a 19 maja 2026 roku pięć odrębnych kampanii supply-chain uderzyło jednocześnie w każdą warstwę pipeline’u deweloperskiego. Analiza tych ataków ujawnia współczesne techniki i skalę zagrożenia:

1. Nx Console – zatrute rozszerzenie VS Code (2,2 mln instalacji)

Atakujący skompromitowali popularne rozszerzenie Nx Console, wstrzykując wieloetapowy credential stealer. Złośliwy kod wykorzystywał trzy kanały eksfiltracji jednocześnie: HTTPS, GitHub API i tunelowanie DNS. Na systemach macOS instalował dodatkowo trwały backdoor w Pythonie. Jedną z ofiar był pracownik GitHuba – kompromitacja jego urządzenia doprowadziła do eksfiltracji 3 800 wewnętrznych repozytoriów firmy.

2. GitHub Actions – podmiana tagów wersji

Popularne akcje actions-cool/issues-helper i maintain-one-comment zostały skompromitowane poprzez zastąpienie wszystkich tagów wersji złośliwymi commitami. Wstrzyknięty kod wykorzystywał runtime bun do ekstrakcji poświadczeń bezpośrednio z pamięci procesu Runner.Worker. Każdy workflow odwołujący się do tych akcji po tagu wersji automatycznie wykonywał złośliwy kod.

3. Shai-Hulud – samoreplikujący się worm npm

Najbardziej innowacyjny element kampanii. Worm zainfekował pakiety z ekosystemu AntV (Alibaba), echarts-for-react oraz timeago.js (1,5 miliona pobierań tygodniowo). Działanie: odczytywał pamięć procesu GitHub Actions runner, zbierał poświadczenia z ponad 130 ścieżek plików, a następnie wykorzystywał skradzione tokeny npm do propagacji na kolejne pakiety – tworząc samorozprzestrzeniający się łańcuch infekcji.

4. Microsoft durabletask – ztrojanizowany PyPI

Grupa TeamPCP opublikowała trzy złośliwe wersje oficjalnego pakietu Microsoftu durabletask (400 000+ pobrań miesięcznie) w ciągu zaledwie 35 minut. Malware kradł tokeny AWS, Azure, GCP, klucze SSH, poświadczenia Kubernetes oraz dane z ponad 90 konfiguracji narzędzi deweloperskich. Charakterystyczny szczegół: pomijał systemy z rosyjską lokalizacją.

Wektory ataku na pipeline CI/CD

Na podstawie analizy incydentów z lat 2024-2026 można wyróżnić pięć głównych wektorów ataku na łańcuch dostaw oprogramowania:

Tag poisoning i podmiana artefaktów

Atakujący przejmują konto maintainera (lub exploitują podatność w repozytorium) i podmieniają tagi wersji na złośliwe commity. Ponieważ większość pipeline’ów odwołuje się do akcji i pakietów po tagach (np. actions/checkout@v4), a nie po hashach commitów, zmiana tagu automatycznie infekuje wszystkich użytkowników. Tak działał atak na tj-actions i TeamPCP CI/CD Siege.

Typosquatting i dependency confusion

Publikacja pakietów o nazwach łudząco podobnych do popularnych bibliotek (np. requ3sts zamiast requests) lub o nazwach pokrywających się z wewnętrznymi pakietami organizacji. W 2026 roku na samym PyPI odnotowano kampanie typosquattingowe celujące w zespoły data science i ML engineering. Więcej o tym wektorze pisaliśmy w analizie ataków na łańcuch dostaw NPM.

Secrets scraping z pamięci runner’ów CI

Złośliwy kod uruchamiany w kontekście pipeline’u CI/CD ma dostęp do zmiennych środowiskowych, tokenów, kluczy API i certyfikatów. Współczesne ataki (jak Shai-Hulud) idą dalej – czytają pamięć procesu runner’a aby wyekstrahować sekrety, które nigdy nie były zapisane w zmiennych środowiskowych. Pozyskane tokeny służą do lateralnego rozprzestrzeniania się na kolejne repozytoria i pakiety.

Cache poisoning i artifact overwrite

Atakujący wstrzykują złośliwą zawartość do cache’u współdzielonego między workflow’ami. Kolejne uruchomienia pipeline’u (np. release) przywracają zatrute dane i wykonują je w uprzywilejowanym kontekście. Wariant tej techniki – artifact overwrite – polega na utworzeniu pipeline’u o takiej samej nazwie jak istniejący, który nadpisuje oryginalne artefakty zatrucjonymi wersjami.

Social engineering maintainerów

Atakujący budują zaufanie w społeczności open-source, kontrybuując do projektu przez tygodnie lub miesiące, a następnie wykorzystują zdobyte uprawnienia do wstrzyknięcia złośliwego kodu. W kampanii UNC6426 z 2026 roku przejęcie kontroli nad pakietem npm umożliwiło uzyskanie pełnego dostępu administratora AWS w ciągu 72 godzin.

Narzędzia deweloperskie jako broń

W 2026 roku atakujący coraz częściej celują bezpośrednio w środowisko pracy programistów – IDE, rozszerzenia i narzędzia CLI. To przesunięcie jest logiczne: kompromitacja narzędzia deweloperskiego daje dostęp do wszystkich projektów, na których pracuje programista, wraz z jego poświadczeniami, tokenami i kluczami SSH.

Kampania GlassWorm z 2026 roku jest doskonałym przykładem: atakujący opublikowali 72 złośliwe rozszerzenia Open VSX dla Visual Studio Code oraz 151 repozytoriów GitHub zawierających payloady zakodowane w Unicode. Skompromitowane rozszerzenie VS Code z 2,2 miliona instalacji doprowadziło do wycieku danych z wewnętrznej infrastruktury GitHuba.

Ten wektor ataku jest szczególnie niebezpieczny, ponieważ rozszerzenia IDE działają z pełnymi uprawnieniami użytkownika i mają dostęp do systemu plików, sieci oraz procesów systemowych.

Regulacje i compliance – NIS2, DORA, SLSA

Rosnąca fala ataków supply-chain wymusiła reakcję regulatorów. W Polsce i Europie kluczowe ramy prawne obejmują:

NIS2 i bezpieczeństwo łańcucha dostaw

23 stycznia 2026 roku Sejm uchwalił nowelizację Ustawy o KSC implementującą Dyrektywę NIS2. Przepisy kładą szczególny nacisk na bezpieczeństwo łańcucha dostaw, wymagając od podmiotów kluczowych i ważnych m.in.:

• Oceny ryzyka związanego z dostawcami oprogramowania i usług ICT
• Weryfikacji praktyk bezpieczeństwa dostawców (w tym procesu SDLC)
• Procedur reagowania na incydenty w łańcuchu dostaw
• Dokumentowania i audytu zależności od podmiotów trzecich

Szczegółowe omówienie wymogów NIS2 dla polskich firm znajdziesz w naszym artykule o wdrożeniu NIS2 w Polsce.

SLSA i SBOM – standardy techniczne

SLSA (Supply-chain Levels for Software Artifacts) to framework bezpieczeństwa Open Source Security Foundation (OSSF) definiujący gradualne poziomy ochrony procesu budowania oprogramowania. Podczas gdy SBOM odpowiada na pytanie co znajduje się w oprogramowaniu, SLSA weryfikuje jak zostało zbudowane.

SBOM (Software Bill of Materials) to formalny wykaz wszystkich komponentów, bibliotek i zależności w oprogramowaniu. Generowanie SBOM dla każdego buildu (nie tylko release’u) staje się standardem wymaganym przez regulatorów i dużych odbiorców oprogramowania.

Jak zabezpieczyć łańcuch dostaw – praktyczny przewodnik

Ochrona pipeline’u CI/CD wymaga podejścia wielowarstwowego. Poniżej przedstawiamy konkretne działania pogrupowane według priorytetów:

Zabezpieczenia krytyczne (wdrożyć natychmiast)

• Pinowanie zależności po hashu (SHA) – nigdy nie odwołuj się do GitHub Actions, pakietów ani obrazów kontenerów po tagach wersji. Używaj pełnych hashów commitów: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 zamiast actions/checkout@v4
• Rotacja sekretów – wszystkie tokeny, klucze API i poświadczenia używane w pipeline’ach CI/CD powinny być rotowane regularnie (minimum co 90 dni) i natychmiast po każdym podejrzeniu kompromitacji
• Zasada najmniejszych uprawnień – tokeny CI/CD powinny mieć minimalne wymagane uprawnienia. GitHub Actions: używaj permissions na poziomie workflow/job zamiast domyślnych szerokich uprawnień tokena GITHUB_TOKEN
• Izolacja pipeline’ów – oddziel środowiska budowania od produkcyjnych. Build pipeline nie powinien mieć bezpośredniego dostępu do infrastruktury produkcyjnej

Zabezpieczenia zaawansowane

• Provenance i podpisywanie artefaktów – generuj metadane provenance dla każdego buildu (informacje o kodzie źródłowym, środowisku budowania, zależnościach). Podpisuj artefakty kryptograficznie za pomocą Sigstore/cosign
• SBOM dla każdego buildu – generuj Software Bill of Materials nie tylko dla release’ów, ale dla każdego buildu. Przechowuj SBOM obok artefaktów, które opisują
• Monitoring anomalii – wdrożyć wykrywanie nietypowych wzorców: nowe zależności dodane bez code review, nagłe zmiany w drzewie zależności, podejrzane skrypty postinstall w pakietach npm/PyPI
• Code review dla zmian w pipeline – traktuj pliki konfiguracyjne CI/CD (.github/workflows/, Jenkinsfile, .gitlab-ci.yml) z takim samym rygorem jak kod produkcyjny – obowiązkowy code review dla każdej zmiany

Zabezpieczenia organizacyjne

• Due diligence dostawców – przed włączeniem nowej zależności weryfikuj: kto ją utrzymuje, jak wygląda historia commitów, czy projekt ma aktywną społeczność, czy stosuje podpisywanie release’ów
• Rozdzielenie kontroli – żaden pojedynczy system nie powinien kontrolować zarówno kodu źródłowego, jak i procesu budowania. Oddziel source control od build execution
• Szkolenia deweloperów – programiści powinni znać techniki ataków supply-chain (typosquatting, social engineering maintainerów) i procedury weryfikacji nowych zależności
• Plan reagowania na incydenty supply-chain – przygotuj procedury na wypadek kompromitacji zależności: jak szybko zidentyfikować zakres wpływu, jak wycofać zatrute wersje, jak powiadomić użytkowników

Rola testów penetracyjnych w ochronie SDLC

Tradycyjne testy penetracyjne skupiają się na aplikacji końcowej. Jednak w obliczu rosnących zagrożeń supply-chain, zakres testów musi objąć cały pipeline wytwarzania oprogramowania – od repozytorium kodu, przez pipeline CI/CD, po rejestry artefaktów i środowiska wdrożeniowe.

Profesjonalne testy penetracyjne pipeline’u CI/CD powinny weryfikować:

• Czy sekrety w pipeline’ach są odpowiednio chronione i czy nie można ich wyekstrahować
• Czy zależności są pinowane po hashach i weryfikowane kryptograficznie
• Czy konfiguracja GitHub Actions/GitLab CI jest odporna na injection attacks
• Czy istnieje segmentacja między środowiskami dev/staging/prod
• Czy proces code review obejmuje zmiany w plikach konfiguracyjnych CI/CD
• Czy monitoring wykrywa anomalie w drzewie zależności i wzorcach dostępu

Firmy produkujące oprogramowanie powinny również zweryfikować swoją zgodność z wymaganiami NIS2 i DORA w zakresie bezpieczeństwa łańcucha dostaw – zarówno pod kątem zabezpieczeń technicznych, jak i procedur organizacyjnych. Więcej o podejściu do bezpieczeństwa w firmach tworzących oprogramowanie pisaliśmy w artykule testy penetracyjne w software house.

Podsumowanie

Ataki na łańcuch dostaw oprogramowania przeszły transformację – z rzadkich, zaawansowanych operacji państwowych w zautomatyzowane, wielowektorowe kampanie dostępne dla grup cyberprzestępczych. Pipeline CI/CD, rejestry pakietów i narzędzia deweloperskie stanowią obecnie jeden z najbardziej narażonych celów ataków.

Kluczowe liczby z 2026 roku:

• 59 kampanii supply-chain w pierwszej połowie roku (2,6x vs 2025)
• 657 złośliwych pakietów w rejestrach npm/PyPI (4,5x vs 2025)
• 5 ataków w 48 godzin – maj 2026, uderzenie we wszystkie warstwy SDLC
• 2,2 mln instalacji skompromitowanego rozszerzenia VS Code
• 0 CVE przypisanych do tych ataków – omijają tradycyjne mechanizmy wykrywania

Ochrona wymaga podejścia wielowarstwowego: pinowanie zależności po hashach, rotacja sekretów, SBOM, provenance verification, monitoring anomalii i regularne testy penetracyjne pipeline’ów CI/CD. Regulacje NIS2 i DORA dodatkowo wymuszają formalne podejście do bezpieczeństwa łańcucha dostaw.

Jeśli Twoja organizacja wytwarza oprogramowanie i chcesz zweryfikować bezpieczeństwo swojego pipeline’u CI/CD, wejdź na stronę Kontakt i skonsultuj z naszymi specjalistami strategię ochrony Twojego łańcucha dostaw.

FAQ