Żeby uporać się z triażem zgłoszeń bug bounty generowanych przez AI, uruchom pięć dźwigni w tej kolejności: (1) filtrowanie wstępne wspierane przez AI, które automatycznie oznacza zmyślone funkcje i brak proof-of-concept, zanim zgłoszenie trafi do człowieka, (2) rate limiting na wejściu, żeby jeden podmiot nie zalał kolejki, (3) ocenę reputacji, która karze potwierdzone śmieci, (4) monitorowanie SLA, które chroni cenny czas recenzentów, oraz (5) nagrody płacone za realny wpływ, a nie za liczbę zgłoszeń. Programy, które padły w 2026 roku, nie miały problemu ze śmieciami. Miały problem z triażem.

Jeśli prowadzisz skrzynkę `security.txt`, program ujawniania podatności (VDP) albo bug bounty, już to czujesz. Liczba zgłoszeń rośnie, a odsetek tych prawdziwych leci na łeb na szyję. Każde zgłoszenie „wiarygodne, lecz fałszywe" wciąż kosztuje doświadczonego inżyniera od 30 minut do trzech godzin, żeby go obalić. To klasyczny problem działania pod obciążeniem: nie chodzi o to, „czy mieć VDP" (powinieneś mieć, a [jak go uruchomić, opisaliśmy osobno](/blog/how-to-set-up-vulnerability-disclosure-program)), tylko o to, że „kolejka tonie — jak utrzymać ją przy życiu, nie wypalając recenzentów i nie tracąc prawdziwych badaczy?"

## Ofiary roku 2026: curl, HackerOne i Nextcloud

W pierwszej połowie 2026 roku trzy z najbardziej wiarygodnych nazwisk w świecie ujawniania podatności na oczach wszystkich ugięły się pod szumem generowanym przez AI. To nie są jakieś niszowe programy. To wzorcowe przykłady tego, jak robić disclosure dobrze — i wszystkie uderzyły w tę samą ścianę: koszt wyprodukowania fałszywego zgłoszenia spadł niemal do zera, podczas gdy koszt jego obalenia pozostał ludzki i wysoki.

### Dlaczego curl wyciągnął wtyczkę

curl zamknął swój program bug bounty na HackerOne z dniem **31 stycznia 2026 roku**. Jego twórca, Daniel Stenberg, dokumentował ten upadek od miesięcy. We wpisie z lipca 2025 roku „Death by a thousand slops" donosił, że **około 20% wszystkich zgłoszeń z 2025 roku to były śmieci AI**, a **tylko jakieś 5% zgłoszeń z 2025 roku okazało się prawdziwymi podatnościami** — to gwałtowny spadek względem poprzednich lat (źródło: [daniel.haxx.se](https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/)).

