Czy open-source wystarczy do zapewnienia zgodności z NIS2/KSC2?

Od kwietnia 2026 roku nowelizacja ustawy o KSC jest już faktem, a tysiące podmiotów i instytucji właśnie odkrywają, że spoczywają na nich (tak naprawdę od kilku lat zapowiadane) nowe obowiązki: samoidentyfikacja, wdrożenie SZBI, raportowanie incydentów i audyty. Terminy się zbliżają, a kary, choć objęte dwuletnią karencją (art. 35 ustawy nowelizującej), przestały być teoretyczne. Nic dziwnego, że na rynku od razu pojawiła się fala „gotowych rozwiązań NIS2″, czyli pudełek i platform, które rzekomo gwarantują zgodność za jednym podpisem na zamówieniu. Tyle że ich ceny bywają niemałe, zwłaszcza dla mniejszych podmiotów, które dopiero co zdały sobie sprawę, że w ogóle podlegają ustawie.

To pytanie wraca przy konsultacjach dla klientów, na szkoleniach i podczas audytów: skoro nie mamy worka pieniędzy na drogie pudełka z mrugającą diodą, to czy obronimy się darmowymi narzędziami i spełnimy wymogi dyrektywy NIS2?

Weźmy choćby to komercyjne pudełko, które ktoś przedstawiał na konferencji jako „gotowe rozwiązanie NIS2”, i zajrzyjmy do środka. Linux. OpenSSL. nginx. Pewnie gdzieś fork Suricaty albo silnik na bazie ClamAV. Za open-source w zasadzie już zapłaciliśmy, tylko z ładnym logo na obudowie. Zatem pytanie: „Open-source czy komercja” jest trochę nie na temat. Lepiej zastanowić się, czy mamy to jak obsłużyć.

Ustawa nie każe nic kupować

Dobra wiadomość jest taka, że ani dyrektywa NIS2, ani polska znowelizowana ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC) nie wskazują żadnego producenta ani konkretnego produktu. Przepisy wymagają wdrożenia Systemu Zarządzania Bezpieczeństwem Informacji (SZBI) opartego na systematycznym szacowaniu ryzyka oraz katalogu środków technicznych i organizacyjnych (art. 8 ust. 1). Sam katalog (od analizy ryzyka, przez ciągłość działania, po uwierzytelnianie wieloskładnikowe) wynika z art. 21 ust. 2 dyrektywy NIS2, a w polskiej ustawie – z przepisów o SZBI. Cała ta regulacja nie powstała przy tym po to, żeby zatapiać firmy kosztami. Jak podkreśla Ministerstwo Cyfryzacji w swoim Q&A, środki mają być odpowiednie i proporcjonalne do oszacowanego ryzyka, a nie do grubości portfela.

Wydany w czerwcu 2025 roku przewodnik techniczny ENISA do rozporządzenia wykonawczego 2024/2690 rozkłada każdy wymóg na praktyczne wskazówki, przykłady dowodów do okazania podczas kontroli oraz odniesienia do norm. Nie ma w nim ani cennika, ani nazwy producenta. Oficjalny zestaw pytań i odpowiedzi (Q&A) Ministerstwa Cyfryzacji podkreśla to samo: liczy się faktyczne wdrożenie i możliwość jego wykazania. Minister może przy tym opublikować, na podstawie art. 45 ust. 3, zestawienie dokumentów normalizacyjnych, czyli listę uznanych norm, a nie listę zakupów u dystrybutorów. Dokumenty normalizacyjne uzupełniają Narodowe Standardy Cyberbezpieczeństwa oraz inne zbiory dobrych praktyk, wydawane jako rekomendacje Pełnomocnika Rządu, z których warto skorzystać. Nigdzie natomiast nie pojawia się nakłanianie do ich zakupu.

Co open-source rzeczywiście załatwi?

Open-source potrafi naprawdę dużo, a większość wymagań technicznych z art. 8 znowelizowanej ustawy o KSC da się spełnić dzięki odpowiednim, darmowym narzędziom. W praktyce wymogi te możemy przypisać do przykładowych rozwiązań, jak poniżej.Dobór jest celowo zachowawczy: to projekty dojrzałe, aktywnie rozwijane i szeroko stosowane produkcyjnie, także w polskich SOC-ach, więc łatwo o dokumentację, społeczność i ludzi, którzy już na nich pracowali. Przy każdym obszarze wskazujemy konkretny artykuł i literę ze znowelizowanej ustawy o KSC:

• Obsługa incydentów (art. 11 ust. 1 pkt 1): Wazuh do korelacji logów, reguł detekcji i automatycznej reakcji, Graylog do przeglądania zdarzeń, Suricata lub Snort w roli IDS/IPS albo Zeek jako źródło telemetrii sieciowej. Do reakcji na żywo służy Velociraptor (zdalne zbieranie artefaktów i threat hunting na setkach końcówek naraz), a prowadzenie i orkiestrację spraw incydentów ułatwi otwarta platforma zarządzania zgłoszeniami, jak DFIR IRIS albo TheHive. Autopsy zostaje do głębszej, laboratoryjnej analizy nośników offline. Co ciekawe, samo Ministerstwo Cyfryzacji w swoim przewodniku (Q&A pkt 3.3 ppkt 2 lit. g)  wprost dopuszcza, że do ciągłego monitorowania „można skorzystać z narzędzi open-source typu SIEM i ustawić adekwatne reguły”.
• Ciągłość działania (art. 8 ust. 1 pkt 2 lit. f): kopie zapasowe na Borg lub restic, a monitorowanie dostępności i przewidywanie wyczerpania zasobów na Zabbixie (same testy odtworzenia to już procedura, nie narzędzie, co warto podkreślić).
• Zarządzanie podatnościami (art. 8 ust. 1 pkt 3): moduł Vulnerability Detection w Wazuhu (zasilany zagregowanymi źródłami danych o podatnościach, m.in. NVD i biuletynami producentów), OpenVAS do skanów aktywnych. Solidna alternatywa dla płatnego Tenable/Nessusa..
• Kryptografia (art. 8 ust. 1 pkt 2 lit. k): weryfikacja konfiguracji (polityki TLS w module SCA Wazuha, testssl.sh), ale zarządzanie kluczami i sama polityka to proces.
• Kontrola dostępu, aktywa i integralność plików (art. 8 ust. 1 pkt 2 lit. m i n oraz pkt 5 lit. c): Keycloak na kontrolę dostępu (lit. n), GLPI lub OCS Inventory na inwentaryzację aktywów (lit. m), a FIM z “who-data” w Wazuhu jako odpowiedź na wymóg ochrony przed nieuprawnioną modyfikacją (pkt 5 lit. c), czyli na pytanie: „Kto zmienił istotny plik konfiguracyjny w środku nocy”. Segmentację sieci i zaporę zapewni pfSense CE albo OPNsense (na nich z kolei działa Suricata lub Snort jako IDS/IPS).
• Uwierzytelnianie wieloskładnikowe (art. 8 ust. 1 pkt 2 lit. l): Keycloak, który natywnie obsługuje nowoczesne standardy uwierzytelniania.

To produkcyjne rozwiązania, które działają w niejednym SOC-u i potrafią wesprzeć nas w tworzeniu raportów, które mogą przydać się przy audycie. Pod kątem samej techniki open-source nie ma się czego wstydzić.
 

Dwa obszary z ustawowego katalogu zostawiamy celowo puste: zarządzanie ryzykiem w łańcuchu dostaw oraz budowanie świadomości i szkolenia personelu. To przede wszystkim umowy, procesy i program szkoleniowy. Narzędzia dostarczą tu najwyżej danych, a nie gotowej zgodności. 

Narzędzie to jeszcze nie jest zgodność

I tu zaczyna się część, którą pomija większość entuzjastów „darmowego NIS2”. Wazuh, do którego alarmów nikt nie zagląda, nie jest zgodnością. Jest tylko dziennikiem zdarzeń. Samo postawienie oprogramowania to jakieś 30 procent pracy. Reszta to strojenie reguł, przechowywanie logów, procedury reagowania, szacowanie ryzyka, obsługa incydentu w reżimie 24/72 godzin (art. 11 ust. 1) i papier z podpisem zarządu. Zgodność robią procesy i ludzie, a nie sam fakt, że usługa działa na porcie.

Dochodzi też cichy koszt. Brak dostawcy oznacza brak gwarancji wsparcia (SLA) i brak infolinii. Jeśli o trzeciej w nocy wywróci się Wazuh Manager, a nikt tego nie zauważy, SOC przez kilka godzin jest ślepy i głuchy – przez ten czas ciężko zidentyfikować jakiekolwiek zagrożenia. Owszem, agenty buforują zdarzenia lokalnie i po powrocie Managera dociągną różnicę, ale bufor ma skończoną pojemność, a logi na końcówkach podlegają rotacji. Jeśli konfiguracja nie przewiduje dłuższych przerw w łączności, część zdarzeń zostanie w tym czasie nadpisana i nie trafi już do SIEM-a. Łatanie, utwardzanie konfiguracji, aktualizacje i utrzymanie klastra również zostają po stronie zespołu.. Darmowe narzędzie potrafi okazać się najdroższe, jeśli nie ma go kto pilnować.

I rzecz, o której zarząd musi wiedzieć: za wdrożenie SZBI osobiście odpowiada kierownik podmiotu (art. 8c), a karę pieniężną można nałożyć bezpośrednio na niego, niezależnie od kary dla podmiotu (art. 73a, do 300% miesięcznego wynagrodzenia). Luka w procedurach wokół „darmowego” narzędzia to więc nie tylko problem działu IT.

Open-source to też łańcuch dostaw

