„Zarządzanie podatnościami" to termin, którego używają niemal wszyscy — i niemal każdy rozumie przez niego coś innego. Dla jednych to skaner i raport. Dla innych comiesięczne zestawienie CVE wysyłane do IT. W praktyce te dwie rzeczy rzadko prowadzą do tego, co naprawdę się liczy: do naprawionej podatności na systemie, który faktycznie był narażony.
Problem
W wielu organizacjach proces wygląda tak: skaner robi swoje, generuje listę, lista trafia do raportu, raport trafia do kogoś, kto nie ma czasu albo mandatu, żeby cokolwiek z nim zrobić. Liczba podatności rośnie z miesiąca na miesiąc. Skaner działa bez zarzutu. Procesu nie ma.
Problem zaczyna się wtedy, gdy mylimy wykrywanie z zarządzaniem. Wykrycie to dopiero dane. Zarządzanie to decyzje podejmowane na tych danych.
Dlaczego to ma znaczenie
Vulnerability Management często odpowiada na jedno pytanie: „Co mamy podatne?". To ważne pytanie, ale samo w sobie nic nie zmienia. Lista 4000 CVE nie mówi, od czego zacząć ani kto ma to zrobić.
Vulnerability Engineering zaczyna się tam, gdzie kończy się lista. Zadaje pytania, które prowadzą do działania:
- gdzie ta podatność faktycznie działa?
- czy ten system jest w ogóle wystawiony?
- kto jest jego właścicielem?
- czy istnieje exploit i czy jest aktywnie wykorzystywany?
- czy jest patch?
- jaki to ma wpływ na biznes?
- kto ma to naprawić i do kiedy?
- jak sprawdzimy, że podatność faktycznie zniknęła?
To nie jest inny zestaw narzędzi. To inny sposób myślenia o tym samym wyniku skanu.
Przykład z organizacji
Dobry przykład to rejestr kontenerów. Wyobraź sobie Harbor ze skanowaniem Trivy, który robi dokładnie to, do czego został postawiony — skanuje każdy obraz i znajduje tysiące podatności. Z perspektywy „co mamy podatne" wszystko działa. Lista jest długa i kompletna.
Tylko że ta lista nie odpowiada na żadne z pytań, które naprawdę mają znaczenie. Nie wiadomo, kto jest właścicielem obrazu — bo obrazy wrzucali różni administratorzy na podstawie maili, bez żadnego modelu odpowiedzialności. Nie wiadomo, czy obraz z setką krytycznych CVE w ogóle gdzieś działa, czy leży w rejestrze od dwóch lat i nikt go nie uruchamia.
znaleziska w rejestrze ≠ ryzyko w runtime
To jest różnica, którą Vulnerability Engineering nazywa wprost. Obraz w rejestrze to potencjał. Ten sam obraz uruchomiony na wystawionym klastrze to realne ryzyko. Skaner widzi jedno. Decyzja wymaga drugiego.
Dopóki nie wiesz, który obraz gdzie działa i kto za niego odpowiada, masz listę podatności — nie masz zarządzania ryzykiem.
Dobre praktyki
- Traktuj wynik skanu jako wejście do procesu, nie jako produkt końcowy.
- Każdą podatność kotwicz do czterech rzeczy: zasobu, właściciela, ekspozycji i decyzji.
- Oddzielaj to, co jest w rejestrze czy repozytorium, od tego, co faktycznie działa. To dwa różne problemy i wymagają dwóch różnych inwentaryzacji.
- Zbuduj model właścicielstwa, zanim zaczniesz ścigać liczby. Bez właściciela żadna podatność nie zostanie naprawiona w sposób powtarzalny.
- Trzymaj każde narzędzie przy jego naturalnym zadaniu: skaner do wykrywania, system do śledzenia remediacji, źródło runtime do ustalania, co naprawdę działa.
Najczęstsze błędy
- Mylenie CVSS z priorytetem. CVSS mówi, jak groźna może być podatność, nie jak groźna jest u Ciebie.
- Uznawanie, że zgłoszenie podatności jest równoznaczne z jej naprawą.
- Brak właściciela — najczęstsza przyczyna podatności, które żyją w organizacji latami.
- Mylenie znalezisk w rejestrze z ryzykiem produkcyjnym.
- Używanie narzędzia niezgodnie z jego naturą, np. SIEM jako bazy właścicielstwa albo skanera jako miejsca docelowego logów.
Podsumowanie
Vulnerability Management odpowiada na pytanie „co mamy podatne". Vulnerability Engineering odpowiada na pytanie „co z tym zrobimy, kto i kiedy". Pierwsze to dane. Drugie to proces, komunikacja i odpowiedzialność.