Ile kosztuje luka bezpieczeństwa, której nikt nie szukał

Firmy szukają w Google „audytu QA” i „testów regresyjnych” znacznie częściej niż „testów bezpieczeństwa”, mimo że koszt zaniedbanej luki bezpieczeństwa jest dziś wyższy niż koszt zaniedbanej regresji o cały rząd wielkości. To nie jest przypadek złej świadomości. To jest mechanizm: luka bezpieczeństwa, która nie została jeszcze wykorzystana, nie boli, więc nikt jej nie szuka, dopóki nie zamieni się w incydent. Wtedy szuka się już czegoś innego: prawnika, agencji PR i budżetu kryzysowego. Ten artykuł liczy, ile kosztuje ta różnica w czasie, opierając się wyłącznie na twardych, publicznych danych, nie na straszeniu.

Dlaczego nikt nie szuka luki, która jeszcze nie zabolała

Ludzie i organizacje szukają rozwiązań problemów, które już odczuwają. Regresja, która spowalnia release, boli co sprint, więc firmy aktywnie szukają narzędzi i usług, które ją skrócą. Luka w kontroli dostępu albo niezałatana zależność w bibliotece nie boli nigdy, dopóki ktoś jej nie wykorzysta. To sprawia, że popyt na testy bezpieczeństwa jest reaktywny, nie proaktywny: rośnie gwałtownie po głośnym incydencie w branży, a między incydentami wraca do zera, niezależnie od tego, jak realne jest ryzyko w danym momencie.

To jest problem, bo ryzyko bezpieczeństwa nie działa cyklicznie jak popyt na jego testowanie. Rośnie liniowo z każdym nowym releasem, każdą nową zależnością w kodzie i każdą nową integracją z zewnętrznym dostawcą. Innymi słowy: krzywa ryzyka rośnie cały czas, a krzywa zainteresowania testowaniem tego ryzyka rośnie skokowo, tylko po fakcie. W tej szczelinie mieszczą się miesiące, czasem lata, w których luka istnieje, nikt jej nie szuka, i nikt za nią nie płaci, dopóki nie zapłaci naraz, w całości, z odsetkami.

Ten sam wzorzec widzimy zresztą w rozmowach z klientami: pytania o strategię testowania, regresję czy audyt procesów QA padają regularnie, jako reakcja na widoczny, codzienny ból. Pytania o testy bezpieczeństwa padają rzadziej i najczęściej dopiero po incydencie w branży albo po wymogu od klienta czy regulatora. To nie jest dowód, że bezpieczeństwo nikogo nie obchodzi. To dowód, że obchodzi dopiero wtedy, gdy przestaje być abstrakcją, a staje się linią w budżecie po incydencie.

Warto to nazwać wprost, bo to zmienia sposób budżetowania. Testy bezpieczeństwa nie są ubezpieczeniem, które kupuje się raz i zapomina. Są kosztem stałym, który firma płaci raz na jakiś czas w małych ratach, żeby uniknąć jednorazowego rachunku, który w 2025 roku wynosił globalnie średnio 4,44 mln dolarów za jeden incydent, a w Stanach Zjednoczonych, gdzie regulacje i kary są surowsze, aż 10,22 mln dolarów.

Ciekawostka na marginesie, ale znacząca: globalny średni koszt naruszenia spadł w 2025 roku po raz pierwszy od pięciu lat, o dziewięć procent rok do roku. Nie dlatego, że ataków jest mniej, tylko dlatego, że firmy z rozwiniętymi procesami wykrywania i automatyzacji nadrabiają czas reakcji. Innymi słowy, cały rynek zaczyna się dzielić na dwie grupy: firmy, które inwestują w szybkość wykrycia i realnie płacą mniej, oraz firmy, które tego nie robią i płacą coraz więcej, bo napastnicy też stają się szybsi. Środek tej skali znika.

Skąd realnie biorą się włamania, nie z filmów

Warto rozbić mit hakera, który łamie szyfrowanie w piwnicy. Najnowszy raport Verizon Data Breach Investigations Report, oparty na analizie ponad 22 tysięcy incydentów i niemal 12,2 tysiąca potwierdzonych naruszeń danych, pokazuje coś dużo bardziej przyziemnego: większość skutecznych ataków zaczyna się od skradzionych danych logowania albo od wykorzystania znanej, niezałatanej podatności, nie od wyrafinowanego exploitu dnia zerowego.

Nadużycie danych logowania odpowiada za 22 procent incydentów, a wykorzystanie podatności w oprogramowaniu za kolejne 20 procent, razem ponad 40 procent wszystkich analizowanych przypadków. Co więcej, samo wykorzystanie podatności wzrosło rok do roku o 34 procent, a udział stron trzecich, czyli dostawców, bibliotek i integracji, w naruszeniach podwoił się do 30 procent. Przy atakach na podstawowe aplikacje webowe aż 88 procent wykorzystywało skradzione dane logowania.

Ta tabela pokazuje coś praktycznego: większość skutecznych ataków da się złapać testami, które nie wymagają zespołu ofensywnych hakerów. Testy kontroli dostępu, cykliczne skanowanie zależności i podstawowa higiena uwierzytelniania adresują ponad połowę realnych wektorów z raportu. To nie jest argument za tym, że pentesty są zbędne, tylko za tym, że większość ryzyka da się ograniczyć zanim w ogóle dojdzie do etapu, w którym pentest miałby sens.

Okno, w którym rozstrzyga się cały rachunek

Jest jedna liczba z badań branżowych nad cyberbezpieczeństwem, która tłumaczy, dlaczego czas reakcji jest ważniejszy niż sama świadomość zagrożenia. Mediana czasu między publicznym ujawnieniem podatności a jej faktycznym wykorzystaniem przez atakujących spadła w 2025 roku do około pięciu dni, a w części przypadków, analizowanych między innymi przez firmę Mandiant, atakujący wykorzystywali lukę jeszcze zanim producent zdążył wydać łatkę. Tymczasem średni czas, w jakim organizacje faktycznie łatają krytyczną podatność, wynosi około 137 dni.

Różnica między tymi dwiema liczbami, około 130 dni, to jest dokładnie to okno, w którym rozstrzyga się, czy incydent w ogóle się wydarzy. Testy bezpieczeństwa nie skracają czasu potrzebnego na wydanie łatki przez producenta biblioteki, ale skracają czas, w jakim wasza organizacja w ogóle dowiaduje się, że ta podatność jej dotyczy. Firma, która skanuje zależności cyklicznie, dowiaduje się o nowej krytycznej podatności w ciągu godzin od jej publikacji. Firma, która robi to raz na kwartał przy okazji audytu, dowiaduje się o niej średnio wiele tygodni po publikacji, czyli długo po tym, jak mediana ataków zdążyła się wydarzyć.

Co to znaczy w polskich realiach, nie tylko w amerykańskich raportach

Globalne raporty łatwo odsunąć jako „to dotyczy dużych korporacji za oceanem”. Dane Urzędu Ochrony Danych Osobowych z 2025 roku pokazują, że presja regulacyjna rośnie równie szybko w Polsce. UODO nałożył w 2025 roku blisko 64,5 mln zł kar, wydając ponad 2 tysiące decyzji administracyjnych i 32 kary pieniężne, wobec niespełna 14 mln zł kar rok wcześniej. Liczba skarg od osób fizycznych wzrosła do około 13 tysięcy, z 8 tysięcy w 2024 i 7 tysięcy w 2023, a do urzędu wpłynęło ponad 22 tysiące zgłoszeń samych naruszeń.

W całej Unii Europejskiej zgłoszenia naruszeń danych rosną w podobnym tempie, około 443 dziennie, czyli mniej więcej 22 procent więcej rok do roku. To nie jest trend, który się odwraca. To jest trend, w którym coraz więcej incydentów jest zgłaszanych, coraz więcej skarg trafia do regulatora, i coraz wyższe kary czekają na firmy, które nie potrafią wykazać, że traktowały bezpieczeństwo danych poważnie, zanim doszło do naruszenia.

Do tego dochodzi unijna dyrektywa NIS2, która wprost wymaga od szerokiej grupy podmiotów, nie tylko wielkich korporacji, wdrożenia środków zarządzania ryzykiem cybernetycznym oraz raportowania poważnych incydentów w krótkim, ustawowym terminie. Konsekwencja jest prosta: samo posiadanie dokumentu polityki bezpieczeństwa przestaje wystarczać. Trzeba umieć wykazać, że ryzyko jest realnie testowane i monitorowane, nie tylko opisane na papierze, bo dokładnie o to regulator zapyta, jeśli dojdzie do zgłoszenia.

Rachunek, który rzadko ktoś robi na głos

Zestawmy te liczby w jednym miejscu, bo osobno łatwo je zignorować, a razem układają się w konkretny mechanizm decyzyjny. Testy bezpieczeństwa aplikacji, prowadzone cyklicznie, kosztują ułamek rocznego budżetu IT średniej firmy. Jedno naruszenie danych kosztuje, wedle globalnej średniej z 2025 roku, 4,44 mln dolarów, a w Polsce dokłada się do tego ryzyko kary od UODO liczonej w milionach złotych, niezależnie od strat operacyjnych i reputacyjnych, które nie trafiają do żadnego raportu finansowego wprost.

Kluczowy jest jednak mechanizm czasu, nie tylko sama kwota. Naruszenia wykryte i opanowane w mniej niż 200 dni kosztowały w 2025 roku średnio 3,87 mln dolarów, a te, które trwały dłużej, aż 5,01 mln dolarów, różnica 29 procent, czyli dokładnie te 1,14 mln dolarów oszczędności widoczne w metrykach wyżej. Testy bezpieczeństwa nie eliminują ryzyka do zera, żadna firma tego nie obiecuje uczciwie, ale skracają czas między pojawieniem się luki a jej wykryciem, a to jest dokładnie ta zmienna, która najbardziej decyduje o koszcie końcowym.

Firmy, które inwestują w automatyzację i sztuczną inteligencję w procesach bezpieczeństwa, widzą to najwyraźniej: zespoły korzystające z tych narzędzi na szeroką skalę wykrywają naruszenia średnio o 51 dni szybciej niż zespoły bez nich, a różnica w koszcie całego incydentu sięga 1,9 mln dolarów. To nie jest argument za kupowaniem konkretnego narzędzia. To jest dowód na to, że szybkość wykrycia problemu jest dziś najsilniejszą dźwignią kosztową w całym temacie bezpieczeństwa, silniejszą niż samo posiadanie procedur na papierze.

Rachunek zaostrza się jeszcze bardziej w sektorach regulowanych. Ochrona zdrowia jest już czternasty rok z rzędu najdroższą branżą pod względem kosztu naruszenia danych, ze średnią 7,42 mln dolarów i czasem opanowania incydentu sięgającym 279 dni, dłużej niż średnia globalna. To dokładnie ten sam segment, w którym testy niezależne od producenta są dziś wymogiem prawnym, nie opcją. Jeśli działacie w bankowości, medycynie albo innym sektorze pod nadzorem regulacyjnym, koszt zaniedbanej luki bezpieczeństwa nie jest hipotetyczny, tylko liczony wprost w kosztach kary i naprawy reputacji, którą regulator i tak każe wam udokumentować.

Dlaczego to nigdy nie trafia na szczyt listy priorytetów

Mechanizm, który opisaliśmy w pierwszej sekcji, ma bezpośrednie przełożenie na to, jak wygląda planowanie budżetu w typowej firmie produktowej. Bezpieczeństwo konkuruje o budżet i uwagę zarządu z rzeczami, które mają widoczny, natychmiastowy efekt: nową funkcją, szybszym wydaniem, niższym kosztem infrastruktury. Testy bezpieczeństwa nie mają swojego odpowiednika „szybszego wydania”. Ich efektem jest brak zdarzenia, a brak zdarzenia jest z definicji niewidoczny.

To tworzy klasyczny problem asymetrii uwagi: koszt zaniedbania jest ogromny, ale odroczony i niepewny, a koszt inwestycji jest mały, ale natychmiastowy i pewny. Ludzki mózg, a za nim budżety firmowe, systematycznie faworyzują unikanie małego, pewnego kosztu nad ograniczaniem dużego, niepewnego ryzyka. Dlatego bezpieczeństwo tak łatwo spada na koniec listy, mimo że rachunek, który policzyliśmy wyżej, mówi coś dokładnie odwrotnego.

Praktyczna konsekwencja: jeśli czekacie, aż temat bezpieczeństwa sam się wybije na szczyt priorytetów, będziecie czekać albo do incydentu, albo do audytu zewnętrznego, który go tam wepchnie siłą. Obie ścieżki są droższe niż zaplanowanie tego świadomie, zanim ktokolwiek zapyta.

Typowy scenariusz wygląda tak: zespół produktowy planuje kwartał, na liście jest dziesięć zadań, z czego dwa są jawnie związane z bezpieczeństwem, na przykład aktualizacja biblioteki albo przegląd uprawnień. Pod presją terminu premiery nowej funkcji te dwa zadania przesuwają się „do następnego sprintu” trzy, cztery razy z rzędu, bo żadne z nich nie ma klienta, który zadzwoni i zapyta, dlaczego jeszcze nie zrobione. Nowa funkcja ma takiego klienta. Regresja ma takiego klienta, bo widać ją na pierwszy rzut oka. Kontrola dostępu, dopóki nikt jej nie złamie, klienta nie ma. To nie jest zła wola zespołu, tylko efekt tego, że priorytetyzacja z natury faworyzuje zadania z widocznym adresatem, a bezpieczeństwo do czasu incydentu adresata nie ma.

Co realnie obniża ten koszt, w skrócie

