Lista zakazanego oprogramowania wzrosła do 1564 pozycji: co się zmieniło i co z tym robić działom IT

Derżspeczwjazku kolejny raz zaktualizowała Listę zabronionego do użytku oprogramowania oraz sprzętu komunikacyjnego (sieciowego). Nowa redakcja weszła w życie 21 lipca 2026 roku: lista wzrosła z 1341 do 1564 pozycji, czyli od razu o 223 nowe pozycje. Dla sektora państwowego i operatorów infrastruktury krytycznej nie jest to „kolejna wiadomość o sankcjach”, lecz bezpośredni powód, by sprawdzić własne rejestry aktywów.

Czym jest ta Lista i skąd się wzięła

Tworzenie Listy przewiduje uchwała Gabinetu Ministrów z 22.10.2025 nr 1335. Prowadzi ją Administracja Derżspeczwjazku — konkretnie Departament Kontroli Państwowej w Dziedzinie Ochrony Informacji i Cyberobrony. Dokument jest publikowany w formacie otwartych danych na oficjalnej stronie służby w sekcji „Działalność”.

Przed pojawieniem się Listy sytuacja była typowo ukraińska: decyzje RBNiO o sankcjach istniały, były wprowadzane w życie dekretami Prezydenta, ale nie istniało jednego scentralizowanego źródła informacji o tym, co dokładnie jest zabronione. Przez to część organów państwowych przez lata nadal eksploatowała produkty objęte sankcjami — nie z premedytacją, lecz dlatego że nie istniał dokument, na który można się powołać w dokumentacji przetargowej czy w akcie audytu wewnętrznego. Lista wypełnia tę lukę: jest oficjalnym scentralizowanym źródłem dla organów władzy państwowej, organów samorządu terytorialnego, formacji wojskowych, przedsiębiorstw państwowych i operatorów infrastruktury krytycznej.

Mechanika aktualizacji jest prosta: specjaliści Departamentu opracowują obowiązujące i nowe decyzje RBNiO, analizują produkty programowe i sprzęt komunikacyjny powiązane z osobami objętymi sankcjami, i wprowadzają je do Listy. Dokument jest z definicji dynamiczny — jest aktualizowany i uzupełniany na bieżąco.

Dynamika: od 27 pozycji do 1564 w pół roku

Najciekawsze w tej historii jest tempo. Lipcowa aktualizacja stała się już siódmą od początku 2026 roku, a Lista wystartowała z zaledwie kilkudziesięciu pozycji. W ciągu pół roku liczba zakazanych rozwiązań IT wzrosła dziesiątki razy.

Oznacza to dwie rzeczy. Po pierwsze: jednorazowa kontrola infrastruktury „pod Listę” nie działa — między dwiema redakcjami może minąć kilka tygodni, a to, co wczoraj było po prostu niepożądane, dziś stało się formalnie zabronione. Po drugie: proces weryfikacji trzeba postawić na regularne tory, najlepiej zautomatyzowane, powiązane z inwentaryzacją oprogramowania.

Co dodano tym razem

223 nowe pozycje obejmują produkty i systemy kilku producentów objętych sankcjami:

1. Sp. z o.o. „Grupa spółek Innotech"” — bankowe, fintechowe, korporacyjne, analityczne, integracyjne, chmurowe oraz infrastrukturalne platformy programowe. Najszersza kategoria pod względem zasięgu: obejmuje zarówno poziom aplikacyjny, jak i platformowy.
2. Sp. z o.o. „Trueconf” — serwerowe i klienckie oprogramowanie do wideokonferencji, komunikacji korporacyjnej i serwerów MCU. Czyli nie tylko klienci na stacjach roboczych, ale i część serwerowa VKZ.
3. Sp. z o.o. „Politerm” — oprogramowanie geoinformacyjne oraz kompleksy programowe do modelowania, obliczania i dyspozycjonowania sieci inżynieryjnych.
4. Linia Zulu — ZuluGIS/ZuluServer, ZuluNetTools, komponenty webowe i mobilne, moduły OPC/API dla sieci ciepłowniczych, wodociągowych, kanalizacyjnych, gazowych i parowych.
5. Sfera lotnicza i kosmiczna — specjalistyczne oprogramowanie i systemy informacyjne FGBU „Awiamettelekom Rosgidrometu” do obsługi meteorologicznej lotnictwa, a także produkty programowe FGUP „Kosmiczna łączność” i JSC „Amtel-Swiaz”.

Szczególnej uwagi zasługuje blok Politerm/Zulu oraz moduły OPC. To już nie oprogramowanie biurowe, lecz poziom systemów SCADA i dyspozycjonowania sieci komunalnych i energetycznych — czyli właśnie ten segment, w którym kompromitacja daje nie wyciek danych, lecz zatrzymanie procesu technologicznego. Obecność w tej kategorii komponentów OPC/API oznacza, że zakaz dotyczy również „niewidocznych” warstw integracyjnych, których zwykle nikt nie inwentaryzuje, ponieważ nie mają ikony w menu „Start”.

