Twierdzenie Schneiera o wykrywaniu luk przez AI wywiera presję na naprawę oprogramowania

Krótkie omówienie artykułu Bruce’a Schneiera z 2 listopada zwraca uwagę na zaskakujące twierdzenie: 3% historycznie zarejestrowanych krytycznych luk w oprogramowaniu wykryto w ciągu jednego miesiąca. Dostarczony fragment jego wpisu AI Vulnerability Finding prognozuje również około 100 000 dodatkowych odkryć rocznie. Liczby te nie zostały tu zweryfikowane, jednak udokumentowane ustalenia już teraz wywierają presję na zespoły odpowiedzialne za naprawę oprogramowania.

Sednem konfliktu jest tempo wykrywania w porównaniu ze zdolnością do usuwania problemów. Wykrycie luki bezpieczeństwa stwarza szansę na ochronę użytkowników. Tworzy też pracę: ktoś musi zweryfikować zgłoszenie, ocenić zakres narażenia, sprawdzić poprawkę i dostarczyć aktualizację. Automatyzacja wykrywania nie przyspiesza automatycznie każdej kolejnej decyzji.

Anthropic, Google i Mozilla stanowią przydatne punkty odniesienia, choć ich dane mierzą różne rzeczy. Ich publikacje wspierają węższy, ale istotny wniosek: zautomatyzowane badania bezpieczeństwa przynoszą rzeczywiste odkrycia, podczas gdy metody liczenia i dalsze rezultaty wymagają dokładnej analizy. Dla programistów i nabywców korporacyjnych pytanie brzmi, czy szybsze wykrywanie przekłada się na mniejszą ekspozycję.

Co faktycznie potwierdza twierdzenie o wykrywaniu luk przez AI

Nagłówkowa statystyka jest tropem badawczym, a nie niezależnie potwierdzonym pomiarem krytycznych luk w oprogramowaniu na świecie.

Dostarczony fragment powiązany z wpisem Schneiera o wykrywaniu luk przedstawia te liczby jako komentarz. W tej analizie nie udało się pobrać oryginalnej strony. W konsekwencji fragment nie ustala, kto obliczył ten odsetek, które rekordy uwzględniono ani jak zdefiniowano okres raportowania.

To rozróżnienie ogranicza zakres wniosków, które można odpowiedzialnie wyciągnąć z tego twierdzenia. Uderzający odsetek może trafnie opisywać konkretną bazę danych, nie opisując jednak każdej luki bezpieczeństwa kiedykolwiek wykrytej. Może też wprowadzać w błąd, gdy czytelnicy niepostrzeżenie zastępują pierwotny mianownik szerszą populacją.

Wykrycie, ujawnienie i publikacja w bazie danych to różne zdarzenia. Badacz może prywatnie zidentyfikować lukę, zanim dostawca ją potwierdzi. Dokumentacja publiczna może pojawić się później, wraz z aktualizacją oprogramowania. Miesięczny skok publikacji nie dowodzi zatem, że wszystkie podstawowe luki wykryto właśnie w tym miesiącu.

Sformułowanie „cała zarejestrowana historia” dodaje kolejną nierozwiązaną granicę. Audytowalne wyliczenie wymaga wskazanej bazy danych, datowanego zrzutu oraz spójnych zasad uwzględniania wpisów. Wymaga też wyjaśnienia kwestii duplikatów, odrzuconych zgłoszeń oraz luk, których ocena ważności zmieniła się po publikacji.

Roczna prognoza wprowadza osobne założenie: że obecne tempo się utrzyma. Założenie to zasługuje na zbadanie nawet wtedy, gdy pierwotny miesięczny wynik okaże się trafny. Skoncentrowana kampania badawcza, zaległości publikacyjne lub skoordynowane wydanie mogą spowodować przejściowy wzrost bez potwierdzenia stabilnej rocznej stopy.

Występuje również problem kategoryzacji. Fragment zaczyna się od krytycznych luk, lecz następnie szerzej odnosi się do błędów i historycznej łącznej liczby luk. Nie można zamiennie stosować tych kategorii bez sprawdzenia podstawowych obliczeń. Defekt oprogramowania, potwierdzona luka bezpieczeństwa i luka krytyczna opisują różne populacje.

Żadne z tych ograniczeń nie czyni szerszego zjawiska nieistotnym. Wyznaczają one granicę pewności. Da się obronić narrację dotyczącą udokumentowanej aktywności odkrywczej i jej konsekwencji operacyjnych, zamiast niepotwierdzonego twierdzenia o precyzyjnie zmierzonym historycznym punkcie zwrotnym.

