Brak patcha nie oznacza braku działania. Oznacza trudniejszą decyzję. A istnienie patcha nie oznacza, że sprawa jest załatwiona — to dopiero początek pracy. Remediacja to ścieżka z dwiema gałęziami, a nie pojedyncze zdarzenie „wyślij zgłoszenie".
Problem
Dwa lustrzane błędy. Pierwszy: „jest patch" traktowane jak koniec pracy — zgłoszenie poszło, sprawa „zamknięta", a poprawka miesiącami nie trafia na produkcję. Drugi: „nie ma patcha" traktowane jak „nic nie da się zrobić" — podatność siedzi, bo czekamy na dostawcę.
Oba prowadzą do tego samego: ryzyko zostaje, mimo że na liście status wygląda na obsłużony.
Dlaczego to ma znaczenie
brak patcha ≠ brak działania
Po ustaleniu priorytetu remediacja rozdziela się na dwie gałęzie — i każda ma swój zestaw kroków:
Przykład z organizacji
Podatność w bibliotece używanej przez usługę w kontenerze. Gałąź „patch jest": aktualizujemy zależność, przebudowujemy obraz, wdrażamy — i potem sprawdzamy w runtime, że na klastrze działa już nowa wersja. To ostatni krok bywa pomijany: nowy obraz ląduje w rejestrze, a stary nadal chodzi na produkcji. Z perspektywy rejestru „naprawione", z perspektywy ryzyka — nie.
Gałąź „patch-a nie ma": dostawca nie wydał jeszcze poprawki, a podatność jest w usłudze wystawionej do internetu. Nie czekamy bezczynnie — ograniczamy ekspozycję, dokładamy regułę na WAF i monitoring, a pozostałe ryzyko świadomie akceptujemy na 30 dni, z konkretnym właścicielem i datą przeglądu. To nie jest „odpuszczenie". To decyzja z nazwiskiem i terminem.
Dobre praktyki
- Nawet gdy patch jest: przypisz właściciela, okno, testy i zweryfikuj efekt w runtime.
- Gdy patcha nie ma: warstwuj działania kompensacyjne, żeby kupić czas.
- Akceptację ryzyka rób jawnie — z właścicielem ryzyka i datą ważności, nie przez zaniechanie.
- Przeliczaj decyzję w czasie — pojawi się patch albo zmieni się wykorzystywalność.
- Status „naprawione" potwierdzaj reskanem i stanem runtime, nie samą obecnością nowego artefaktu.
Najczęstsze błędy
- „Jest patch" traktowane jak zamknięcie sprawy.
- „Nie ma patcha" traktowane jak brak możliwości działania.
- Cicha akceptacja ryzyka — bez właściciela, bez terminu, bez przeglądu.
- Weryfikacja tylko w rejestrze, podczas gdy stara wersja dalej działa.
- Wdrożenie bez testów, które wywraca produkcję i podkopuje zaufanie do remediacji.
Podsumowanie
Dostępność patcha to nie odpowiedź „tak/nie" na pytanie, czy mamy problem. To rozwidlenie ścieżki. Gdy poprawka jest — pracę dopiero zaczynasz i kończysz ją na produkcji, nie w rejestrze. Gdy jej nie ma — masz trudniejszą, ale wciąż realną decyzję do podjęcia. W obu przypadkach kluczowe jest to samo: właściciel, termin i potwierdzony efekt.