NCSC w publikacji z 4 czerwca opisuje nadużycia rejestrów pakietów i automatycznych procesów CI/CD, a jako jeden z przykładów wskazuje majowy atak Mini Shai-hulud. Dla zespołów tworzących oprogramowanie i dla firm, które je kupują, wniosek jest ten sam. Zależności i sekrety używane przez automatyzację wymagają takiej samej kontroli jak kod pisany we własnym zespole.

Wyobraź sobie magazyn, w którym dostawy przyjmuje automat. Ciężarówka podjeżdża w nocy, automat sprawdza, czy nadawca jest na liście zaufanych, i wpuszcza towar na półki. Rano nikt nie zagląda do kartonów, bo przecież nadawca był znany. Taki magazyn działa sprawnie do dnia, w którym ktoś podszyje się pod zaufanego nadawcę albo przejmie jego ciężarówkę. Proces wytwarzania oprogramowania często przypomina ten magazyn. Pakiety z publicznych rejestrów trafiają do projektu przez automatyczne procesy, a te procesy korzystają z tokenów i haseł, które otwierają kolejne drzwi. Punktem odniesienia jest wpis NCSC z 4 czerwca 2026 r., zatytułowany „Software supply chain attacks: check your dependencies”. Proponujemy przeczytać go jako listę pytań do własnego procesu wydań.

Zaufane narzędzia wytwarzania stają się kanałem ataku

Według NCSC celem nadużyć są rejestry pakietów i automatyczne procesy CI/CD. To miejsca, którym zespoły programistów ufają z definicji. Rejestr dostarcza gotowe komponenty, a pipeline pobiera je, buduje aplikację i wydaje kolejne wersje bez udziału człowieka. Atakujący, który zdoła umieścić szkodliwą treść w tym łańcuchu, dociera do firmy tą samą drogą, którą przychodzą zwykłe aktualizacje.

Jako jeden z przykładów NCSC wskazuje majowy atak Mini Shai-hulud. Fakty, na których opiera się ta wiadomość, nie opisują szczegółów jego przebiegu ani listy poszkodowanych organizacji. Nie będziemy ich więc dopowiadać. Wystarczy wniosek ogólniejszy. Skoro NCSC sięga po przykład z maja 2026 r., problem dotyczy bieżącej praktyki zespołów programistów.

Osobną warstwą są poświadczenia. Automatyzacja potrzebuje sekretów, żeby pobierać pakiety, publikować wydania i łączyć się z innymi systemami. Zalecenie NCSC, by rotować narażone poświadczenia, pokazuje, że incydent w łańcuchu zależności nie kończy się na usunięciu złej wersji pakietu.

Pipeline, który sam pobiera i wydaje kod, jest pełnoprawnym uczestnikiem procesu wytwarzania i wymaga własnej kontroli.

Automatyczna aktualizacja omija moment decyzji

Procedury bezpiecznego wytwarzania mogą zakładać, że ktoś przegląda zmiany w kodzie. Łatwo przy tym przeoczyć, że przegląd obejmuje kod napisany przez zespół, a nowe wersje zależności mogą wchodzić do projektu automatycznie. Nie twierdzimy, że tak wygląda proces w konkretnej firmie; fakty przywołane w tej wiadomości tego nie dokumentują. Sprawdźmy jednak, czy we własnym procesie jest moment, w którym ktoś decyduje o przyjęciu nowej wersji pakietu.

NCSC zaleca kontrolę nowych wersji. Rozważmy hipotetyczny zapis w polityce: „zależności są aktualizowane na bieżąco”. Brzmi rozsądnie, bo aktualizacje często przynoszą poprawki. Ten sam zapis oznacza jednak, że nowa wersja z rejestru może trafić do wydania, zanim ktokolwiek ją obejrzy. Pytanie dla zespołu brzmi więc: kto i na jakiej podstawie zatwierdza nową wersję komponentu, zanim pipeline zbuduje z niej wydanie?

Podobnie jest z sekretami. Polityka może wymagać rotacji haseł, ale tokeny wpisane w konfigurację automatyzacji łatwo pominąć, bo nikt nie loguje się nimi ręcznie. Rotacja narażonych poświadczeń, o której pisze NCSC, wymaga najpierw wiedzy, których z nich proces CI/CD w ogóle używa.

Zapis o aktualizowaniu zależności na bieżąco powinien wskazywać, kto zatwierdza nową wersję przed wydaniem.

Kupujący dziedziczy zależności dostawcy

Dla zarządu i działu zakupów teza NCSC ma drugie zastosowanie. Firma, która nie pisze własnego kodu, nadal korzysta z oprogramowania zbudowanego z zależności i wydanego przez czyjś pipeline. Jeśli dostawca nie kontroluje nowych wersji pakietów, kupujący przejmuje to ryzyko razem z produktem. Sprawdźmy, czy umowa i ankieta bezpieczeństwa w ogóle pytają o ten fragment procesu.

Proponujemy dodać do rozmowy z dostawcą trzy pytania odpowiadające zaleceniom NCSC. Jak dostawca przegląda zależności swojego produktu? Czy potrafi zrotować poświadczenia używane przez automatyzację, gdy uzna je za narażone? W jaki sposób kontroluje przyjmowanie nowych wersji komponentów? Odpowiedzi zapiszmy i powiążmy z konkretnym produktem. Ogólne zapewnienie o „bezpiecznym procesie wytwarzania” potraktujmy jako początek rozmowy.

Przywołane fakty nie pozwalają oszacować kosztu takiej kontroli ani strat po ataku w konkretnej organizacji. Nie obiecujmy więc określonej oszczędności. Odpowiedzialność da się jednak przypisać: ktoś w firmie powinien wiedzieć, od których dostawców oprogramowania zależy jej działanie, i umieć zadać im te pytania.

Polskie zespoły korzystają z tych samych rejestrów

Fakty, na których opiera się ta wiadomość, nie określają skali problemu w Polsce i nie wskazują polskich organizacji poszkodowanych w opisanych kampaniach. Publiczne rejestry pakietów i procesy CI/CD nie mają jednak granic państwowych. Polski zespół programistów korzysta z tych samych rejestrów co zespoły, do których NCSC kieruje swój wpis.

Dla polskiego nabywcy usług IT oznacza to prostą zmianę w odbiorze prac. Przy zamówieniu oprogramowania u software house'u albo przy wdrożeniu gotowego produktu poprośmy o opis procesu wydań: skąd pochodzą zależności, kto zatwierdza nowe wersje i gdzie dostawca przechowuje sekrety automatyzacji. Brak odpowiedzi nie dowodzi zaniedbania. Powinien jednak trafić do protokołu jako jawna niewiadoma, zapisana obok ogólnego potwierdzenia odbioru.

Co z tym zrobić w poniedziałek

  1. Przejrzyj zależności jednego projektu. Wybierz aplikację, która jest najbliżej klientów. Spisz, z jakich rejestrów pochodzą jej pakiety i które nowe wersje weszły do niej od maja 2026 r. Zaznacz pozycje, których nikt w zespole nie potrafi uzasadnić.
  2. Spisz sekrety automatyzacji. W konfiguracji jednego pipeline'u CI/CD wypisz tokeny i hasła, z których korzysta. Przy każdym zanotuj, do czego daje dostęp i kiedy był ostatnio rotowany. Brak daty oznacz jako brak ustalenia.
  3. Wyślij pytania do jednego dostawcy. Wybierz dostawcę oprogramowania krytycznego dla firmy. Zapytaj o przegląd zależności, rotację poświadczeń automatyzacji i kontrolę nowych wersji komponentów. Ustal termin odpowiedzi i osobę, która ją oceni.

Łańcuch dostaw oprogramowania zaczyna się w rejestrze pakietów i kończy w pipeline, który nie musi nikogo pytać o zgodę. Wpis NCSC z 4 czerwca daje zespołom i kupującym gotową listę miejsc do sprawdzenia. Kontrola zależności i sekretów automatyzacji powinna być częścią zwykłego procesu wydań i odbioru.

Źródła

  1. NCSC: Software supply chain attacks: check your dependencies, publikacja: 4 czerwca 2026 r.

Redakcja cyberinsight.pl.