Dla osób, które zetknęły się z AI Vulnerability Finding poprzez posty w mediach społecznościowych, to rozróżnienie chroni użyteczny wniosek. Zespoły bezpieczeństwa mają powód, aby już teraz przeanalizować swoje możliwości. Nie muszą akceptować niezweryfikowanego odsetka, zanim sprawdzą, czy ich własne procesy wykrywania i naprawy nie stają się niezrównoważone.

Raportowane wyniki Anthropic pokazują skalę, ale z ważnymi ograniczeniami

Opublikowane przez Anthropic dane wspierają twierdzenie o znaczącej skali wykrywania, ale nie potwierdzają historycznego odsetka ani miesięcznej ekstrapolacji z komentarza.

W ogłoszeniu z 6 października dotyczącym programu weryfikacji cyberbezpieczeństwa Anthropic podał, że między kwietniem a lipcem zweryfikował co najmniej 129 000 luk w oprogramowaniu u partnerów. Osobno firma zgłosiła 5 500 zweryfikowanych ustaleń ze skanowania projektów open source między kwietniem a październikiem.

Firma podała, że ponad 33 000 zweryfikowanych luk otrzymało ocenę krytyczną lub wysoką. Są to wyniki raportowane przez firmę, a nie niezależnie odtworzony spis. Ich okresy i kategorie różnią się też od twierdzenia zawartego w dostarczonym komentarzu, dotyczącego krytycznych luk wykrytych w ciągu miesiąca.

Anthropic ujawnił istotne ograniczenia. Raportowanie wpływu oparto na częściowych informacjach od 33 partnerów, a organizacje stosowały różne podejścia do triage’u. Mniej niż połowa podała liczbę załatanych przypadków. W rezultacie firma opisała raportowany wskaźnik poprawek jako znacząco niepełny.

Te granice mają znaczenie, ponieważ różne pomiary odpowiadają na różne pytania. Liczba ustaleń mierzy raportowaną skalę wykrywania. Liczba potwierdzonych przypadków dodaje etap walidacji. Liczba załatanych przypadków opisuje późniejszy rezultat, natomiast dowody wdrożenia wskazują, czy dotknięci użytkownicy rzeczywiście otrzymali ochronę.

Implikacje konkurencyjne powinny więc pozostać wąskie. Anthropic raportuje wyniki organizacji uczestniczących w programie i korzystających z jego modeli. Badacze zagrożeń Google analizują szersze wzorce ujawniania i wykorzystywania luk. Publikacje te oferują uzupełniające się perspektywy, ale żadna nie przedstawia kontrolowanego porównania dowodzącego, który dostawca zapewnia lepsze wyniki bezpieczeństwa.

Dla nabywców oznacza to, że łączna liczba wykryć powinna rozpoczynać rozmowę, a nie ją rozstrzygać. Dostawca generujący więcej zgłoszeń może wykrywać wcześniej pomijane problemy. Może też wymagać więcej czasu na weryfikację po stronie klienta, zwłaszcza gdy raportom brakuje wyraźnych dowodów odtworzenia lub informacji o dotkniętych wersjach.

Użyteczna ocena rozróżniałaby nowe, zaakceptowane luki od wcześniej znanych problemów i zduplikowanych zgłoszeń. Oddzielałaby również proponowane poprawki od poprawek sprawdzonych. Takie rozróżnienia utrudniają porównania, ale łączą wynik techniczny z pracą, którą klient musi wykonać.

Presja szczególnie mocno spada na organizacje posiadające istotne oprogramowanie, lecz bez dużego, wyspecjalizowanego zespołu bezpieczeństwa. Zdolność wykrywania można kupić lub pozyskać z zewnątrz. Odpowiedzialność za zaakceptowanie zgłoszenia i zmianę produktu nadal jednak musi gdzieś spoczywać, nawet gdy pierwotna analiza przychodzi automatycznie.

To analityczna konsekwencja raportowanej skali, a nie zmierzony wynik dotyczący zatrudnienia w całej branży. Jeśli liczba napływających zweryfikowanych zgłoszeń rośnie, podczas gdy zdolność ich przeglądu pozostaje stała, nierozwiązana kolejka się wydłuża. Dokładne tempo zależy od oprogramowania każdej organizacji, używanych narzędzi i możliwości wprowadzania bezpiecznych zmian.