Co już było wcześniej na Liście

Obowiązująca redakcja, oprócz nowości, nadal zawiera klasykę, która wciąż spotykana jest w ukraińskich organizacjach:

1. rozwiązania księgowe i korporacyjne oparte na 1C, BAS i UA-Budżet;
2. produkty antywirusowe Kaspersky;
3. wszystkie usługi powiązane z „Yandexem”.

Wcześniej zespół Clapkey już pisał na ten temat:

- Ukraina zaostrza kontrolę nad produktami programowymi

- Do kogo tak naprawdę należy BAS

Ostatni punkt warto czytać szerzej niż „nie wchodzić na wyszukiwarkę”: to również metryki i liczniki na stronach internetowych, API kartograficzne i SDK w aplikacjach mobilnych. Takie rzeczy najczęściej „wiszą” w legacy-kodzie stron i w starych integracjach.

Konsekwencje niewykonania

Tu bez sentymentów. Jeśli zabronione oprogramowanie zostanie wykryte w systemach informacyjnych instytucji państwowej, może to stać się podstawą do unieważnienia autoryzacji kompleksowego systemu ochrony informacji. Kierownicy odpowiednich organizacji mogą zostać pociągnięci do odpowiedzialności administracyjnej.

Unieważniona autoryzacja KSZI to nie abstrakcyjna kara, lecz faktyczne zatrzymanie legalnej eksploatacji systemu ze wszystkimi konsekwencjami: od problemów z integracjami po kwestie podczas kontroli i zamówień.

Sama Derżspeczwjazku formułuje ryzyko wprost: używanie takich produktów stwarza zagrożenie wycieku danych, nieautoryzowanego dostępu do zasobów informacyjnych, zdalnej ingerencji w działanie systemów i zatrzymania krytycznie ważnych procesów.

Praktyczna checklista dla działu IT

Co warto zrobić, nie czekając na kolejną redakcję:

1. Sporządzić pełny inwentarz oprogramowania. Nie „z pamięci administratorów”, lecz przez rzeczywiste źródła: inwentaryzacja WMI/registry w Windows, menedżery pakietów w Linux, dane z systemu monitoringu, SCCM/odpowiedniki, raporty EDR. Zabronione oprogramowanie najczęściej żyje na „zapomnianych” serwerach.
2. Osobno przejrzeć to, co nieoczywiste. Biblioteki, sterowniki, wtyczki, serwery OPC, SDK w aplikacjach mobilnych, liczniki i mapy na stronach korporacyjnych, wbudowane komponenty w systemach SCADA.
3. Zweryfikować z otwartymi danymi Listy. Ponieważ jest publikowana jako open data, weryfikację można realnie zautomatyzować: sparsować listę do własnej bazy aktywów (CMDB/NetBox/dowolne inne) i ustawić na cotygodniowy cron zamiast ręcznego porównywania PDF.
4. Sprawdzić zamówienia i umowy. Lista została stworzona między innymi po to, by uprościć procesy zamówień i zarządzania ryzykiem. Dokumentacja przetargowa i obowiązujące umowy wsparcia to osobny front pracy.
5. Sporządzić plan zastąpienia z terminami. Dla każdej znalezionej pozycji: czym zastępujemy, kto jest odpowiedzialny, termin, ryzyka migracji danych. Szczególnie bolesne będzie to dla systemów księgowych na 1C/BAS oraz dla branżowych systemów GIS.
6. Udokumentować wynik. Akt inwentaryzacji i plan zastąpienia to jest to, co pokazuje się podczas kontroli. Ustne przekonanie, że „u nas takiego nie ma”, dowodem nie jest.

Wniosek

Lista przekształciła się z dokumentu deklaratywnego w narzędzie roboczej kontroli, które zmienia się niemal co miesiąc. Logika państwa jest zrozumiała: oprogramowanie dziś jest rozpatrywane nie tylko jako narzędzie robocze, ale i jako potencjalny kanał cyberataku — z zarządzaną aktualizacją, telemetrią i kanałem do producenta, który znajduje się pod sankcjami.

Dla działów IT oznacza to przejście od jednorazowych „czystek” do stałego procesu: inwentaryzacja → weryfikacja z aktualną redakcją → zastąpienie → dokumentowanie. Kto zbuduje to jako regularną procedurę już teraz, ten nie będzie przeżywał każdej kolejnej aktualizacji jak awarii.

Źródła:

1. Derżspeczwjazku: „Lista zabronionego do użytku oprogramowania i sprzętu komunikacyjnego rozszerzona do 1564 pozycji” — cip.gov.ua
2. Derżspeczwjazku: „Lista zabronionego do użytku oprogramowania oraz sprzętu komunikacyjnego (sieciowego)” — cip.gov.ua