Z perspektywy ludzkiej ekonomia była brutalna. Każde zgłoszenie angażowało **trzech do czterech z siedmioosobowego zespołu bezpieczeństwa** na **od 30 minut do mniej więcej trzech godzin** pracy weryfikacyjnej — niemal w całości w ramach wolontariatu. Początek 2026 roku podjął decyzję za niego: w **pierwszych 21 dniach 2026 roku curl dostał około 20 zgłoszeń i potwierdził zero podatności**, w tym **siedem zgłoszeń na HackerOne w jednym oknie 16 godzin** (źródło: [daniel.haxx.se](https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/); [BleepingComputer](https://www.bleepingcomputer.com/news/security/curl-ending-bug-bounty-program-after-flood-of-ai-slop-reports/)).

Od 1 lutego 2026 roku curl kieruje zgłoszenia do prywatnego zgłaszania na GitHubie oraz na `security@curl.se` — bez żadnej nagrody pieniężnej, wprost, jak ujął to Stenberg, po to, żeby „odebrać ludziom motywację do wysyłania bzdur". Przez cały czas działania program wypłacił nagrody za **87 potwierdzonych podatności i ponad 100 000 dolarów od 2019 roku**. Bounty działało przez lata. To śmieci AI je dobiły.

### Skok HackerOne o 76% i zamrożenie Internet Bug Bounty

HackerOne wykonał dwa odrębne ruchy. Po pierwsze, jego **Internet Bug Bounty (IBB)** — wspólny fundusz finansujący kluczowe zależności open source — **wstrzymał przyjmowanie nowych zgłoszeń pod koniec marca 2026 roku**, powołując się na rozjechanie się tempa odkrywania bugów wspomaganego przez AI z ludzką zdolnością ich łatania (źródło: [Privacy Guides](https://www.privacyguides.org/news/2026/04/17/hackerone-pauses-internet-bug-bounty/); [InfoWorld](https://www.infoworld.com/article/4154210/internet-bug-bounty-program-hits-pause-on-payouts.html)).

Po drugie, w kwietniu 2026 roku, równolegle z uruchomieniem płatnej usługi walidacji, HackerOne ujawnił sztandarową statystykę makro: **liczba zgłoszeń podatności wzrosła o 76% rok do roku, bijąc rekord w marcu 2026 roku**, podczas gdy **około 25% zgłoszeń potwierdzono jako możliwe do wykorzystania** — wskaźnik, który utrzymał się mniej więcej na stałym poziomie (źródło: [komunikat prasowy HackerOne](https://www.hackerone.com/press-release/hackerone-introduces-h1-validation-help-enterprises-manage-surge-ai-discovered)). Przeczytaj to uważnie: bezwzględna liczba realnych bugów wciąż rośnie, ale rośnie też szum wokół nich — i szum rośnie szybciej. Do maja 2026 roku IBB **ostro przyciął kwoty nagród na wszystkich poziomach ważności** (źródło: [The Register](https://www.theregister.com/security/2026/05/21/hackerone-takes-an-axe-to-its-bug-bounty-rewards/5244458)).

### To problem całego ekosystemu

Łatwo byłoby spisać curl na straty jako niedofinansowany projekt open source, a HackerOne potraktować jako bóle wzrostu jednej platformy. Tyle że ten wzorzec jest znacznie szerszy.

| Program | Co się stało | Kiedy |
|---|---|---|
| **Nextcloud** | Zakończył wypłaty, powołując się na „masowy wzrost liczby zgłoszeń niskiej jakości"; przyjmowanie zgłoszeń zostawił otwarte, dopóki nie „wymyśli, jak je sensownie filtrować" | kwiecień 2026 |
| **Google** | Przestał przyjmować część zgłoszeń generowanych przez AI | marzec 2026 |
| **Cosmos Labs (krypto)** | Współ-CEO zgłosił **skok o 900% rok do roku** — 20 do 50 zgłoszeń dziennie | 2026 |
| **Bugcrowd** | Liczba zgłoszeń **więcej niż poczwórniła się w ciągu trzech tygodni** — głównie fałszywe alarmy lub niskiej jakości znaleziska AI | marzec 2026 |
| **Jądro Linuksa** | Linus Torvalds nazwał listę bezpieczeństwa „niemal całkowicie niemożliwą do ogarnięcia" pod naporem zduplikowanych zgłoszeń tworzonych z pomocą AI | 2026 |

Źródła: [heise](https://www.heise.de/en/news/Due-to-AI-Bug-bounty-programs-without-rewards-now-also-at-Nextcloud-11271443.html); [Computing.co.uk](https://www.computing.co.uk/news/2026/security/bug-bounty-platforms-battle-ai-slop); [Cointelegraph via TradingView](https://www.tradingview.com/news/cointelegraph:f6afb56fe094b:0-ai-drives-surge-in-bug-bounty-reports-but-slop-is-rising-too/).

Najbardziej wymowne jest zdanie Nextcloud. Oni nie zamknęli wejścia. Zostawili kanał otwarty i przestali płacić, *dopóki nie nauczą się filtrować jak należy*. Ta luka — „chcemy tych zgłoszeń, ale nie stać nas na ich triaż" — to dokładnie problem, o którym jest ten artykuł.

## Dlaczego śmieci AI rozbijają ekonomię bug bounty

Bug bounty to mechanizm kosztownego sygnału. Pierwotne założenie: człowiek włożył realny wysiłek w znalezienie buga, więc wyprodukował konkretne, odtwarzalne zgłoszenie — i jego triaż jest wart czasu recenzenta. Cały model opiera się na tym, że wysiłek włożony w zgłoszenie jest na tyle kosztowny, by odsiewać szum u samego źródła.

AI obala to założenie. Sprawia, że wyprodukowanie wiarygodnie wyglądającego zgłoszenia jest niemal darmowe, podczas gdy koszt jego obalenia uparcie pozostaje ludzki. Wygenerowane zgłoszenie potrafi przytoczyć prawdziwie wyglądający CVE, opisać prawdziwie wyglądającą funkcję i przedstawić pewne siebie kroki odtworzenia — a wszystko to halucynacja. Recenzent i tak musi otworzyć kod, prześledzić zarzut i udowodnić negatyw. Udowodnienie, że bug jest prawdziwy, idzie szybko. Udowodnienie, że przekonujący fałszywiec *nie* jest prawdziwy, idzie wolno.

I robi się jeszcze gorzej. AI ma tendencję do wyrzucania wielu wariantów tego *samego* problemu — ten sam wzorzec cross-site scriptingu z dwudziestoma różnymi payloadami — i zgłaszania każdego jako osobnego znaleziska. Liczba zgłoszeń puchnie, a bezpieczeństwo ani drgnie. Wąskim gardłem staje się w całości walidacja — czyli ten jeden element procesu, którego domyślnie nie da się tanio zautomatyzować (źródło: [Pen Test Partners](https://www.pentestpartners.com/security-blog/ai-noise-and-the-effect-its-having-on-vulnerability-disclosure-programs/)).

Dla zachowania proporcji warto pamiętać: VDP i bounty historycznie miały **60 do 80% nietrafionych zgłoszeń jeszcze przed erą AI** (źródło: [Yogosha](https://yogosha.com/blog/ai-and-vulnerability-triage-lessons-learned-from-our-automated-assistance-poc/)). Podatek od triażu istniał zawsze. AI nie wymyśliło tego problemu. Usunęło tylko naturalny rate limit, który trzymał go w ryzach.

## Procedura triażu: pięć dźwigni, które utrzymują VDP przy życiu

Tego nie naprawisz jednym narzędziem. Naprawisz to, odwracając ekonomię — podnosząc koszt wysyłania śmieci i obniżając koszt ich filtrowania. Oto pięć dźwigni, w kolejności od najsilniejszej.

1. **Filtrowanie wstępne wspierane przez AI na wejściu.** Automatycznie klasyfikuj oczywiste śmieci (zmyślone funkcje, sfabrykowane CVE, brak proof-of-concept, szablonowy język), zanim człowiek straci na nie godzinę.
2. **Rate limiting i kontrola spamu.** Throttling z przesuwnym oknem, żeby jeden podmiot nie zalał kolejki w 16-godzinnym zrywie.
3. **Ocena reputacji, która karze śmieci.** Spraw, by potwierdzone śmieci kosztowały zgłaszającego — recydywiści sami się wykruszą.
4. **Monitorowanie SLA, które chroni czas recenzentów.** Potwierdzaj i zamykaj zgłoszenia z zegarkiem w ręku, żeby prawdziwi badacze nie szli z frustracji do mediów.
5. **Nagrody za wpływ, nie za ilość.** Płać według poziomu ważności, ustaw znaleziska informacyjne na zero i wymagaj konsolidacji, żeby tysiąc identycznych znalezisk płaciło raz.

### 1. Filtrowanie wstępne wspierane przez AI na wejściu

Pojedynczy ruch o największej dźwigni to przestać wpuszczać surowe zgłoszenia najpierw do człowieka. Wstępne prześwietlenie przez LLM potrafi wyłapać znaki rozpoznawcze, które dzieli niemal każde zgłoszenie-śmieć: odwołania do funkcji albo elementów kodu, które nie istnieją; CVE cytowane jako nowe, choć mają już kilka lat albo są zmyślone; ogólnikowe formułki o remediacji; oraz brak jakiegokolwiek konkretnego, uruchamialnego proof-of-concept.

Kluczowa decyzja projektowa jest taka, że to ma być *wsparcie*, a nie automatyczne odrzucanie. Pierwszy przebieg ma rekomendować, nie decydować: wysoka pewność „przepuść", „do przejrzenia" albo „oznacz". Człowiek wciąż rozstrzyga wszystko, co graniczne. Nie budujesz robota-bramkarza. Budujesz Tiarę Przydziału, która kieruje oczywiste śmieci z dala od uwagi twoich najlepszych inżynierów.

### 2. Rate limiting i kontrola spamu

curl dostał siedem zgłoszeń w 16 godzin. Żaden ludzki zespół nie ogarnie tego triażem w czasie rzeczywistym. Prosty throttling z przesuwnym oknem — powiedzmy, pięć zgłoszeń na podmiot na pięć minut, a potem tymczasowa blokada — neutralizuje wzorzec zalewu zrywem, nie dotykając przy tym legalnych badaczy, którzy niemal nigdy nie zgłaszają jeden po drugim w błyskawicznym tempie. To najtańsza dźwignia do wdrożenia i jedna z najskuteczniejszych przeciw konkretnemu kształtowi ataku z 2026 roku.

### 3. Ocena reputacji, która karze śmieci

Systemy karmy to w świecie bounty żadna nowość, ale większość z nich nagradza tylko sensowną pracę. Realia 2026 roku wymagają odwrotności: potwierdzone śmieci i odrzucony spam powinny *odejmować* punkty. Kiedy reputacja zgłaszającego leci w dół, możesz bramkować jego przyszłe zgłoszenia albo automatycznie obniżać im priorytet. Chodzi o to, żeby śmieci kosztowały — żeby ludziom grającym na ilość przestało się to opłacać.

### 4. Monitorowanie SLA, które chroni czas recenzentów

Tu jest powiązanie, które ludzie przegapiają: monitorowanie SLA nie polega tylko na byciu responsywnym. Polega na tym, żeby nie stracić dobrych badaczy. Prawdziwi badacze idą do mediów, gdy potwierdzenia się ślimaczą, łatki wychodzą po cichu albo ważność zostaje dyskretnie zaniżona — czyli dokładnie tryb porażki, który opisaliśmy w tekście [gdy badacze idą do mediów](/blog/when-researchers-go-public-botched-disclosure). Pod obciążeniem śmieciami to właśnie czasy potwierdzeń pękają jako pierwsze — i to dokładnie wtedy, gdy najmniej cię stać na zrażenie do siebie prawdziwych zgłaszających, którzy utknęli gdzieś w szumie. Zegar potwierdzeń (np. 72 godziny) plus cele rozwiązania na poziom ważności sprawiają, że ludzie, na których koordynacji najbardziej ci zależy, dalej z tobą współpracują.

<div class="blog-inline-cta">
  <p><strong>Toniesz w skrzynce VDP?</strong> Moduł CSIRT od Kit dostarcza prześwietlanie wstępne przez AI, rate limiting na wejściu, karmę reputacji, zegary SLA i nagrody oparte na wpływie — jako konfigurację, a nie półroczny projekt wdrożeniowy.</p>
  <p><a href="/users/sign_up">Rozpocznij darmowy okres próbny</a></p>
</div>

### 5. Nagrody za wpływ, nie za ilość

Jeśli twoje bounty płaci za każde przyjęte znalezisko niezależnie od poziomu ważności, to płacisz ludziom za samą ilość — a AI z radością dostarczy. Powiąż wypłaty z macierzą ważności, w której znaleziska informacyjne płacą **0 $**, a realne pieniądze dostaje tylko realny wpływ. Połącz to z deduplikacją, żeby tysiąc wariantów jednego buga o wspólnej przyczynie źródłowej zwijało się do jednego zgłoszenia i jednej wypłaty. Po tę dźwignię sięgnął na koniec właśnie curl: odebrał pieniężną motywację do wysyłania bzdur. Nie musisz schodzić aż do zera jak curl, ale musisz przestać nagradzać ilość.

## Nie wylewaj dziecka z kąpielą: dobrzy badacze wspomagani przez AI

Wrogiem jest *niezweryfikowana ilość*, nie AI. To rozróżnienie ma znaczenie, bo leniwa reakcja — „zbanujmy zgłoszenia robione z pomocą AI" — wyrzuciłaby za burtę twoich najlepszych kontrybutorów.

Najjaśniejszy kontrprzykład to Joshua Rogers, którego praca wspomagana przez AI wydobyła w curl około 50 *prawdziwych* bugów — każdy zweryfikowany przez człowieka przed wysłaniem. To samo narzędzie co u handlarzy śmieciami, przeciwny rezultat — bo między modelem a przyciskiem „wyślij" stał kompetentny człowiek. Stenberg mówił wprost, że odpowiedzialne badania wspomagane przez AI są mile widziane; nie do udźwignięcia jest dla niego sikawka niesprawdzonego outputu.

Dlatego zadanie tej procedury jest precyzyjne: filtruj po *dowodach i trafności*, a nie po tym, *czy w grę wchodziło AI*. Zgłoszenie z działającym proof-of-concept i odwołaniem do prawdziwego kodu przechodzi niezależnie od tego, czy szkic napisał człowiek, czy model. Zgłoszenie ze zmyślonymi funkcjami i bez PoC odpada z tego samego powodu, kto by go nie napisał. Prześwietlaj sygnał, nie narzędzie.

## Jak Kit przekłada tę procedurę na działanie

Oto niewygodna prawda dla każdego zespołu, który zechce zbudować to u siebie: pięć dźwigni powyżej to z grubsza pół roku wewnętrznego dłubania w narzędziach. Wertykał `Csirt::` w Kit implementuje je jako konfigurację. Odwzorowanie jest niemal jeden do jednego.

| Dźwignia z procedury | Funkcja CSIRT w Kit | Co robi |
|---|---|---|
| **Triaż wstępny wspierany przez AI** | `Csirt::AiScreening` | Prześwietlenie przez LLM zwraca `pass` / `review` / `flag` według pewności i wykrywa jawne sygnały śmieci: zmyślone funkcje, sfabrykowane CVE, stare CVE podane jako nowe, ogólnikową remediację, brak konkretnego PoC, szablonowy język, mgliste kroki odtworzenia, odwołania do nieistniejącego kodu |
| **Rate limiting / kontrola spamu** | `Csirt::SpamConfig` | Throttling z przesuwnym oknem (domyślnie 5 zgłoszeń na 5 minut, potem tymczasowa blokada) z auto-blokadą przy recydywie |
| **Reputacja, która karze śmieci** | `Csirt::KarmaEvent` | Potwierdzone śmieci AI kosztują zgłaszającego karmę; odrzucenie spamu i „nie dotyczy" też odejmują; trafne rozwiązania i nagrody dodają, z bonusami za poziom ważności |
| **Deduplikacja** | `Csirt::TriageConfig` | Deduplikacja włączona domyślnie, żeby powtórzone warianty jednej przyczyny źródłowej nie zamieniły się w sto zgłoszeń |
| **Monitorowanie SLA** | `Csirt::SlaConfig` | Zegar potwierdzeń (domyślnie 72h) plus cele rozwiązania na poziom ważności |
| **Nagrody oparte na wpływie** | `Csirt::BountyMatrixConfig` | Pasma wypłat warstwowane wg poziomu ważności; znaleziska informacyjne płacą 0 $, w górę aż do krytycznych |
| **Odpowiedzialność pod obciążeniem** | `Csirt::OnCallConfig` | Auto-przydział dyżuru, żeby potwierdzenia nie pękały, gdy kolejka skacze |
| **Mniej szumu spoza zakresu** | `Csirt::ScopeConfig`, `Csirt::SecurityTxtConfig` | Publiczny zakres i polityka ograniczają nietrafione zgłoszenia u źródła |

Jedna precyzyjna uwaga o prześwietlaniu przez AI: to *triaż wspomagający* — rekomendacja plus ocena pewności, a nie automatyczne odrzucenie. Ludzie wciąż rozstrzygają każdy `flag` i każdy `review`. Kit nie twierdzi, że zablokuje wszystkie śmieci. Filtruje pierwszy przebieg i przewartościowuje motywacje, żeby godziny twoich recenzentów szły na prawdziwe bugi — a zgłoszenie w stylu Joshui Rogersa z działającym PoC przemyka bez przeszkód, podczas gdy to z halucynacjami zostaje wyłapane.

## Wnioski: problem ze śmieciami to tak naprawdę problem z triażem

Programy, które padły w 2026 roku, nie zostały pokonane przez AI. Zostały pokonane przez pipeline wejściowy zbudowany pod świat kosztownego sygnału, który już nie istnieje. Śmieci to po prostu ilość. Porażka była strukturalna: brak automatycznego pierwszego przebiegu, brak rate limitu, brak kary reputacyjnej i bounty, które płaciło za ilość.

Każde z tych ograniczeń da się naprawić — i każde z nich jest ustawieniem, a nie projektem badawczym. Jeśli stawiasz program od zera, zacznij od [przewodnika po uruchomieniu VDP](/blog/how-to-set-up-vulnerability-disclosure-program). Jeśli już toniesz, ruch jest jeden: odwrócić ekonomię. Zautomatyzuj pierwszy przebieg, ograniczaj zalewy, spraw, by śmieci coś kosztowały, chroń czas recenzentów za pomocą SLA i płać wyłącznie za realny wpływ. Trzymaj na zewnątrz zgłoszenia, które zabiły curl — i wpuszczaj zgłoszenia w stylu Joshui Rogersa.

Dokładnie do tego został zbudowany moduł CSIRT od Kit. [Rozpocznij darmowy okres próbny](/users/sign_up) i zamień zalaną skrzynkę w przefiltrowaną, ograniczoną rate limitem i zabezpieczoną SLA kolejkę.