Dlatego najważniejsze pytanie uzupełniające po ogłoszeniu Anthropic dotyczy ukończenia procesu. Ile zaakceptowanych ustaleń trafiło do wspieranych wydań? Jak długo pozostawały nierozwiązane? Bez porównywalnych odpowiedzi duże liczby wykryć wyraźniej pokazują aktywność niż zmniejszoną ekspozycję.

Opiekunowie oprogramowania przejmują pracę po wykryciu luki

Organizacje utrzymujące podatne oprogramowanie ponoszą operacyjny ciężar przekształcenia zgłoszenia w ochronę.

Zmiany w bazie luk NIST z 15 kwietnia ilustrują presję na infrastrukturę informacyjną otaczającą prace nad bezpieczeństwem. Agencja podała, że zgłoszenia luk wzrosły o 263% między 2020 a 2025 rokiem. Stwierdziła, że nawet zwiększona wydajność przetwarzania nie pozwalała dotrzymać tempa.

NIST zmienił sposób wzbogacania wpisów w National Vulnerability Database, swoim publicznym repozytorium informacji o lukach. Wzbogacanie dodaje szczegóły, takie jak oceny ważności i dotknięte produkty. W zmienionym podejściu wybrane kategorie otrzymują priorytet, podczas gdy pozostałe wpisy pozostają widoczne bez natychmiastowego wzbogacenia.

Agencja nadała priorytet znanym aktywnie wykorzystywanym lukom, oprogramowaniu używanemu przez administrację federalną oraz określonemu oprogramowaniu krytycznemu. Przyznała również, że kryteria te nie obejmą każdego potencjalnie istotnego problemu. Zmiana ta dokumentuje ograniczenie możliwości; nie dowodzi, że AI spowodowała bazowy wzrost liczby zgłoszeń.

Szerszy wniosek jest taki, że rosnący strumień odkryć wymaga więcej niż dodatkowych wierszy w bazie danych. Opiekunowie i klienci potrzebują wiarygodnego kontekstu, aby zdecydować, co zasługuje na uwagę. Brakujący lub opóźniony kontekst może przenieść pracę interpretacyjną na zespoły już odpowiedzialne za ocenę własnych systemów.

Dla opiekuna oprogramowania otrzymanie wiarygodnego zgłoszenia tworzy kilka obowiązków, których nie da się sprowadzić do przeczytania jego konkluzji. Należy zrozumieć dotknięte zachowanie. Proponowana poprawka musi pasować do otaczającej architektury. Wspierane wersje i zależne komponenty mogą wymagać odrębnych decyzji.

Użytkownicy korporacyjni napotykają kolejną warstwę interpretacji. Podatny komponent może znajdować się w produkcie, który kupują, a nie utrzymują bezpośrednio. Muszą wiedzieć, które zainstalowane wersje są dotknięte, czy podatne zachowanie jest dostępne oraz jakie działanie wspiera ich dostawca.

Są to przykładowe zależności operacyjne, a nie ustalenia, że każda organizacja doświadcza tych samych zaległości. Ich znaczenie wynika z różnicy między wykryciem a remediacją, czyli procesem usunięcia lub ograniczenia luki. Zgłoszenie ma wartość tylko wtedy, gdy ktoś może podjąć na jego podstawie świadomą decyzję.

Nierównowaga bodźców zasługuje na uwagę. Platforma wykrywania może natychmiast eksponować swoje ustalenia, podczas gdy opiekun otrzymuje mniej widoczne uznanie za staranną weryfikację i bezproblemowe aktualizacje. Nabywcy powinni dostrzegać, że wolumen raportowania i jakość utrzymania stanowią różne wkłady w bezpieczeństwo.

Wspólna dokumentacja staje się użyteczna, gdy decyzje przekraczają granice zespołów. Przeszukiwalna baza wiedzy może pomóc łączyć zapisy techniczne, decyzje dotyczące odpowiedzialności i materiał dowodowy. Wspiera koordynację; walidacja i zatwierdzenie wydania nadal wymagają odpowiedniego procesu inżynieryjnego.

Praktyczna presja ma charakter organizacyjny równie mocno jak techniczny. Szybsze wykrywanie wymusza jaśniejsze przypisanie odpowiedzialności za zgłoszenia, poprawki i decyzje wdrożeniowe. Gdy te obowiązki pozostają niejednoznaczne, większy strumień uzasadnionych ustaleń może ujawnić słabości procesu reakcji, zanim ulepszy produkt.

Mozilla pokazuje, dlaczego wykrycie wymaga pełnego procesu naprawy

