NIS2 — szerszy zakres niż myślisz
Dyrektywa NIS2 (2022/2555), implementowana przez państwa członkowskie od października 2024, jest istotnie szersza niż jej poprzedniczka z 2016 roku. Obejmuje 18 sektorów i dziesiątki tysięcy podmiotów w UE — nie tylko operatorów infrastruktury krytycznej, ale też dostawców usług cyfrowych, zarządzanych usług ICT i oprogramowania.
Kluczowa zmiana której nie można zbagatelizować: NIS2 rozszerza odpowiedzialność za bezpieczeństwo na łańcuchy dostaw. Podmiot objęty dyrektywą musi zarządzać ryzykiem bezpieczeństwa nie tylko wewnętrznie, ale też u swoich dostawców. To sprawia, że firmy technologiczne dostarczające do podmiotów NIS2 stają się częścią regulacyjnego ekosystemu — nawet jeśli same nie są objęte dyrektywą bezpośrednio.
Art. 21 — bezpieczeństwo łańcucha dostaw
Artykuł 21 ust. 2 lit. d dyrektywy NIS2 nakłada obowiązek zarządzania bezpieczeństwem łańcucha dostaw, “w tym aspektów związanych z bezpieczeństwem stosunków między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami”.
W praktyce oznacza to, że podmioty NIS2 będą wymagały od dostawców oprogramowania i usług ICT dokumentowania swoich kontroli bezpieczeństwa. Nie jako formalność — ale jako warunek nawiązania i kontynuowania współpracy.
SBOM — od dobrowolnego do wymaganego
Software Bill of Materials (SBOM) — ustrukturyzowana lista składników oprogramowania wraz z wersjami i zależnościami — staje się kluczowym dokumentem w kontekście NIS2. Pozwala podmiotowi kupującemu oprogramowanie zweryfikować jego skład i szybko zidentyfikować ekspozycję na nowo odkryte podatności.
Analogia jest prosta: tak jak producent żywności jest zobowiązany do podania listy składników, dostawca oprogramowania będzie musiał udokumentować z czego jest zbudowany jego produkt. US Executive Order 14028, Cyber Resilience Act (nadchodzące rozporządzenie UE) i rosnące wymagania kontraktowe Enterprise idą w tym samym kierunku.
Organizacje które nie mają automatycznego generowania SBOM jako elementu procesu wytwórczego, będą musiały tworzyć te dokumenty ręcznie — co przy złożonych aplikacjach z dziesiątkami transitive dependencies jest praktycznie niemożliwe do utrzymania.
Co oznacza “zarządzanie ryzykiem dostawców” w praktyce
Podmiot NIS2 który kupuje oprogramowanie zewnętrzne ma teraz obowiązek ocenić ryzyko tego dostawcy. Mechanizmy tej oceny obejmują typowo: kwestionariusze bezpieczeństwa, przegląd certyfikatów (ISO 27001, SOC 2), żądania dokumentacji technicznej, a dla dostawców krytycznych — audyty.
Dla firmy technologicznej która chce pozostać dostawcą dla klientów Enterprise w UE, oznacza to konieczność przygotowania “pakietu dowodowego” — dokumentacji potwierdzającej faktyczne wdrożenie kontroli bezpieczeństwa, nie tylko deklaracji ich istnienia.
Sankcje i egzekwowanie
NIS2 przewiduje sankcje administracyjne do 10 milionów EUR lub 2% globalnego obrotu (dla podmiotów kluczowych) oraz 7 milionów EUR lub 1,4% obrotu (dla podmiotów ważnych). Istotniejsze jednak są konsekwencje biznesowe — wykluczenie z przetargów, utrata kontraktów, obowiązek powiadomienia klientów o incydentach.
Jak NIS2 wpływa na pipeline CI/CD
Wymogi NIS2 dotyczące łańcucha dostaw przekładają się na konkretne oczekiwania wobec procesu wytwórczego oprogramowania. Podmiot objęty dyrektywą, zamawiający audyt dostawcy, szuka odpowiedzi na pytania, które dotyczą bezpośrednio konfiguracji pipeline’u.
Integralność kodu i artefaktów: Czy istnieje mechanizm weryfikacji, że artefakt wdrożony na produkcję jest dokładnie tym, co zbudował pipeline? Podpisywanie artefaktów (Cosign/Sigstore) daje kryptograficzny dowód nienaruszalności. Bez tego — dostawca nie jest w stanie udowodnić integralności swojego produktu.
Zarządzanie podatnościami w zależnościach: Czy aplikacja jest skanowana pod kątem znanych podatności (CVE) w bibliotekach zewnętrznych? NIS2 Art. 21 ust. 2 lit. e wymaga “praktyk w zakresie obsługi i ujawniania podatności”. W kontekście pipeline’u oznacza to automatyczne skanowanie SCA (Software Composition Analysis) przy każdym buildzie — nie jednorazowy raport.
Kontrola dostępu do pipeline’u: Kto może uruchamiać workflow i modyfikować konfigurację deploymentu? Zasada minimalnych uprawnień (least privilege) dotyczy nie tylko aplikacji produkcyjnej, ale też narzędzi które ją budują i wdrażają. OIDC zamiast statycznych tokenów eliminuje jeden z najczęstszych wektorów przejęcia dostępu.
Dokumentacja i ślad audytowy: Każde uruchomienie pipeline’u powinno generować artefakty, które można przedstawić audytorowi: logi budowania, wyniki skanowania, SBOM, podpisy artefaktów. To jest właśnie to, co składa się na Evidence Pack.
Harmonogram implementacji i co to oznacza teraz
Dyrektywa NIS2 weszła w życie 16 stycznia 2023, a państwa członkowskie miały czas do 17 października 2024 na transpozycję do prawa krajowego. Polska pracuje nad ustawą o krajowym systemie cyberbezpieczeństwa (nowelizacja ustawy z 2018 roku), której ostateczny kształt jest wciąż ustalany.
Niezależnie od tempa legislacji krajowej — podmioty NIS2 już teraz stosują wymogi dyrektywy w relacjach z dostawcami. Kwestionariusze bezpieczeństwa, żądania dokumentacji technicznej i wymagania SBOM pojawiają się w zapytaniach ofertowych nie dlatego, że ustawa krajowa tego wymaga — ale dlatego, że dyrektywa UE daje im ku temu podstawę, a presja compliance oficerów jest realna.
Dla firm technologicznych w Polsce oznacza to: nie czekaj na ustawę. Przygotuj dokumentację techniczną i Evidence Pack teraz — bo klienci Enterprise pytają już dziś.
Czytaj również: