Bezpieczny rozwój i nabywanie w NIS 2 zgodnie z artykułem 21 ust. 2 lit. e)
NIS 2 mówi, że musisz zabezpieczyć systemy w zakresie zakupów, rozwoju i utrzymania. Artykuł 21 ust. 2 lit. e) jest ramą nadrzędną. §6 CIR (UE) 2024/2690 dzieli go na dziesięć podsekcji. Niemcy wprowadzają go do prawa krajowego przez §30 ust. 2 pkt 5 BSIG.
Krótka wersja
Artykuł 21 ust. 2 lit. e) jest nadrzędnym obowiązkiem bezpieczeństwa w całym cyklu życia IT. Nie tylko kod. Nie tylko łatanie. Cała ścieżka: kupowanie systemu, budowanie go, konfigurowanie, zmienianie, testowanie, łatanie, eksploatacja, wycofywanie z eksploatacji. Ta sama zasada obowiązuje w całej UE.
CIR (UE) 2024/2690 uzupełnia szczegóły. §6 załącznika ma dziesięć podsekcji (§6.1 do §6.10), które operacjonalizują ten obowiązek. Ta strona obejmuje stronę rozwoju i zmian: zakupy (§6.1), bezpieczny cykl życia oprogramowania (§6.2), zarządzanie konfiguracją (§6.3), zarządzanie zmianą (§6.4), testowanie bezpieczeństwa (§6.5) i zarządzanie łatkami (§6.6). Bezpieczeństwo sieci, segmentacja, ochrona przed złośliwym oprogramowaniem i zarządzanie podatnościami (§6.7 do §6.10) mają własne strony.
Niemcy wprowadzają tę samą zasadę do prawa krajowego przez §30 ust. 2 pkt 5 BSIG. Brzmienie jest niemal słowo w słowo zgodne z tekstem UE. Ta strona przechodzi przez dyrektywę, unijne rozporządzenie wykonawcze oraz niemiecką transpozycję w tej kolejności.
Artykuł 21 ust. 2 lit. e) dyrektywy NIS 2 (2022/2555)
Bezpieczeństwo w procesie nabywania, rozwoju i utrzymania sieci i systemów informatycznych, w tym obsługa i ujawnianie podatności.
To punkt e) na liście dziesięciu środków cyberbezpieczeństwa, które każdy podmiot kluczowy i ważny musi wdrożyć. Jest to jedyny punkt na liście, który wprost rozciąga się od zamówienia zakupu po koniec eksploatacji.
CIR (UE) 2024/2690, załącznik §6
Środki bezpieczeństwa w nabywaniu, rozwoju i utrzymaniu sieci i systemów informatycznych (artykuł 21 ust. 2 lit. e) dyrektywy (UE) 2022/2555).
Ponieważ jest to rozporządzenie (a nie dyrektywa), jest bezpośrednio wiążącym prawem UE. Transpozycja krajowa nie jest potrzebna. Ma zastosowanie do dostawców DNS, rejestrów TLD, dostawców chmury, centrów danych, dostawców usług zarządzanych oraz pozostałych sektorów wymienionych w jego załączniku. §6 ma dziesięć numerowanych podsekcji, z których każda nazywa konkretny obowiązek.
§30 ust. 2 pkt 5 BSIG (Niemcy)
Bezpieczeństwo w nabywaniu, rozwoju i utrzymaniu systemów technologii informatycznych, w tym obsługa i ujawnianie podatności.
Niemcy kopiują tekst UE niemal słowo w słowo. 'Systemy technologii informatycznych' zamiast 'sieci i systemów informatycznych' to brzmienie, a nie znaczenie. BSI wskazuje moduły IT-Grundschutz CON.8 (rozwój oprogramowania) i OPS.1.1.3 (zarządzanie łatkami i zmianą) jako praktyczną drogę.
Wpisz wymagania bezpieczeństwa do każdego zakupu
Zanim kupisz produkt lub usługę IT, spisujesz, co musi spełniać w zakresie bezpieczeństwa. Uwierzytelnianie, logowanie, wsparcie aktualizacji, ujawnianie podatności, region hostingu, gdzie znajdują się dane. Następnie walidujesz, czy dostawca rzeczywiście spełnia wymagania. To spoczywa na podmiocie kupującym, a nie na dostawcy. 'Używamy SaaS' nie przenosi tego obowiązku.
Prowadź bezpieczny cykl życia oprogramowania
Wymagania bezpieczeństwa są analizowane podczas specyfikacji i projektowania. Stosuje się zasady bezpiecznego kodowania, w tym security by design i architektury zero-trust. Same środowiska programistyczne są zabezpieczone. Testowanie bezpieczeństwa odbywa się przed wydaniem. Dane testowe są traktowane z ostrożnością, a nie kopiowane z produkcji. Cały cykl życia jest udokumentowany, a nie tylko jedna czy dwie praktyki.
Łataj w odpowiednim czasie, najpierw testuj
Łatki bezpieczeństwa są stosowane w odpowiednim czasie (tekst CIR), powiązanym z dotkliwością podatności. Łatki są testowane przed produkcją. Łatki awaryjne są dokumentowane. 'Kiedy zespół ma czas' nie jest ramą czasową. Wybierz kadencję, zapisz ją, udowodnij, że jej przestrzegasz.
Bezpieczeństwo od zakupów po wycofanie z eksploatacji
§6 nie dotyczy rozwoju w wąskim sensie. Obejmuje cały cykl życia: jak wybierasz, co kupić, jak budujesz, jak konfigurujesz, jak testujesz, jak łatasz, jak zmieniasz, jak wycofujesz. Mittelstand, który kupuje 95 procent swojego oprogramowania, nadal odpowiada za §6.1 (wymagania zakupowe) i §6.6 (zarządzanie łatkami). Nie możesz wypisać się z cyklu życia tylko dlatego, że nie piszesz kodu.
Dyscyplina zmian: żadnych nieśledzonych zmian na produkcji
§6.4 jest bezpośredni: zmiany na produkcji są zarządzane, dokumentowane i przeglądane. Zmiany awaryjne także są dokumentowane, tylko po fakcie zamiast przed. Zmiana bez zgłoszenia, bez zatwierdzającego i bez planu wycofania nie spełnia wymagania, nawet jeśli działa. Audytorzy porównują dziennik zmian z systemem zgłoszeń. Jeżeli nie potrafią odtworzyć, kto co zmienił i kiedy, mechanizm kontrolny nie jest wdrożony.
BSI / IT-Grundschutz CON.8 + OPS.1.1.3
BSI mapuje §30 ust. 2 pkt 5 BSIG na dwa moduły Grundschutz. CON.8 'Software-Entwicklung' obejmuje stronę SDLC: wymagania, bezpieczne kodowanie, testy, wydanie. OPS.1.1.3 'Patch- und Änderungsmanagement' obejmuje stronę zmian i łatek. Jeżeli stosujesz CON.8 i OPS.1.1.3, mieścisz się w tym, czego wymaga §30 BSIG.
Wytyczne techniczne wdrożeniowe ENISA
ENISA, agencja UE ds. cyberbezpieczeństwa, publikuje Wytyczne techniczne wdrożeniowe (TIG), które biorą abstrakcyjny tekst §6 CIR i pokazują, co robić w praktyce. Mapują każdą podsekcję na mechanizmy kontrolne ISO/IEC 27001:2022 (A.8.25 do A.8.32 dotyczące bezpiecznego rozwoju, A.5.20 do A.5.23 dotyczące relacji z dostawcami), więc istniejące certyfikacje dają przewagę na starcie.
Krajowe ustawy transponujące
Każde państwo członkowskie ma własną ustawę transponującą (Holandia: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Obowiązki wynikające z artykułu 21 ust. 2 lit. e) są takie same, ponieważ dyrektywa ustanawia jeden standard ogólnounijny. Różni się: na które ramy krajowe organ regulacyjny wskazuje jako praktyczną drogę.
Używamy SaaS, więc bezpieczny rozwój to zadanie dostawcy.
Częściowo słusznie. Dostawca odpowiada za kod. Ty nadal odpowiadasz za §6.1: udokumentowane wymagania bezpieczeństwa dla każdego produktu lub usługi IT, które kupujesz, plus walidacja, że dostawca je spełnia. Uwierzytelnianie, logowanie, wsparcie aktualizacji, lokalizacja danych, powiadamianie o naruszeniach. Jeżeli Twoja dokumentacja zakupowa jest pusta, obowiązek nie jest dopełniony, nawet jeśli dostawca jest doskonały.
Robimy przeglądy kodu, więc element SDLC jest pokryty.
Przegląd kodu to jedna praktyka. §6.2 wymaga udokumentowania całego cyklu życia: wymagania bezpieczeństwa podczas specyfikacji, zasady bezpiecznego kodowania (w tym security by design i zero-trust), zabezpieczone środowiska programistyczne, procedury testowania bezpieczeństwa przed wydaniem, staranne traktowanie danych testowych. Pojedyncza praktyka na szczycie nieudokumentowanego procesu nie spełnia tej sekcji.
Łatamy, kiedy zespół ma czas.
§6.6 wymaga odpowiedniego czasu powiązanego z dotkliwością, plus testowania przed produkcją i dokumentacji dla łatek awaryjnych. 'Kiedy jest czas' nie jest ramą czasową. Wybierz kadencję (np. krytyczne w ciągu 72 godzin, wysokie w ciągu 14 dni), zapisz ją, udowodnij w dzienniku zmian, że jej przestrzegasz. Audytor odtworzy historię Twoich łatek z systemu zgłoszeń.
Większość IT w niemieckim Mittelstandzie wygląda tak: 90 procent oprogramowania dostawców (ERP, kadry, poczta, współdzielenie plików, CRM), trochę spoiwa integracyjnego, sporadyczne skrypty wewnętrzne. Dużym ciężarem §6 dla tego profilu nie jest SDLC. To zakupy §6.1 i zarządzanie łatkami §6.6.
Napisz szablon wymagań bezpieczeństwa raz. Uwierzytelnianie, logowanie, ujawnianie podatności, wsparcie aktualizacji, region hostingu, eksport danych, powiadamianie o naruszeniach. Stosuj go do każdego nowego zakupu i każdego odnowienia. Połącz to z zapisaną kadencją łatania (krytyczne / wysokie / średnie, każde z ramą czasową) oraz dziennikiem zmian, którego wszyscy używają. To pokrywa większość §6 dla typowego Mittelstandu bez zatrudniania specjalisty od bezpieczeństwa oprogramowania.
Wbudowaliśmy wymagania zakupowe §6.1, dokumentację SDLC §6.2, dziennik zmian §6.4 i kadencję łatania §6.6 w moduł PRO platformy. Wypełniasz szablon zakupowy raz i używasz go ponownie. Każdy nowy produkt lub usługa IT przechodzi przez tę samą listę kontrolną bezpieczeństwa z zatwierdzeniem.
Dziennik zmian i kadencja łatania działają na tym samym śladzie audytowym co reszta platformy: zgłoszenie, zatwierdzający, plan wycofania, plik dowodowy. Zmiany awaryjne otrzymują formularz po fakcie. Nie prowadzisz osobnego dziennika zgodności. Gdy audytor pyta, jak załatałeś dany CVE, odpowiedzią jest jedno zapytanie, a nie trzy arkusze kalkulacyjne.
- Dyrektywa (UE) 2022/2555 (NIS 2), artykuł 21 ust. 2 lit. e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 (CIR), załącznik §6 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ustawa o BSI (BSIG), §30 ust. 2 pkt 5 w brzmieniu nadanym przez ustawę o wdrożeniu NIS2 i wzmocnieniu cyberbezpieczeństwa
- Moduły IT-Grundschutz BSI CON.8 'Software-Entwicklung' oraz OPS.1.1.3 'Patch- und Änderungsmanagement'
- Wytyczne techniczne wdrożeniowe ENISA dla CIR (UE) 2024/2690 (stan na maj 2026)