Opis Mozilli stanowi konkretny przykład wspomaganego przez AI wykrywania połączonego z dostarczonymi zmianami w oprogramowaniu.

Raport Mozilli o procesie wzmacniania Firefoksa opisuje integrację modeli z infrastrukturą testową i cyklem obsługi błędów bezpieczeństwa. Zespół twierdzi, że użyteczna skala wymagała odtwarzalnych testów, wykrywania duplikatów, triage’u, śledzenia i prac nad wydaniem. Podał, że naprawił 271 ustaleń Mythos Preview w Firefox 150.

To samo konto wyjaśnia, dlaczego sumy w bazach danych wymagają ostrożności: Mozilla grupuje wiele zgłoszonych wewnętrznie błędów pod wspólnymi identyfikatorami podatności. Podana przez nią liczba błędów nie odpowiada więc bezpośrednio liczbie publicznych identyfikatorów. Liczenie którejkolwiek z tych populacji bez wyjaśnienia tej zależności może wprowadzać czytelników w błąd.

Mozilla odróżnia też poważny błąd od praktycznego przejęcia systemu. Jej warstwowa architektura przeglądarki oznacza, że atakujący może potrzebować wielu podatności, aby przekroczyć granice ochronne. Klasyfikacja jako wysokiej wagi wskazuje problem wymagający rozwiązania; nie dowodzi, że kompletny atak został już zbudowany.

Te zgłoszone szczegóły tworzą bardziej użyteczne studium przypadku niż sama liczba odkryć. Pokazują opiekuna projektu omawiającego to, co dzieje się między automatycznym wykryciem a wydaniem. Ujawniają również wiedzę instytucjonalną, przez którą musi przejść wynik modelu, zanim użytkownicy otrzymają poprawkę.

Wniosek analityczny jest taki, że możliwości modelu i możliwości organizacyjne wzajemnie się wzmacniają. System, który znajduje rzeczywisty problem, zapewnia ograniczoną ochronę, jeśli nikt nie potrafi go odtworzyć ani ocenić. Dojrzały proces reagowania zyskuje więcej dzięki dowodom przedstawionym w formie użytecznej dla jego inżynierów.

Ta zależność komplikuje również porównania zakupowe. Model oceniany w starannie przygotowanym środowisku projektu korzysta z narzędzi do budowania, infrastruktury testowej oraz opiekunów rozumiejących kod. Klient nie może zakładać równoważnych wyników po skierowaniu tego samego modelu na nieznaną aplikację.

Rozważmy hipotetyczne zgłoszenie dotyczące szeroko wykorzystywanej biblioteki. Początkowe dowody mogą potwierdzać awarię w środowisku testowym. Opiekunowie nadal musieliby zrozumieć przyczynę, ustalić wersje objęte problemem i określić, czy proponowana poprawka rozwiązuje jego źródło.

Test regresyjny, czyli test zabezpieczający przed ponownym wprowadzeniem znanego defektu, pomógłby utrwalić poprawkę. Komunikacja dotycząca wydania musiałaby precyzyjnie opisywać dotknięte zachowanie. Użytkownicy zależni od tej biblioteki potrzebowaliby następnie ścieżki aktualizacji pasującej do produktów, które ją zawierają.

Ten hipotetyczny przykład wyjaśnia przepływ pracy, a nie stwierdza wystąpienia dodatkowego rzeczywistego incydentu. Pokazuje, dlaczego to samo ustalenie może generować pracę dla badaczy, opiekunów bibliotek, dostawców produktów i operatorów przedsiębiorstw. Każdy uczestnik kontroluje inną część drogi do ochrony.

Istnieje tu możliwość pozytywnego cyklu. Lepsze dowody mogą skrócić czas poświęcany na interpretację zgłoszeń, pozostawiając więcej uwagi na faktyczne poprawki. Zweryfikowane poprawki i użyteczne testy mogą z kolei ulepszyć środowisko dostępne dla kolejnej zautomatyzowanej analizy. To, czy ten cykl się urzeczywistni, zależy od wdrożenia i zmierzonych wyników.

Możliwy jest też scenariusz odwrotny. Źle przygotowane ustalenia mogą pochłaniać uwagę potrzebną do rozwiązania bardziej istotnych zgłoszeń. Istotne rozróżnienie nie sprowadza się po prostu do badań prowadzonych przez ludzi lub automatycznie. Chodzi o dowody pomagające opiekunowi podjąć działanie, w przeciwieństwie do wyników przenoszących nierozwiązaną pracę dochodzeniową na odbiorcę.

