CISO przenoszą budżety z tradycyjnego zarządzania podatnościami (Vulnerability Management, VM) do symulacji włamań i ataków (Breach and Attack Simulation, BAS), ponieważ sztuczna inteligencja skróciła czas od publikacji podatności do działającego exploita z około 53 dni w 2024 roku do około 24 godzin w 2026 roku — podczas gdy mediana czasu załatania podatności aktywnie wykorzystywanej w atakach wydłużyła się do 43 dni. Gdy napastnik atakuje w ciągu godzin, a proces remediacji trwa tygodniami, powinniśmy coraz częściej zamiast pytać o istniejące podatności, pytać o to, „co realnie można wykorzystać przeciwko nam i czy nasze zabezpieczenia są na to gotowe?”.
To zmiana logiki zarządzania ryzykiem IT, którą warto zrozumieć już teraz, nie czekając na to, gdy wymuszą ją regulacje albo — co gorsza — incydent.
Trzydziestoletni model pracy już nie przystaje do rzeczywistości
Tradycyjne zarządzanie podatnościami przez trzy dekady opierało się na jednym cichym założeniu, zgodnie z którym między ujawnieniem podatności a jej uzbrojeniem w działający exploit mijały tygodnie lub miesiące. Ten bufor czasowy pozwalał działać metodycznie – skanować, oceniać według skali CVSS, planować łatanie w oknach serwisowych, testować i wdrażać łatki. Dane z 2026 roku pokazują, że ten bufor przestał istnieć.
Według Zero Day Clock średni czas od publikacji podatności do jej pierwszego potwierdzonego wykorzystania w atakach (time‐to‐exploit, TTE) spadł w 2026 roku z około 53 dni jeszcze w 2024 roku, do około 24 godzin.
Verizon Data Breach Investigations Report 2026, oparty na danych z ponad 13 000 organizacji, wskazuje, że 32% włamań zaczyna się od wykorzystania podatności w oprogramowaniu — częściej niż od phishingu czy skradzionych danych logowania — i prognozuje dalszy wzrost tego udziału. Dzieje się tak, ponieważ asystenci AI obniżyli próg wejścia — budowanie exploita, przenoszenie narzędzia na inny język programowania czy wyszukiwanie nowych błędów stało się dostępne dla napastników, którzy wcześniej nie mieli takich kompetencji.
Po stronie obrony trend jest odwrotny. Ten sam raport Verizon pokazuje, że średni czas usunięcia podatności z listy aktywnie wykorzystywanych (known‐exploited) wydłużyła się z 32 do 43 dni, a odsetek organizacji, które załatały je w pełni, spadł z 38% do 26%.
Nawet organizacje osiągające najlepsze wyniki zamykają w pierwszym tygodniu jedynie 30% ‑40% takich podatności — i ten wskaźnik od lat praktycznie się nie zmienia, mimo rosnących nakładów. Średnia liczba podatności known‐exploited wymagających załatania wzrosła w ciągu roku z 11 do 16, czyli o blisko pięćdziesiąt procent, a to dane sprzed fali podatności odkrywanych masowo przez modele AI.
Skalę tej fali ilustruje majowa aktualizacja badań Anthropic. Firma wraz z około 50 partnerami wykorzystała model Claude Mythos Preview do odnalezienia w ciągu jednego miesiąca ponad 10 000 podatności o wysokiej lub krytycznej istotności w oprogramowaniu o znaczeniu systemowym. Ten sam model, skierowany na przeglądarkę Firefox, napisał 181 działających exploitów (!). Poprzednia generacja modeli potrafiła stworzyć 2. Wśród znalezisk był błąd w OpenBSD, który pozostawał niewykryty przez 27 lat.
Dlaczego „łatajcie szybciej” nie jest strategią
Odruchową odpowiedzią na skrócenie czasu do exploita jest presja na szybsze łatanie — formułują ją regulatorzy, oczekują zarządy, zapisują ją w umowach klienci. Problem w tym, że remediacja nie jest przełącznikiem, który można przestawić. Każda łatka w środowisku produkcyjnym to zmiana, a zmiana to ryzyko operacyjne, które wymaga testów regresyjnych, okna serwisowego, akceptacji właściciela systemu i poszanowania zobowiązań dotyczących dostępności.
Z perspektywy zarządzania ciągłością działania wyłączenie krytycznego systemu produkcyjnego po to, by wyprzedzić exploit, bywa po prostu innym rodzajem utraty dostępności — tyle że wywołanym własnymi rękami. W projektach, które realizujemy dla instytucji finansowych i spółek energetycznych, analiza BIA regularnie pokazuje, że dla części systemów koszt nieplanowanego okna serwisowego jest porównywalny z kosztem umiarkowanego incydentu.
Drugi problem jednak ma większą wagę — priorytetyzacja według skali CVSS przestała cokolwiek priorytetyzować. Ocena istotności podatności nie mówi, czy błąd jest osiągalny w konkretnej architekturze, czy istniejące zabezpieczenia już go neutralizują ani czy da się go połączyć w łańcuch prowadzący do aktywów o znaczeniu krytycznym. Gdy dziennie pojawiają się setki zgłoszeń, a znaczna część nosi ocenę 9 lub 10, lista priorytetów, na której wszystko jest priorytetem, przestaje pełnić swoją funkcję. Zespoły bezpieczeństwa toną w zaległościach, których fizycznie nie da się nadrobić, i których liczba w dodatku rośnie szybciej, niż możliwości ich zamykania.
Czym jest breach and attack simulation (BAS) i co zmienia w logice zarządzania ryzykiem
Symulacja włamań i ataków (Breach and Attack Simulation, BAS) to technologia, która w sposób kontrolowany i bezpieczny odtwarza rzeczywiste techniki napastników, czyli taktyki, techniki i procedury (TTP) znane z bieżących kampanii, wykorzystywane przeciwko produkcyjnym mechanizmom prewencji i detekcji organizacji. Wynik symulacji daje organizacji wiedzę na temat tego, co istniejące zabezpieczenia faktycznie zablokują, co wykryją, a co przejdzie niezauważone.
Z perspektywy zarządzania ryzykiem operacyjnym BAS odpowiada na trzy pytania, na które samo zarządzanie podatnościami odpowiedzieć nie potrafi.
Po pierwsze, oddziela ryzyko teoretyczne od realnego. Podatność, którą zapora aplikacyjna i system detekcji na stacjach końcowych (EDR) już neutralizują, to zupełnie inny problem niż taka, która wchodzi do środowiska bez oporu, a traktowanie każdej z nich jak pożaru rozprasza zasoby.
Po drugie, weryfikuje skuteczność kontroli, za które organizacja już zapłaciła. Przeciętne duże przedsiębiorstwo utrzymuje od kilkunastu do kilkudziesięciu narzędzi bezpieczeństwa z nakładającymi się politykami, a BAS mierzy, czy działają one tak, jak skonfigurowano i gdzie kryje się ryzyko rezydualne.
Po trzecie — i to argument, który najlepiej rozumieją komitety ryzyka — kupuje czas na bezpieczne łatanie. Jeśli można wykazać, że krytyczne aktywo jest osłonięte działającymi kompensacyjnymi środkami kontroli, łatka może przejść normalny proces zarządzania zmianą zamiast awaryjnego wdrożenia nocą z soboty na niedzielę.
Gartner opisuje ten kierunek jako walidację ekspozycji na ataki (Adversarial Exposure Validation, AEV), polegająca na połączeniu pytania o skuteczność zabezpieczeń z kontekstem biznesowym. Pytanie dotyczy tego, które aktywa mają największe znaczenie i co jest do nich realnie osiągalne.
To także rdzeń koncepcji ciągłego zarządzania ekspozycją na zagrożenia (Continuous Threat Exposure Management, CTEM), z którą Gartner związał często cytowaną prognozę, zgodnie z którą organizacje priorytetyzujące inwestycje w bezpieczeństwo na podstawie programu ciągłego zarządzania ekspozycją mają być trzykrotnie mniej narażone na naruszenie. Rynek podąża za tą logiką — analitycy Mordor Intelligence wyceniają rynek BAS na około 1,3 miliarda dolarów w 2026 roku, z prognozą wzrostu do 3,6 miliarda do 2031 roku.
Uczciwość wymaga jednak dwóch zastrzeżeń. Znacząca część publikacji promujących tezę „VM umarło, kupcie BAS” pochodzi od dostawców platform BAS — również artykuł, który wywołał obecną dyskusję, powstał jako treść partnerska jednego z vendorów. Dane źródłowe (Verizon DBIR, badania Anthropic, statystyki TTE) bronią się same, ale wnioski zakupowe warto wyciągać z chłodną głową. Po drugie, BAS nie zastępuje zarządzania podatnościami, tak jak test planu ciągłości działania nie zastępuje samego planu. Łatanie pozostaje obowiązkiem — zmienia się mechanizm decydowania o kolejności i dowodzenia, że przyjęta kolejność jest bezpieczna.
Walidacja zamiast deklaracji, czyli lekcja, którą BCM odrobił dwadzieścia lat temu
Dla praktyków zarządzania ciągłością działania obecny zwrot w cyberbezpieczeństwie wygląda znajomo. BCM od dawna stoi na stanowisku, że plan ciągłości działania, który nie był testowany, jest hipotezą, a nie zabezpieczeniem. Dlatego dojrzałe organizacje ćwiczą scenariusze awarii, przełączają się na ośrodki zapasowe i mierzą rzeczywiste czasy odtworzenia zamiast poprzestawać na deklaracjach w dokumentacji.
BAS przenosi dokładnie tę filozofię na warstwę zabezpieczeń technicznych. Zgodnie z nią, zamiast wierzyć, że system EDR wykryje technikę opisaną w raporcie CERT, organizacja bezpiecznie ją odtwarza i sprawdza. W obu przypadkach chodzi o to samo — o zastąpienie papierowej pewności dowodem. Wiemy z własnej praktyki, że różnica bywa bolesna. W testach planów odtworzeniowych, które prowadzimy, rozbieżność między deklarowanym a rzeczywistym czasem odtworzenia systemów potrafi sięgać kilkuset procent, a analogiczne rozczarowania czekają organizacje, które po raz pierwszy skonfrontują konfigurację swoich narzędzi bezpieczeństwa z symulowanym atakiem.
Ten kierunek wzmacniają regulacje. Rozporządzenie DORA wymaga od podmiotów finansowych regularnego testowania operacyjnej odporności cyfrowej, z testami penetracyjnymi opartymi na analizie zagrożeń (TLPT) dla podmiotów o największym znaczeniu, a dyrektywa NIS2 nakłada na kadrę zarządzającą osobistą odpowiedzialność za nadzór nad zarządzaniem ryzykiem cyberbezpieczeństwa. W obu przypadkach regulator co prawda pyta, czy organizacja ma skaner podatności i politykę łatania, ale w ślad za tym, oczekuje, że organizacja potrafi wykazać, że jej zabezpieczenia działają wobec realistycznych scenariuszy ataku. Ciągła, zautomatyzowana walidacja zabezpieczeń jest naturalną odpowiedzią na tak postawione pytanie, zwłaszcza między kosztownymi testami TLPT, które z natury są ćwiczeniem punktowym.
Co z tym zrobić, zanim zrobi to za nas budżet
Niechęć zarządów do finansowania kolejnego narzędzia bezpieczeństwa jest wręcz legendarna — i akurat w tym przypadku bywa zdrowa, bo zakup platformy BAS bez przygotowania organizacyjnego podzieli los niejednego skanera, który generuje praktycznie nieczytane raporty. Sensowna sekwencja zaczyna się od zidentyfikowania aktywów krytycznych (to robimy w BCM) i ścieżek, którymi napastnik mógłby do nich dotrzeć, przez inwentaryzację i przegląd konfiguracji już posiadanych kontroli, po zdefiniowanie procesu, w którym wynik symulacji przekłada się na decyzję o pilnym łataniu, o mitygacji kompensacyjnej albo o świadomej akceptacji ryzyka, udokumentowanej w sposób możliwy do przedstawienia audytorowi i regulatorowi. Dopiero na tak przygotowany grunt warto wprowadzać automatyzację walidacji.
Jest też argument czysto finansowy, który warto przedstawić komitetowi budżetowemu. Przesunięcie części środków z rozbudowy skanowania do walidacji nie zwiększa wydatków na bezpieczeństwo. Zmienia ich strukturę tak, by ograniczony czas zespołów remediacyjnych trafiał tam, gdzie faktycznie zmieni to wynik jeśli chodzi o poziom odporności. Skoro nawet najlepsze organizacje zamykają w pierwszym tygodniu mniej niż połowę aktywnie wykorzystywanych podatności, wymaganie, by łatać wszystko szybciej nie da nam przewagi, bo to fizycznie niewykonalne. Przewagę da nam wiedza, które luki naprawdę wymagają trybu awaryjnego, a które mogą poczekać na normalne okno serwisowe pod osłoną działających kontroli. Oczywiście, nie daje nam to 100% pewności — takiej nikt uczciwy nie zadeklaruje — ale daje nami sposób na to, by ryzyko, które organizacja i tak akceptuje każdego dnia, akceptować świadomie i na podstawie dowodów, a nie nadziei opartej o statystyki.
FAQ
Czym różni się BAS od testu penetracyjnego? Test penetracyjny to punktowe ćwiczenie prowadzone przez ludzi, zwykle raz do roku, na wycinku środowiska. BAS działa w sposób ciągły i zautomatyzowany, odtwarzając znane techniki ataków przeciwko produkcyjnym zabezpieczeniom. Oba podejścia się uzupełniają — BAS nie zastępuje testów TLPT wymaganych przez DORA, ale wypełnia lukę między nimi.
Czy BAS zastępuje zarządzanie podatnościami? Nie. Łatanie pozostaje koniecznością, a skanowanie podatności — źródłem danych wejściowych. BAS zmienia sposób priorytetyzacji: zamiast kolejności według oceny CVSS decyzje opierają się na dowodach, które podatności są realnie możliwe do wykorzystania w danym środowisku i których nie osłaniają istniejące kontrole.
Czy symulowanie ataków w środowisku produkcyjnym jest bezpieczne? Dojrzałe platformy BAS korzystają z kurowanych, zweryfikowanych bibliotek scenariuszy, a nie z surowego generowania złośliwego kodu przez AI, i są projektowane tak, by nie zakłócać pracy systemów. Wdrożenie wymaga jednak analizy ryzyka i uzgodnienia zakresu — jak każde działanie w środowisku produkcyjnym.
Od czego zacząć, jeśli organizacja nie ma programu walidacji zabezpieczeń? Od analizy wpływu na biznes (BIA) i identyfikacji aktywów krytycznych, przeglądu konfiguracji posiadanych narzędzi bezpieczeństwa oraz zdefiniowania procesu decyzyjnego dla wyników walidacji. Samo narzędzie jest ostatnim, nie pierwszym krokiem.
Źródła:
- Verizon Data Breach Investigations Report 2026 Anthropic, Glasswing Initiative — aktualizacja badań, maj 2026
- Zero Day Clock — statystyki time‐to‐exploit 2024–2026 Gartner,
- Market Guide for Adversarial Exposure Validation 2026 Gartner, prognoza dotycząca Continuous Threat Exposure Management (CTEM) Mordor Intelligence,
- Breach and Attack Simulation Market Report 2026
- AWS Security Blog, AI‐augmented threat actor accesses FortiGate devices at scale, luty 2026
- The Hacker News, AI Broke Vulnerability Management, czerwiec 2026 (treść partnerska Picus Security)
Zanim zaczniesz walidować zabezpieczenia, musisz wiedzieć, co naprawdę wymaga ochrony. Sprawdź, jak analiza BIA może pomóc w ocenie krytyczności aktywów → Identyfikacja procesów i aktywów krytycznych | parametry RTO/RPO | podstawa priorytetyzacji podatności