Nie chcemy tu powtarzać w całości checklisty, którą już opisaliśmy szczegółowo w osobnym artykule o minimalnym zestawie działań dla zarządów. W skrócie: dwie bramki w CI, które dają największy zwrot przy najmniejszym koszcie utrzymania, to analiza statyczna kodu i kontrola zależności bibliotek, bo to właśnie tam, zgodnie z danymi Verizon wyżej, mieści się największa część realnego ryzyka. Do tego dochodzą cykliczne testy dynamiczne i osobna kategoria testów kontroli dostępu, bo błędy w uprawnieniach są jednocześnie najdroższe i najczęściej pomijane w codziennej regresji.

Źródło: Verizon 2025 DBIR, IBM Cost of a Data Breach Report 2025.

Pełny, dziesięciopunktowy zestaw działań, łącznie z gotowością na incydent i dashboardem dla zarządu, opisaliśmy krok po kroku w artykule Testy bezpieczeństwa aplikacji: minimalny zestaw działań dla zarządów. Ten artykuł odpowiada na pytanie „co robić”, tamten na pytanie „ile to kosztuje, jeśli tego nie zrobicie”.

Nasza perspektywa

W Quality Island testy bezpieczeństwa są jedną z naszych podstawowych linii usługowych, obok testów funkcjonalnych, regresyjnych, wydajnościowych i dostępności. Nasze szkolenie „Cybersecurity, testy bezpieczeństwa” należy do bestsellerów w naszym katalogu, co samo w sobie jest sygnałem: firmy nie pytają nas o to, bo mają nadmiar czasu, tylko dlatego, że coraz częściej rozumieją, że to nie jest temat, który da się przełożyć na później bez konsekwencji.

Pierwszy wniosek z naszej pracy w tym obszarze: firmy, które traktują testy bezpieczeństwa jako jednorazowy audyt raz w roku, dostają dokładnie to, za co płacą, czyli zdjęcie stanu z jednego dnia, które starzeje się z każdym kolejnym wdrożeniem. Bezpieczeństwo, tak jak jakość ogólnie, działa tylko jako proces ciągły, nie jako projekt z datą zakończenia.

Drugi wniosek: najdroższe błędy nie są tymi najbardziej wyrafinowanymi. Zgodnie z danymi, które przytoczyliśmy wyżej, najczęstsze realne wektory ataku to rzeczy podstawowe: słabe zarządzanie danymi logowania, niezałatane zależności, brak kontroli nad integracjami z dostawcami. To dobra wiadomość dla firm z ograniczonym budżetem, bo oznacza, że pierwsze, najtańsze kroki dają nieproporcjonalnie duży efekt, zanim w ogóle trzeba sięgnąć po drogie narzędzia klasy enterprise.

Trzeci wniosek, szczególnie istotny dla firm z sektora regulowanego: testy bezpieczeństwa i niezależność wykonawcy to dwa osobne tematy, które w praktyce się przenikają. Pisaliśmy już o tym, co dokładnie sprawdza kontroler przed podpisaniem umowy na testy niezależne od producenta. Warto wiedzieć, że te same pytania o niezależność, udokumentowaną metodykę i ślad audytowy dotyczą też testów bezpieczeństwa, jeśli mają one stanowić dowód należytej staranności przed regulatorem, nie tylko wewnętrzną checklistę.

Co zrobić, jeśli u was ten temat wciąż czeka na lepszy moment

Lepszego momentu nie będzie, dopóki ktoś go nie wymusi zewnętrznie, albo incydentem, albo audytem klienta czy regulatora. Jeśli wolicie zdecydować o momencie sami, dobry punkt startowy to trzy pytania, które da się zadać na najbliższym spotkaniu zarządu, bez czekania na budżet na pełny program bezpieczeństwa.

Źródło: opracowanie własne Quality Island na podstawie Verizon 2025 DBIR i IBM Cost of a Data Breach Report 2025.

Jeśli na którekolwiek z tych pytań odpowiedź brzmi „nie wiemy”, to jest dokładnie ta luka, o której mówi tytuł tego artykułu: nikt jej nie szuka, dopóki nie zaboli, a wtedy boli dokładnie tyle, ile pokazują liczby wyżej.

Powiązane na Strefie QA

• Testy bezpieczeństwa aplikacji: minimalny zestaw działań dla zarządów
• Jak testować zgodność z RODO, nie blokując całego developmentu
• Audyt niezależny od producenta: co naprawdę sprawdza kontroler, zanim podpiszecie umowę

Źródła:

• IBM, Cost of a Data Breach Report 2025
• Verizon, 2025 Data Breach Investigations Report
• Urząd Ochrony Danych Osobowych, statystyki kar i zgłoszeń 2025
• Testy bezpieczeństwa aplikacji, Quality Island