AI generuje fałszywe podatności w oprogramowaniu

Świat oprogramowania opiera się na zaufaniu do wspólnej bazy znanych błędów. Ktoś właśnie zaczął ją zaśmiecać fikcyjnymi wpisami, które nie mają nic wspólnego z rzeczywistością. Firma JFrog, specjalizująca się w bezpieczeństwie, odkryła sześć rzekomych krytycznych podatności w SQLite, które okazały się czystą fikcją. Raporty przypisywały im poważne błędy pamięci z ocenami sięgającymi 9.8 w skali CVSS, ale funkcje, na które wskazywały, w ogóle nie istniały w cytowanych wersjach. Co więcej, kod dowodowy (proof-of-concept) działał bez żadnych problemów.

To nie pojedynczy przypadek. Jedno nowe konto na GitHubie opublikowało w ciągu kilku dni 55 raportów o podatnościach. JFrog przeanalizował je i uznał, że 54 z nich to całkowite zmyślenia. Jedyny prawdziwy błąd był opakowany w fałszywe metadane. Pozostałe wpisy wymyślały dziury w SQLite, bibliotece graficznej libraw oraz dekoderze audio Arduino. Red Hat początkowo nadał jednemu z wpisów dotyczących SQLite idealną ocenę 10.0, by później obniżyć ją do 7.6. Sama firma SQLite dodała funkcję, którą rzekomo zaatakowano, dopiero w 2025 roku – rok po wersji, w której błąd miał występować.

Jak fikcja trafiła do oficjalnych rejestrów

Te fałszywe zgłoszenia nie pozostały tylko na GitHubie. Trafiły do National Vulnerability Database (NVD), czyli rządowej bazy USA prowadzonej przez NIST. Tam oznaczono je jako krytyczne, a zespół CISA wzbogacił je o dodatkowe informacje. Gdy podatność znajdzie się w takiej bazie, skanery i zespoły bezpieczeństwa na całym świecie traktują ją jak realne zagrożenie. System działa na zaufaniu – każdy może przesłać zgłoszenie CVE przez publiczny formularz MITRE, a organizacje przypisujące identyfikatory w dużej mierze polegają na słowach zgłaszającego.

Jak zauważył Alan Coopersmith, inżynier z Oracle, CNA (CVE Numbering Authority) często nie ma możliwości samodzielnej weryfikacji raportu. Kiedyś ostatnią linią obrony był NIST, którego eksperci ręcznie sprawdzali każde zgłoszenie. Niestety, lawina wpisów zmusiła ich do wstrzymania szczegółowej analizy już na początku 2024 roku. Zaległości sięgnęły ponad 27 tysięcy nieprzetworzonych raportów pod koniec 2025 roku. Federalny audytor stwierdził, że agencja marnowała pieniądze, nie będąc w stanie uporać się z backlogiem. W efekcie żaden etap tego procesu nie wymaga dziś od nikogo odtworzenia błędu.

Maszyny oszukują maszyny

Największe zagrożenie kryje się jednak w tym, co czyta te wpisy dalej. Zespoły bezpieczeństwa coraz częściej kierują agentami AI do analizy kodu w poszukiwaniu zgłoszonych podatności. Gdy taki agent dostanie zmyślony wpis CVE, może zacząć szukać funkcji, której nikt nigdy nie napisał. Następnie zmieni działający kod, próbując załatać problem, który nie istnieje. W tym obiegu człowieka prawie nie ma – jedno AI tworzy wiarygodny raport, słabo obsadzony proces przepuszcza go dalej, a kolejne AI próbuje go naprawić.

Afek Berger z JFrog zwraca uwagę na fundamentalną asymetrię. Wygenerowanie przekonującej podróbki kosztuje dziś niemal nic. Weryfikacja natomiast kosztuje dokładnie tyle, ile zawsze: przeczytanie źródła, zbudowanie wersji, uruchomienie dowodu. Nawet dobrze wyposażone zespoły obronne nie są w stanie ręcznie sprawdzić każdego raportu. CISA i NIST mają zbyt duże zaległości, by pomóc. System honorowy nie był przygotowany na maszyny, które potrafią kłamać na skalę przemysłową.

Co to oznacza dla bezpieczeństwa oprogramowania

Problem z AI-slopem w bazach podatności to nie tylko kwestia wiarygodności danych. To realne zagrożenie dla integralności procesów bezpieczeństwa. Gdy narzędzia oparte na AI mają łatć luki, które nie istnieją, marnują zasoby i wprowadzają chaos w kodzie. Zamiast poprawiać bezpieczeństwo, mogą je pogarszać, wprowadzając nowe, rzeczywiste błędy.

Jednocześnie fałszywe wpisy rozpraszają uwagę. Zespoły bezpieczeństwa, które muszą priorytetyzować swoje działania, mogą skupić się na fikcyjnych zagrożeniach, tracąc z oczu te prawdziwe. To szczególnie niebezpieczne w sytuacji, gdy liczba zgłoszeń rośnie szybciej niż możliwości ich weryfikacji.

Jak chronić się przed dezinformacją w CVE

Dla zespołów bezpieczeństwa kluczowe staje się wypracowanie własnych mechanizmów weryfikacji. Zamiast ślepo ufać wpisom w NVD, warto:

  • Sprawdzać, czy wskazana funkcja faktycznie istnieje w cytowanej wersji oprogramowania
  • Uruchamiać proof-of-concept w izolowanym środowisku przed podjęciem jakichkolwiek działań
  • Korzystać z narzędzi do wykrywania treści generowanych przez AI w raportach
  • Weryfikować historię kont zgłaszających podatności – nagłe pojawienie się wielu raportów z jednego źródła powinno wzbudzić czujność

Producenci oprogramowania powinni z kolei rozważyć szybsze reagowanie na zgłoszenia dotyczące ich produktów. W przypadku SQLite, szybka odpowiedź producenta mogła zapobiec nadaniu fikcyjnej podatności oceny 10.0 przez Red Hata.

W dłuższej perspektywie konieczna jest zmiana procesu akceptacji zgłoszeń. Wymóg dostarczenia działającego dowodu przed nadaniem identyfikatora CVE mógłby znacząco ograniczyć liczbę fałszywych wpisów. Póki co jednak system oparty na zaufaniu pozostaje podatny na nadużycia, a narzędzia AI tylko pogłębiają ten problem.

Środowisko bezpieczeństwa stoi przed nowym wyzwaniem. Musi nauczyć się odróżniać prawdziwe zagrożenia od AI-slopu, zanim systemy oparte na zaufaniu całkowicie stracą wiarygodność. To wyścig z czasem, w którym stawką jest zaufanie do całego ekosystemu oprogramowania.

Źródło

Może Cię zainteresować