Znane luki, pozostawione bez poprawek.
Art. 21(2)(g) NIS 2 wymienia podstawowe praktyki higieny cybernetycznej wśród wymaganych środków, a jedną z najbardziej podstawowych jest utrzymywanie oprogramowania zaktualizowanego o znane luki. Jeśli poprawka dla opublikowanego doradztwa istnieje, a Ty jej nie stosujesz, celowo uruchamiasz znaną lukę. Ta decyzja jest zwykle podejmowana w manifeście, bazowym obrazie lub w kodzie.
The shapes the same control failure takes.
Higiena cybernetyczna ulega pogorszeniu, gdy zmiana pozostawia znaną, naprawialną lukę. Powtarzające się schematy:
Zależność jest zatrzymywana przed poprawką
Biblioteka z opublikowanym doradztwem jest przypięta do wersji dotkniętej luką zamiast zaktualizowanej do wersji naprawionej, aby unikać ponownego testowania.
Bazowy obraz jest zamrożony i nieobsługiwany
Bazowy obraz jest przypięty do starego tagu, który nie otrzymuje już aktualizacji bezpieczeństwa, więc znane luki się w nim gromadzą.
Mechanizm automatycznej aktualizacji jest wyłączony
Automatyzacja aktualizacji zależności lub obrazów jest wyłączona albo jej pull requesty są rutynowo zamykane, więc poprawki przestają być wdrażane.
Poprawka bezpieczeństwa jest cofana
Aktualizacja, która zamknęła lukę, jest wycofywana, ponieważ powodowała problemy, ponownie otwierając lukę.
Oprogramowanie końca życia jest utrzymywane
Środowisko uruchomieniowe lub biblioteka po zakończeniu wsparcia, które nie otrzymują już żadnych poprawek, jest zachowywane zamiast zostać zaktualizowane.
Zależność przypięta do wersji z znanym doradztwem.
Biblioteka ma opublikowane doradztwo bezpieczeństwa z dostępną wersją naprawioną. Zastosowanie poprawki oznaczałoby ponowne testowanie integracji, więc zmiana przypina ją z powrotem do wersji dotkniętej luką. Aplikacja nadal działa, ale na wersji z znaną, niezałataną luką.
"dependencies": {- "image-parser": "1.4.2"+ "image-parser": "1.3.0" }Przypięcie image-parser z powrotem do wersji 1.3.0 utrzymuje wersję z znanym, opublikowanym doradztwem, podczas gdy naprawiona wersja (1.4.2) jest dostępna. Art. 21(2)(g) (podstawowe praktyki higieny cybernetycznej) obejmuje utrzymywanie oprogramowania zaktualizowanego o znane luki. Zastosuj naprawioną wersję i przetestuj ponownie, zamiast utrzymywać wersję dotkniętą luką.
Higiena cybernetyczna jest sprawdzana na podstawie tego, co nadal uruchamiasz.
Inspekcja w ramach NIS 2 szuka dowodów na podstawową higienę: że znane luki są śledzone i łatane w rozsądnym czasie oraz że oprogramowanie jest utrzymywane w stanie wsparcia. Zmiana, która przypięła zależność z powrotem do wersji podatnej na luki, zamroziła nieobsługiwany bazowy obraz lub wyłączyła automatyzację aktualizacji, jest konkretnym zaniedbaniem stojącym za tym, i jest widoczna w diffie manifestu, pliku lockfile lub obrazu.
Przegląd, a nie skaner luk.
heygrc sygnalizuje zmiany, które dotyczą środków higieny NIS 2, i cytuje odpowiedni punkt, aby poprawka została wprowadzona w pull request. Nie uruchamia skanowania luk ani potoku poprawek. Wychwytuje moment, w którym zmiana pozostawia znaną, naprawialną lukę w kodzie, na poziomie diffu.