Dlaczego każda podatność powinna mieć właściciela?

Największym problemem w podatnościach często nie jest brak patcha. Jest brak właściciela. Poprawka zwykle istnieje — gorzej, że nie ma nikogo, kto czuje się odpowiedzialny, żeby ją wdrożyć.

Problem

Cykl życia zgłoszenia w wielu organizacjach wygląda tak: skaner wykrywa, SOC zgłasza, Security opisuje i przekazuje „do IT". I tu zgłoszenie znika. Bo „IT" to nie jest właściciel — to worek, do którego trafiają rzeczy niczyje. Pytanie „czyje to jest?" nie ma odpowiedzi, więc nie ma też decyzji ani terminu.

Podatność, która nie ma właściciela, jest operacyjnie niewidzialna. Istnieje na liście, ale nie istnieje w niczyim planie pracy.

Dlaczego to ma znaczenie

kto ją zgłosił ≠ kto ją naprawi

Wykrycie, zgłoszenie i opisanie to trzy różne czynności trzech różnych zespołów — i żadna z nich nie jest naprawą. Skaner, SOC i Security mogą zrobić wszystko po swojej stronie, a podatność i tak zostanie, dopóki ktoś z mandatem nie podejmie decyzji i nie wdroży poprawki.

Co więcej, „właściciel" to nie jedna rola. To co najmniej trzy, które zbyt często się zlewają:

Właściciel zasobu: odpowiada za system, na którym podatność występuje.

Właściciel remediacji: faktycznie wykonuje poprawkę — często zespół, nie pojedyncza osoba.

Właściciel ryzyka: ma mandat, żeby zaakceptować ryzyko, gdy naprawa jest niemożliwa albo odłożona.

Kiedy te role nie są rozdzielone i przypisane, nikt nie działa — bo każdy zakłada, że robi to ktoś inny.

Przykład z organizacji

Wróćmy do rejestru kontenerów. Obrazy trafiały do Harbora od różnych administratorów, na podstawie maili, bez żadnego modelu odpowiedzialności. Skaner znajdował krytyczne CVE, ale przy każdym z nich zatrzymywaliśmy się na pytaniu, na które nikt nie umiał odpowiedzieć: „czyj to obraz?". Bez tej odpowiedzi nie da się przypisać remediacji — można tylko odbijać zgłoszenie między zespołami.

Rozwiązaniem nie jest mocniejszy apel „naprawcie swoje podatności". Jest model, który przypisuje właściciela automatycznie — ze struktury, nie z dobrej woli:

nazwane projekty per zespół zamiast wspólnego worka,
osobne konta techniczne (robot accounts) per pipeline, żeby było wiadomo, skąd obraz pochodzi,
a przede wszystkim widoczność runtime — to, co faktycznie działa i gdzie, jest najbardziej wiarygodnym sygnałem właścicielstwa.

Tu jest ważny szczegół: logi pobrania obrazu czy historia maili to nie to samo, co właścicielstwo. Pokazują, kto coś kiedyś wziął — nie kto za to dziś odpowiada. Dopiero to, co działa w runtime, mówi, czyj to problem naprawdę.

Dobre praktyki

Przypisuj właścicielstwo strukturą, nie apelem — dobra wola nie skaluje się.
Rozdziel trzy role: właściciela zasobu, remediacji i ryzyka.
Używaj widoczności runtime jako nadrzędnego sygnału właścicielstwa.
Traktuj „brak właściciela" jako osobne znalezisko do zamknięcia, nie pustą rubrykę.
Zbuduj model właścicielstwa, zanim zaczniesz ścigać liczby remediacji.

Najczęstsze błędy

Zakładanie, że wykrycie podatności to już jej przypisanie.
Przekazywanie podatności „do IT" jak do worka bez nazwiska.
Mylenie logów pobrania albo historii maili z właścicielstwem.
Zlewanie tego, kto zgłasza, z tym, kto naprawia.
Próba remediacji, zanim w ogóle wiadomo, kto za co odpowiada.

Podsumowanie

Skaner wykryje, SOC zgłosi, Security opisze — ale dopóki podatność nie ma właściciela, nie ma też naprawy. Właścicielstwo to nie formalność w tabelce. To warunek, żeby cokolwiek się wydarzyło. I jak prawie wszystko w Vulnerability Engineering, wynika ze struktury, nie z dobrych chęci.