Skrzynka security@ w projekcie Go puchnie dziś od raportów, które wyglądają jak prawdziwe odkrycia, ale czytane do końca okazują się dłuższą konwersacją z modelem językowym. Filippo Valsorda, niedawno szef bezpieczeństwa Go w Google, dziś maintainer ekosystemu w organizacji Geomys, opublikował w ubiegłym tygodniu tekst kończący trzydziestoletnią umowę między światem open source a badaczami bezpieczeństwa. Stara reguła była prosta. Reporter dostarczał maintainerowi rzadką wiedzę o luce, dostawał w zamian czas na embargo, atrybucję i wpis do CVE. Tymczasem dziś modele językowe znajdują podatności prawie tak dobrze jak ludzcy badacze, a odpalić je może każdy z darmowym kontem. W rezultacie wąskim gardłem nie jest już szukanie, lecz triage, czyli ocena, co naprawdę jest luką. Ta zmiana wywraca rytuał, w którym branża żyła od lat dziewięćdziesiątych.
Skrzynka security@ przestała być miejscem rzadkim
Trzeba na chwilę cofnąć się do czasów, w których raport luki naprawdę był wydarzeniem. W tamtej erze maintainer otwierał maila od badacza i wiedział, że ma w ręku coś trudno powtarzalnego. Z reguły osoba po drugiej stronie spędziła miesiące na inżynierii wstecznej albo fuzzingu, dlatego honorowanie embargo, koordynacja patcha i dyskretna atrybucja były zwyczajną wymianą wartości. Cały etos branży zbudował się natomiast wokół jednego założenia. Wiedza o luce jest aktywem, którego nie ma się ot tak. To dlatego programy bug bounty Mozilli czy polityka odpowiedzialnego ujawnienia w Google Project Zero opierały się na zaufaniu maintainera do reportera.
Tymczasem rok 2026 wprowadza zupełnie inny rachunek. Junior z dostępem do Claude’a, Gemini albo darmowego ChatGPT potrafi wkleić plik źródłowy biblioteki, kazać modelowi “znajdź problemy bezpieczeństwa” i po krótkiej chwili otrzymać obszerny raport. Jakość jest jak zwykle dwojaka. Z jednej strony bowiem obok kilku akapitów trafnej analizy stoją w raporcie wymyślone klasy CVE-2026-X, nieistniejące funkcje pomocnicze i “udowodnienia” oparte na halucynowanym kodzie. W efekcie filtrowanie tego strumienia zajmuje człowiekowi tyle samo czasu, ile zajęłaby wcześniej rozmowa z jednym poważnym reporterem.
Trzy mechanizmy, które LLM-y wyłączyły z gry
Argument Valsordy nie jest tylko narzekaniem na jakość. Opisuje on natomiast trzy mechaniczne zmiany, dzięki którym stary model przestał się domykać ekonomicznie. Każdą z nich widać dziś na skrzynce niejednego maintainera open source.
Insight przestał być rzadki
Pierwsza i najpoważniejsza zmiana dotyczy samej wartości znalezienia luki. Dopóki znalezienie wymagało rzadkiej wiedzy, raport miał sens jako forma daru. Dziś natomiast modele językowe znajdują podatności na poziomie zbliżonym do średniego, a niekiedy lepszego, zewnętrznego badacza. Co więcej, robią to równolegle dla każdej osoby, która zapyta. Maintainer dostaje więc szum o niemal identycznej jakości jak ten, który mógłby wygenerować sobie sam, zwyczajnie odpalając model w swoim CI. W rezultacie wartość zewnętrznego reportera spada do bardzo wąskiego rdzenia, czyli osób, które robią coś, czego model jeszcze nie potrafi.
Triage to nowe wąskie gardło
Druga zmiana dotyczy ekonomii czasu. Kiedy wiedza była rzadka, koszt znalezienia luki znacznie przewyższał koszt jej weryfikacji. Dziś natomiast zachodzi sytuacja odwrotna. Wyprodukowanie raportu kosztuje grosze, a weryfikacja każdego z nich nadal wymaga doświadczonego człowieka z wiedzą o kodzie. W rezultacie wąskim gardłem nie jest szukanie, lecz triage. To z kolei oznacza, że programy bug bounty, które wynagradzały samo zgłoszenie, zaczynają wynagradzać niewłaściwą rzecz. Premiują bowiem wolumen, podczas gdy realnie potrzebne jest filtrowanie.
Embargo nie chroni przed kimś, kto ma własny model
Trzecia zmiana podważa najbardziej święty rytuał branży. Embargo i skoordynowane ujawnienie (po angielsku coordinated disclosure) działały, dopóki atakujący musiał poczekać, aż badacz coś znajdzie i opublikuje. Tymczasem dziś atakujący ma w laptopie tego samego asystenta, którego ma obrońca. W efekcie może odpalić model na tym samym kodzie i znaleźć tę samą lukę bez czekania na publikację. Konsekwencja jest niewygodna, ale logiczna. Triage, szybkie łatanie i profilaktyka mają dziś większą wagę niż kontrola czasu publikacji. Z tego powodu Valsorda pisze wprost, że pracą jest dziś triage, szybkie usuwanie i jak zawsze prewencja.
Curl, Geomys i PyPI mówią to samo różnymi słowami
Sygnałów spod tej samej diagnozy słychać dziś z kilku stron jednocześnie. Daniel Stenberg, twórca biblioteki curl używanej praktycznie w każdym poważnym produkcie sieciowym, ogłosił w połowie czerwca, że projekt nie będzie przyjmował raportów podatności przez cały lipiec. Argument był nudnie prozaiczny. Zespół przestał nadążać z triage’em, a jakość raportów spadła do poziomu, w którym sortowanie tego co wartościowe od tego co wymyślone stało się pochłaniającym sercem zadaniem, jakiego nie sposób zaplanować na zwykłą zmianę.
W ekosystemie Pythona podobny problem opisuje William Woodruff, inżynier bezpieczeństwa pracujący nad pakietami PyPI. Mówi wprost, że tygodniowo musi przejść przez dobrze ponad tuzin raportów, w których zarówno techniczna treść, jak i szacowany wpływ są niejasne. To jest natomiast objętość, która zabija dłuższe inicjatywy zespołu. Każda godzina spędzona na rozplątywaniu raportu o niczym to godzina, w której nikt nie pracuje nad podstawowym bezpieczeństwem ekosystemu.
Geomys, organizacja Valsordy obsługująca utrzymanie wybranych pakietów Go w modelu komercyjnym, mierzy się z tym samym, tylko od bardziej rentownej strony. Klienci płacą za szybsze patche, a skuteczność tej obietnicy mierzy się dziś tym, ile czasu maintainer spędza na walce z zalewem szumu. Pisaliśmy w analogicznym tonie o programie Patch the Planet od OpenAI, w którym GPT-5.5-Cyber łata otwarte biblioteki zanim luki zostaną opublikowane. To dwie strony tego samego problemu. Z jednej strony atakujący przyspiesza. Z drugiej, obrona zaczyna przesuwać model finansowania z nagrody za zgłoszenie na nagrodę za szybkie usunięcie.
Polskie projekty open source są w tej samej pętli, tylko mniejszej
Diagnoza dotyczy także polskiego ekosystemu, nawet jeśli z pozoru mowa wyłącznie o gigantach typu curl i Go. Mniejsze projekty open source publikowane przez polskie zespoły działają w dokładnie tej samej dynamice. Skala raportów jest mniejsza, ale strumień zgłoszeń generowanych przez modele rośnie w identycznym tempie. Polskie firmy znacznie rzadziej mają natomiast osobny pełnoetatowy zespół triage’u. Z tego powodu rolę tę dorzuca się najczęściej komuś z zespołu platformy albo SRE jako zadanie poboczne.
W projektach klienckich, w których pracują zespoły software house’ów, ten sam mechanizm pojawia się w trochę innym kostiumie. Programy bug bounty uruchamiane przez polskie banki i sklepy internetowe coraz częściej raportują wewnętrznie, że rośnie wolumen zgłoszeń, w których trzeba długo szukać tej części, która faktycznie prowadzi do naprawy. To samo opisuje komunikat Five Eyes z 22 czerwca, który ujmuje ofensywne AI w cyber w skali miesięcy, nie lat. Innymi słowy, tempo, w którym pojawiają się nowe wektory ataków, jednocześnie podkręca presję na obrońców i na maintainerów, do których trafia szum z tego samego procesu.
Co praktycznie zmienia się w bug bounty i w pracy CISO
Dla osób prowadzących programy bug bounty wnioski układają się w kilka konkretnych decyzji. Najpierw należy odsiać zgłoszenia, które są ewidentnym efektem konwersacji z modelem, jeszcze przed wpięciem ich w pełny proces triage. Można w tym celu wprowadzić obowiązek dostarczenia konkretnego repro w środowisku publicznym albo wymóg podpisania commita testowego. Następnie warto przeprojektować nagrody. Premiowanie samego zgłoszenia traci sens, kiedy generuje je model. Sensowniej rośnie tu rola płatności za pełne łańcuchy ataku, replikowalność i impakt.
Dla CISO w firmach komercyjnych wniosek brzmi inaczej. Trzeba zaakceptować, że atakujący ma dziś dostęp do tego samego asystenta co obrońca. Z tego powodu skraca się okno między wprowadzeniem luki a jej eksploatacją. Praktyka, która kiedyś nazywała się “czas do patcha”, staje się natomiast głównym wskaźnikiem dojrzałości bezpieczeństwa zespołu. To wyjaśnia, dlaczego część dużych firm porzuca dziś kwartalny cykl wdrażania poprawek na rzecz znacznie krótszych iteracji. Pisaliśmy o tym przy analizie czerwcowego Patch Tuesday Microsoftu z rekordową liczbą luk i zero-dayami i przy ostatnich wpadkach w ekosystemie wtyczek developerskich, gdzie złośliwe rozszerzenia JetBrains kradły klucze API.
Dla badaczy zaczyna się natomiast inna rzeczywistość. Sama zdolność do zlecenia modelowi audytu kodu przestaje być wartością. Tym, co odróżnia raport wartościowy od szumu, są praca z repro, łańcuchy eskalacji, znajomość konkretnego frameworka i cierpliwość, by sprawdzić każdą halucynację modelu, zanim wyśle się ją na maila. Programy, które wynagradzają tę dyscyplinę, będą dalej działały. Te, które płacą za sam wolumen, są na ścieżce, którą maintainer curl już dziś wybrał – z wyłączeniem kanału na czas porządkowania kolejki.
Pierwsza Misja AI · Kodożercy
AI zmienia rynek pracy. Zacznij rozumieć o co chodzi.
Kurs Pierwsza Misja AI to najkrótszy kurs po którym naprawdę rozumiesz AI – i możesz to pokazać certyfikatem. Sci-fi fabuła i gamifikacja sprawiają że nie nudzisz się ani minuty.
Dołącz do kursantów →
Podsumowanie
Diagnoza Valsordy jest twarda, ale jednocześnie wyzwalająca. Stare rytuały odpowiedzialnego ujawnienia luk powstały w czasach, gdy wiedza o podatności była aktywem kosztującym miesiące pracy. Dziś ten sam aktyw da się wyprodukować w piętnaście minut, więc model gospodarczy, który go premiował, przestaje grać. Polskie zespoły bezpieczeństwa nie muszą natychmiast zamykać swoich programów bug bounty, ale powinny zacząć inaczej liczyć wartość, jaką dostają w zamian za wypłacaną nagrodę. Maintainerzy open source z kolei dostają teraz prawo, by powiedzieć głośno to, co od miesięcy chodziło im po głowie. Raporty wygenerowane przez model nie są darem, są pracą, za którą ktoś musi zapłacić, zanim jeszcze wyląduje w skrzynce maintainera.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