Etykiety ważności nie mogą rozwiązać luki weryfikacyjnej

Krytyczna etykieta, publiczny identyfikator i zaobserwowane wykorzystanie opisują różne wymiary problemu bezpieczeństwa.

Common Vulnerability Scoring System, czyli CVSS, to system opisu ważności podatności za pomocą zdefiniowanych cech technicznych. Specyfikacja oceny ważności organizacji FIRST umieszcza wyniki krytyczne między 9,0 a 10,0. Sama ta klasyfikacja nie określa, czy atakujący wykorzystują lukę w konkretnej organizacji.

Podobnie CVE, identyfikator Common Vulnerabilities and Exposures, zapewnia publicznie ujawnionej podatności wspólny punkt odniesienia. Nie jest uniwersalną jednostką identycznego zakresu technicznego. Liczba zależy częściowo od sposobu przypisywania i przedstawiania problemów.

Rzetelna ocena pierwotnego odsetka wymaga zatem spójnych zasad w czasie. Licznik i mianownik muszą korzystać ze zgodnych populacji oraz definicji ważności. W przeciwnym razie obliczenie może łączyć nieporównywalne rekordy, sprawiając wrażenie precyzyjnego.

Istnieje również równie istotna kwestia czasu. Jeśli licznik obejmuje rekordy opublikowane niedawno, mierzy aktywność publikacyjną. Nazwanie tego aktywnością odkrywczą wymaga dodatkowych dowodów dotyczących czasu wykrycia podstawowych problemów. Opóźnienia w raportowaniu mogą rozdzielać te zdarzenia.

Analiza Google z 30 września dotycząca ujawniania i wykorzystywania podatności zapewnia szerszy kontekst. Badacze zgłosili 5 045 ujawnień w styczniu 2026 roku i 10 740 w sierpniu. Ostrzegli też, że zasady przypisywania oraz cykle publikacji dostawców komplikują interpretację surowych sum.

Badacze śledzili wykorzystanie osobno i stosowali własne oceny ryzyka zamiast kategorii CVSS. To rozróżnienie metodologiczne ma znaczenie: kategorii ryzyka z ich analizy nie należy po cichu przemianowywać na krytyczny wynik ważności. Podobne brzmienie nie czyni różnych systemów klasyfikacji wymiennymi.

Te ustalenia uzasadniają ostrożność wobec twierdzeń o związku przyczynowym. Wzrost liczby ujawnień może współwystępować z większym wykorzystaniem AI, nie dowodząc, że AI wyjaśnia cały wzrost. Zmiany w zachowaniach raportowych, zasięgu i praktykach publikacyjnych również wymagają analizy.

Zaobserwowane wykorzystanie ma własne ograniczenia. Podatność nieobecna w zbiorze danych monitoringu nie musi być bezpieczna ani nietknięta. Z kolei duża liczba ujawnień nie dowodzi równie dużego wzrostu liczby udanych przejęć. Widoczność i próbkowanie wpływają na to, co badacze mogą zaobserwować.

Najmocniejsze sceptyczne stanowisko uznaje zatem rzeczywisty postęp techniczny, jednocześnie wymagając zdyscyplinowanego pomiaru. Nie wymaga odrzucania każdego raportu firmy. Pyta, czy dowody wspierają konkretny przedstawiany wniosek, zwłaszcza gdy wykracza on na historyczne sumy lub przyszłą roczną produkcję.

W przypadku AI Vulnerability Finding nierozstrzygnięte pytanie nie dotyczy tego, czy zautomatyzowane systemy potrafią identyfikować rzeczywiste luki. Przytoczone relacje projektów już wspierają to węższe twierdzenie. Niepewność dotyczy skali w porównywalnych populacjach, odpowiedzialności za wzrost oraz tempa, w jakim odkrycia stają się trwałą ochroną.

To rozróżnienie powinno kształtować publiczną dyskusję. Traktowanie każdej luki jako natychmiastowej katastrofy może przytłoczyć proces priorytetyzacji. Traktowanie niepewnych statystyk zbiorczych jako powodu do ignorowania udokumentowanych ustaleń tworzy przeciwny błąd. Dowody powinny określać zakres twierdzenia i pilność reakcji.

Obserwuj potwierdzone poprawki, terminy wydań i niezależną replikację

Kolejne użyteczne dowody połączą wyniki wykrywania z zaakceptowanymi ustaleniami, dostarczonymi poprawkami i powtarzalnymi rezultatami.