Najczęściej pomijany wątek. Niejednokrotnie pada pytanie: „Jak open-source ma się do oceny ryzyka dostawcy?”. Otóż wprost. Ustawa wymaga zarządzania ryzykiem łańcucha dostaw (art. 8 ust. 1 pkt 2 lit. e), a wykorzystywane biblioteki open-source są właśnie takim łańcuchem.

Przypomnijmy sprawę xz/liblzma z 2024 roku (CVE-2024-3094). Napastnik, który latami socjotechniką budował zaufanie opiekuna projektu i w końcu uzyskał status współopiekuna wstawił backdoora celującego w sshd, który o mało nie trafił do stabilnych wydań Debiana i Fedory. „Darmowe i otwarte” nie znaczy więc „pozbawione ryzyka dostawcy”. Czasem oznacza, że dostawcą jest jeden przemęczony wolontariusz, który utrzymuje krytyczną bibliotekę po godzinach, bez wsparcia i uznania użytkowników.

W praktyce wdrożenie open-source w reżimie KSC wymaga tego samego, co rozwiązania komercyjne. Trzeba prowadzić wykaz komponentów (Software Bill of Materials/SBOM), patrzeć na kondycję projektów (ilu jest opiekunów, jak szybko łatają, kto to finansuje), zamrażać wersje, weryfikować sumy kontrolne i mieć proces szybkiej reakcji na podatności. To dokładnie te pytania, które zadalibyśmy płatnemu dostawcy. Otwartość kodu jest tu atutem, bo pozwala audytować, ale ktoś ten audyt musi faktycznie wykonać.

Dokąd to zmierza, czyli krótko o CSA2

Na poziomie unijnym szykuje się jeszcze jedna zmiana. Zaproponowana 20 stycznia 2026 roku rewizja Cybersecurity Act, znana jako CSA2 , ma zastąpić rozporządzenie z 2019 roku. Projekt może gruntownie zmienić podejście do bezpieczeństwa łańcucha dostaw ICT, wprowadzając w Tytule IV przekrojowy mechanizm walki z zagrożeniami nietechnicznymi, czyli geopolitycznymi i zagraniczną ingerencją.

Nowe ramy zakładają wskazywanie przez Komisję dostawców wysokiego ryzyka (“High-Risk Suppliers”, HRS) oraz państw trzecich uznanych za zagrożenie. Co to oznacza w praktyce? Dla operatorów sieci łączności (stacjonarnych, komórkowych i satelitarnych) CSA2 wprowadza obowiązek usuwania komponentów od dostawców HRS z kluczowych aktywów sieciowych, a dla sieci komórkowych – sztywny okres na ich wycofanie, nieprzekraczający 36 miesięcy.. Ponieważ wymiana infrastruktury to koszt rzędu milionów, jeśli nie miliardów euro rocznie, spór o bezpieczeństwo kodu staje się tak naprawdę dyskusją o suwerenności technologicznej Europy. W tym układzie open-source, którego nie kontroluje pojedynczy zagraniczny dostawca, bywa mocną kartą przetargową, pod warunkiem, że obejmiemy go rzetelną, wewnętrzną oceną ryzyka. Ciekawostka z polskiego podwórka: znowelizowana ustawa o KSC ma własny mechanizm uznawania za dostawcę wysokiego ryzyka (postępowanie z art. 67b), do którego wyników odsyła ocena łańcucha dostaw (art. 8 ust. 2 pkt 4), a przepisy te prezydent skierował do Trybunału Konstytucyjnego w ramach kontroli następczej. 

Podsumowanie

Czy open-source wystarczy? Może wystarczyć. Tylko że samo pytanie jest źle postawione. Narzędzia otwartoźródłowe są legalne, sprawdzone, mocno dopracowane i pokrywają większość wymagań technicznych z art. 8 znowelizowanej ustawy o KSC. Prawdziwe pytanie brzmi trochę inaczej: „Czy mamy na to zasoby?”.

Czy jest czas, żeby to wdrożyć, a potem przez lata utrzymywać? Czy jest kompetentny zespół, który nie tylko postawi Wazuha, ale będzie czytał generowane przez niego alarmy, stroił reguły, łatał, pisał dokumentację SZBI i panował nad zależnościami? Czy ktoś odbierze powiadomienie o trzeciej w nocy i będzie wiedział, co z nim zrobić? Licencja jest darmowa, ale czas zaangażowanych w projekt ludzi – już nie.

Jeśli odpowiedź brzmi: „Tak, mamy ludzi i czas”, open-source spokojnie udźwignie ciężar zgodności, często taniej i z mniejszym uzależnieniem od jednego dostawcy niż drogie, zamknięte pudełko. Jeśli odpowiedź to: „Nie do końca”, to właśnie darmowe narzędzie zacznie kosztować najwięcej, tyle że w nadgodzinach i nieprzespanych weekendach.

~Aleksander Wojdyła