W ciągu najbliższych kilku miesięcy należy przede wszystkim obserwować pełniejsze raportowanie ze strony Anthropic i organizacji uczestniczących. Użytecznym postępem byłyby zestawione liczby pokazujące, które ustalenia zostały zaakceptowane, poprawione i uwzględnione w obsługiwanych wydaniach. Porównywalne raportowanie ułatwiłoby ocenę istniejących twierdzeń dotyczących wykrywania.

Silniejsza relacja wyjaśniałaby, jak traktowano zduplikowane zgłoszenia i powiązane defekty. Rozdzielałaby oprogramowanie utrzymywane prywatnie od projektów publicznych, w których można przeanalizować dokumentację. Jasno wskazywałaby również okres raportowania, unikając porównań między nakładającymi się lub różnej wielkości przedziałami.

Jeśli te informacje wykażą wzrost liczby odkryć wraz z ukończonymi naprawami, wzmocnią argument za poprawą zdolności obronnych. Jeśli potwierdzone ustalenia będą się kumulować bez odpowiadających im dowodów wydań, wzmocni to obawę, że wykrywanie wyprzedza reagowanie. Samo niepełne raportowanie pozostawi wynik niepewnym.

Po drugie, należy obserwować czas między zaakceptowanymi zgłoszeniami a dostępnymi aktualizacjami. Łatka, czyli zmiana oprogramowania mająca skorygować defekt, jest etapem pośrednim. Obsługiwane wydanie udostępnia tę poprawkę użytkownikom, natomiast wdrożenie określa, czy otrzymują ją środowiska objęte problemem.

Te odstępy mają znaczenie, ponieważ przepustowość może się poprawiać, podczas gdy poszczególne problemy nadal zbyt długo czekają. Zespół może ogółem zamykać więcej zgłoszeń, a jednocześnie utrzymywać rosnącą kolejkę trudnych przypadków. Raportowanie wyłącznie ukończonych poprawek ukryłoby te nierozwiązane sprawy.

Dowody na krótsze, trwałe cykle napraw wzmocniłyby argument, że zautomatyzowane wykrywanie może poprawiać bezpieczeństwo operacyjne. Rosnące kolejki nierozwiązanych spraw lub powtarzające się korekty wcześniejszych poprawek podważyłyby go. Oba wyniki zasługują na uwagę obok nagłówkowych sum odkryć.

Po trzecie, należy obserwować niezależną replikację w projektach o różnych zasobach utrzymaniowych. Wyniki z intensywnie testowanej przeglądarki są pouczające, lecz nie dowodzą równoważnych rezultatów dla każdej aplikacji czy biblioteki. Szersze dowody wymagają udokumentowanych środowisk, zaakceptowanych ustaleń i jasnych relacji dotyczących potrzebnej pracy.

Replikacja byłaby szczególnie użyteczna, gdy opiekunowie publikują własną ocenę zamiast jedynie potwierdzać sumę podaną przez dostawcę. Zgodność co do ważności ustalenia i jego poprawki dostarcza więcej informacji niż demonstracja dająca przekonujący wynik. Niezgodność może ujawnić ograniczenia ukrywane przez statystyki zbiorcze.

Te sygnały oferują sposób oceny postępu bez polegania na prognozie, kto ostatecznie odniesie największe korzyści. Atakujący i obrońcy mogą korzystać z podobnych możliwości, ale ich cele i ograniczenia operacyjne są różne. Wynik zależy od dostępu, wdrożenia oraz szybkości, z jaką zmiany ochronne docierają do systemów objętych problemem.

Pierwotny komentarz oddaje zaskoczenie wokół AI Vulnerability Finding, lecz zaskoczenie jest punktem wyjścia do weryfikacji. Poproś o zbiór danych stojący za tym odsetkiem. Zapytaj, jakie zasady oceny ważności obowiązują i czy daty opisują odkrycie czy publikację. Następnie śledź ustalenia przez potwierdzenie, poprawkę i wydanie. Jeśli oceniasz narzędzia bezpieczeństwa, żądaj dowodów, które Twój zespół może odtworzyć, oraz wyników uznawanych przez Twoich opiekunów. Jeśli zależysz od dostawców oprogramowania, pytaj, jak komunikują wersje objęte problemem i ukończone poprawki. Przeczytaj podstawowe relacje projektów, zanim powtórzysz roczne prognozy. Użyteczne pytanie jest konkretne: gdy wykrywanie przyspiesza, czy organizacje odpowiedzialne za Twoje oprogramowanie potrafią przekształcić te dowody w ochronę?