Masowa kampania ujawniania podatności to jeden zgłaszający, który naraz wysyła wiele znalezisk do wielu niepowiązanych ze sobą stron. Terminy ustala sam. Publiczny Security Disclosure Ledger firmy Z.ai notuje **2 436 znalezisk w 269 projektach open source**, w tym 107 krytycznych i 990 wysokich, przy średnio **26,6 roku** między wprowadzeniem błędu a jego wykryciem; niezależny audyt pola statusu w tym rejestrze wykazał, że **2 239 znalezisk nadal ma status `discovered`**, a dokładnie jedno `sent to maintainer`. Jedno potwierdzenie, jeden zegar SLA, jedna decyzja o poziomie ważności: przyjmowanie zgłoszeń pojedynczo rozpada się w zderzeniu z takim kształtem.

To trzeci tekst z serii, a całe sedno tkwi w różnicy: te znaleziska są w większości prawdziwe i nikt ich nie zamawiał. [Tekst o śmieciach AI](/blog/ai-slop-flooding-bug-bounty-triage) dotyczył **nieprawidłowych** zgłoszeń napływających masowo. [Tekst o modelu kosztów VDP](/blog/ai-cheap-vulnerability-research-vdp-triage-economics) mówił o tym, że koszt znalezienia prawdziwego błędu spadł z grubsza do ceny obiadu. Tu nie chodzi ani o jedno, ani o drugie.

[Tekst o wielu dostawcach](/blog/coordinated-disclosure-multi-vendor-vulnerabilities) opisywał jeden błąd, który spada na pięciu dostawców; tutaj jeden zgłaszający uderza naraz w 269 projektów. Ten sam problem zarządczy, wywrócony na lewą stronę, tyle że termin trzyma strona, która akurat ma premierę produktu.

## 2 436 znalezisk, 269 projektów i jeden zgłaszający

14 sierpnia 2026 roku Z.ai wypuściło GLM-5.3 i tego samego dnia opublikowało pod adresem `cvd.z.ai` swój Security Disclosure Ledger. Artefaktem wartym lektury jest tu rejestr, nie wynik benchmarku.

| Wskaźnik | Wartość |
|---|---|
| Łączna liczba znalezisk | 2 436 w 269 projektach open source |
| Podział na poziomy ważności | 107 krytycznych, 990 wysokich, 1 286 średnich, 53 niskie |
| Ujawnione publicznie | 53 z identyfikatorami CVE; 2 383 nieujawnione |
| Średni wiek błędu | 26,6 roku od wprowadzenia do wykrycia |
| Najstarszy dotknięty kod | 1981 rok, rozpiętość 45 lat |

Wśród ujawnionych z nazwy znalezisk są: stos 6lowpan w jądrze Linuksa, WebKit, `ptrace` z FreeBSD, GStreamer i Suricata. Z.ai podaje, że GLM-5.3 osiąga **84,5% w CyberGym** wobec 77,2% dla GLM-5.2. Wątek na Hacker News urósł do 1 170 punktów i 584 komentarzy, a najostrzejsza krytyka celowała nie w model, tylko w masowe skanowanie open source bez jakiejkolwiek polityki embarga. Zanim cokolwiek zbudujesz na tych liczbach, dwa zastrzeżenia.

**To nie jest praca jednego modelu.** Z.ai twierdzi, że kampania ruszyła jeszcze w czasach GLM-5.2, prowadziło ją kilka zespołów bezpieczeństwa korzystających z różnych zestawów narzędzi, a biuletyny bezpieczeństwa po stronie projektów wymieniają rozmaite wersje GLM. Pisz „kampania Z.ai”, nigdy „GLM-5.3 znalazł 2 436 błędów”.

**Każda zbiorcza liczba pochodzi z publikacji samego Z.ai.** Nikt spoza firmy nie zweryfikuje 2 383 nieujawnionych wpisów. To nie przytyk pod adresem Z.ai, tylko opis pozycji, w jakiej sam się znajdziesz, kiedy do twojej skrzynki wpadnie partia czterdziestu zgłoszeń: przyjmując zgłoszenie, nie sprawdzisz twierdzeń masowego zgłaszającego, a ja nie sprawdzę tych tutaj.

## Ani historia o śmieciach AI, ani o tanim wykrywaniu błędów

Przy śmieciach AI problemem był stosunek sygnału do szumu, przy ekonomice triażu chodziło o koszt jednostkowy. Tutaj chodzi o **kształt**, a to właśnie kształt rozbija narzędzia. Zwykły program ujawniania podatności (VDP) zakłada relację wiele-do-jednego: wielu niezależnych badaczy, każdy wysyła jedno zgłoszenie i każdy, składając je, godzi się na twoją politykę. Kampania masowa odwraca ten układ. Jeden zgłaszający zwraca się naraz do 269 odbiorców, według harmonogramu, który sam ustala, i publikuje jawny rejestr, zanim większość z nich w ogóle się o czymkolwiek dowie.

Strona odbierająca niczego nie akceptowała, na żaden harmonogram się nie umawiała, a w większości przypadków nikt jej nawet nie powiadomił. To nie jest zgłoszenie do programu bug bounty. Bliżej temu do **masowej kampanii powiadomień o podatnościach**, którą badania nad bezpieczeństwem opisują od dekady i o której wiadomo jedno: odsetek odpowiedzi jest żałośnie niski.

## Wąskim gardłem jest powiadomienie, nie łatanie

Najcenniejsza informacja w rejestrze to nie liczba 2 436, tylko to, gdzie te znaleziska utknęły. Audyt pola statusu, wykonany 14 sierpnia, zanotował: **2 239 `discovered`, 84 `reported`, 53 `revealed`, 29 `acknowledged`, 30 `patched` i 1 `sent to maintainer`**. Blisko **92% znalezisk nadal leży po stronie zgłaszającego.**

Anthropic rozegrał to samo dwa miesiące wcześniej i doczekał się audytu. Analiza rejestru Mythos, którą VulnCheck opublikował 9 czerwca 2026 roku, wykazała **23 019 kandydatów na podatności**, z czego 467 zweryfikowano i zgłoszono, a 1 129 zgłoszono bez weryfikacji. Do opiekunów projektów dotarło więc w 60 dni **1 596 znalezisk, czyli 6,9%**, w tempie, przy którym rozładowanie zaległości zajęłoby według VulnCheck jakieś **2,4 roku**.

Do tego dziesięć znalezisk przekroczyło już 90-dniowy termin wyznaczony przez samo Anthropic i wciąż nie zostało opublikowanych, a kolejnych 168 ma termin w ciągu 30 dni.

Dwóch dostawców, dwa rejestry, jeden strukturalny wniosek: **wykrywanie skaluje się, powiadamianie nie.** Model znajdzie przepełnienie sterty w kodzie z 1994 roku w kilka minut. Odnalezienie opiekuna, napisanie zgłoszenia, na które człowiek umie zareagować, i doprowadzenie sprawy do łatki to wciąż ta sama ludzka robota co zawsze.

Dla strony odbierającej to dobra wiadomość z terminem ważności. Fala jeszcze cię nie zalała, a kiedy nadejdzie, przyjdzie **partią**, bo zgłaszający nie zgłasza pojedynczego błędu, tylko rozładowuje kolejkę.

## Co się psuje, gdy od jednego nadawcy przychodzi 40 zgłoszeń

Trzy awarie czysto mechaniczne, żadna nie wymaga oceny sytuacji. We wszystkich trzech twoja automatyka działa dokładnie tak, jak ją zaprojektowano.

**Lawina potwierdzeń.** Automatyczna odpowiedź na każde zgłoszenie jest poprawna przy jednym i staje się nękaniem przy czterdziestu. Nadawca dostaje czterdzieści maili, których nikt nie chciał, twoja domena wysyła czterdzieści niemal identycznych wiadomości pod jeden adres, a po tym wszystkim nadawca i tak nie wie, kto odpowiada za partię ani kiedy spojrzy na nią człowiek.

**Sumowanie SLA.** Czterdzieści zegarów potwierdzenia rusza równocześnie. Każdy z osobna da się obsłużyć w 72 godziny, razem dają obciążenie triażem, pod które nikt nie układał grafiku dyżurów. W rozbiciu na pojedyncze zgłoszenia kolejka świeci na zielono, jako całość jest beznadziejna. Dokładnie ten tryb awarii opisywał [tekst o wielu dostawcach](/blog/coordinated-disclosure-multi-vendor-vulnerabilities), tylko odwrócony: tam jedna sprawa miała wiele zegarów, tu wiele spraw dzieli jeden pułap mocy przerobowych.

**Poziom ważności przed przyczyną źródłową.** Triaż zgłoszenie po zgłoszeniu pyta najpierw „jak groźne jest to jedno?”. Przy kampanii to pytanie drugie; pierwsze brzmi: czy metoda tego zgłaszającego się broni i czy te znaleziska mają wspólną przyczynę źródłową?

Czterdzieści znalezisk z jednego zestawu narzędzi wycelowanego w jeden parser to bardzo często jedna klasa błędu w czterdziestu miejscach w kodzie. Triażowanie ich osobno kosztuje czterdzieści razy więcej i daje gorszą odpowiedź, bo wzorzec widać wyłącznie w całości.

Wszystkie trzy awarie biorą się z jednej decyzji projektowej: **jednostką pracy jest zgłoszenie.** Przy kampanii już nią nie jest.

## Kampania to nie zgłoszenie: co musi obejmować przyjmowanie zgłoszeń

Lekarstwem jest obiekt partii stojący ponad zgłoszeniem. Pięć pól robi tu większość roboty.

1. **Jedna partia, jedno potwierdzenie.** Jedna odpowiedź, która nazywa partię, podaje liczbę znalezisk i zobowiązuje do daty pierwszej merytorycznej odpowiedzi. Kiedy w zgłoszeniu jest identyfikator partii, wyłącz pojedyncze maile.
2. **Jeden właściciel.** Konkretna osoba odpowiedzialna za partię, a nie czterdzieści przypisań rozdzielanych po kolei między dyżurnych.
3. **Jeden wspólny zegar dla partii**, a pod spodem zegary poszczególnych znalezisk. Potwierdzenie jest zobowiązaniem wobec całej partii, naprawa dotyczy pojedynczego znaleziska.
4. **Ocena metody zapisana raz.** Czy zestaw narzędzi się broni? Czy dołączone PoC dają się uruchomić? Odpowiadasz dla całej partii, dziedziczysz odpowiedź w dół i korygujesz tylko tam, gdzie konkretne znalezisko jej przeczy.
5. **Grupowanie po przyczynie źródłowej przed oceną ważności.** Najpierw klastry, potem punktacja klastrów, a nie pojedynczych wierszy.

Kit jeszcze tego nie ma. Moduł `Csirt::` traktuje `Csirt::Report` jako rekord najwyższego poziomu: żadnego obiektu kampanii, żadnej partii zgłoszeń. Czterdzieści zgłoszeń to czterdzieści wierszy, czterdzieści maili z potwierdzeniem, czterdzieści zegarów SLA i czterdzieści powiadomień na dyżur.

To główna teza tego tekstu i zarazem luka w naszym własnym produkcie, a nie jego funkcja. Pięć pól powyżej to kształt, jaki naszym zdaniem powinien mieć taki obiekt.

## Czyj jest zegar ujawnienia, kiedy zgłasza dostawca modelu?

Niczyj, dopóki go sobie nie zapiszesz.

Żadne prawo nie ustala skoordynowanego ujawnienia na 90 dni. Jest konwencja, choćby 90+30 z Project Zero i 90+14 z ZDI dla współpracujących dostawców, a poza tym liczy się to, kto opublikuje pierwszy. Kiedy zgłaszającym jest dostawca modelu, termin splata się z **marketingiem premiery**, bo rejestr jest w równym stopniu pokazem możliwości, co artefaktem ujawnienia.

Z.ai nie opublikowało przy rejestrze żadnej polityki embarga: ani strony z zasadami, ani terminu przy pojedynczym znalezisku, ani odliczania. Tylko status, poziom ważności i identyfikatory. To i tak przejrzystsze niż ciche skanowanie, a mimo to zostajesz bez żadnej daty.

Anthropic 90-dniowy termin ogłosił, a VulnCheck znalazł dziesięć znalezisk, które go przekroczyły i nadal nie zostały opublikowane. Wybór nie jest więc między dostawcą z polityką a dostawcą bez niej, tylko między datą w **twoim** rejestrze a datą w cudzym kalendarzu publikacji.

Tę lukę zamykają trzy pola: `requested_embargo_at` (o co poprosił zgłaszający), `agreed_embargo_at` (co wynegocjowaliście) i `published_at` (co się faktycznie stało). Kit ich nie ma i mówi to wprost na własnej stronie porównania: *„Kit nie modeluje żadnych terminów ujawnienia ani dat embarga. Pole z datą embarga to uczciwa prośba; dziś Kit śledzi potwierdzenie odbioru, a nie ujawnienie.”* Jedyna 90-dniowa stała w kodzie to wygaśnięcie tokenu potwierdzającego odbiór, a nie zegar ujawnienia.

## Limity to zła obrona: co naprawdę dał limit Apple'a

Pierwszym odruchem po lekturze tego wszystkiego jest nałożenie na nadawcę limitu. Apple przeprowadziło ten eksperyment publicznie, a wynik jest ciekawszy niż nagłówek. W czerwcu 2026 roku firma dołożyła w swoim portalu dla badaczy limit zgłoszeń i **30-dniową karencję**, a zgłoszenia ponad limit wymagają osobnej prośby. Wysokości limitu nie podano.

Bynario, który przez cały 2025 rok i początek 2026 złożył **13 zgłoszeń**, zbudował własne narzędzia oparte na AI i w trzy tygodnie złożył **ponad 50 zgłoszeń dotyczących macOS**. Przebił limit i został odcięty od portalu dokładnie w chwili, gdy miał w ręku krytyczne znalezisko.

Limit nie zatrzymał znaleziska i właśnie to zwykle się pomija. Apple dostało szczegóły inną drogą i 27 lipca załatało **CVE-2026-43760**, błąd typu confused deputy w starej ścieżce VNC, który pozwalał uwierzytelnionemu klientowi VNC czytać i tworzyć pliki jako root. Bynario opublikował analizę dwa dni później, już po wydaniu łatki: to normalna publikacja badawcza po załataniu, a nie sfrustrowane wyrzucenie zero-daya do sieci.

Potem przyszło to, na co limit nie miał żadnego wpływu. Opis Bynario skierował uwagę badaczy na starą ścieżkę kodu Screen Sharing. W ciągu 48 godzin ujawniono w tym samym demonie osobny błąd **typu pre-auth**, czyli możliwy do wykorzystania bez uwierzytelnienia, razem z proof of concept. Cztery dni później powstał działający exploit, a potem ruszyły realne ataki: kopanie kryptowalut na wystawionym do internetu porcie 5900.

Apple wydało awaryjną łatkę 6 sierpnia. CISA 14 sierpnia podniosła ocenę z 7,1 do **9,8**, a 18 sierpnia dopisała podatność do katalogu Known Exploited Vulnerabilities, a urzędom federalnym wyznaczyła termin naprawy na 21 sierpnia 2026 roku.

Dziesięć dni od błędu podniesienia uprawnień, który wymagał uwierzytelnienia, do zdalnego wykonania kodu bez uwierzytelnienia w tym samym komponencie, z wpisem w KEV włącznie.

Morał nie brzmi „limity rodzą zero-daye”; to nadinterpretacja materiału. Jest węższy i bardziej użyteczny: **limit zgłoszeń decyduje o tym, jak szybko zgłoszenia trafiają do twojej kolejki, i o niczym więcej, a na pewno nie o tym, jak szybko dowiaduje się świat.** Na tej osi czasu kontrolujesz realnie jedno: własne moce przerobowe w przyjmowaniu zgłoszeń. Limit nie dołożył ich ani grama.

## Lepsza odpowiedź GitHuba: cztery zgłoszenia i wyjście z limitu

GitHub uderzył w tę samą ścianę i zamiast dławienia wybrał podział na poziomy. Dla zgłoszeń złożonych 27 lipca 2026 roku i później prowadzi publiczny poziom ze stałymi stawkami **250 $ / 2 000 $ / 5 000 $ / 10 000 $** od niskich po krytyczne oraz poziom VIP wyłącznie na zaproszenie: **1 000 $ / 7 500 $ / 20 000 $ / 30 000 $ i więcej**. Najciekawsze jest to, jak się tam wchodzi: badacz poniżej progu reputacji platformy dostaje **do czterech zgłoszeń na start**, żeby się pokazać, a drzwi do VIP otwiera **jedno prawidłowe krytyczne** zgłoszenie, dwa wysokie, cztery średnie albo siedem niskich.

To limit, z którego jest wyjście. Narzędzia Bynario spaliłyby cztery zgłoszenia, a potem na dowolnym z krytycznych błędów, które i tak zgłoszono później, otworzyłyby sobie szybką ścieżkę. Limit Apple'a nie ma żadnych drzwi: liczy zgłoszenia, przestaje liczyć, a jedyne przejście dalej prowadzi przez kalendarz.

Nazwijmy tę różnicę projektową wprost: **ograniczenie przepustowości da się obronić tylko wtedy, gdy o jego zniesieniu przesądza to, czy masz rację, a nie odczekanie 30 dni.** Podsumowanie GitHuba jest zdaniem wartym skopiowania: *„nie zarabiasz więcej, zgłaszając więcej. Zarabiasz więcej, zgłaszając lepiej.”*

Kit wdrożył połowę tego pomysłu, tę o zaufaniu, i musi naprawić drugą, tę o limitach. `Csirt::Researcher#karma_tier` dzieli badaczy według zgromadzonej karmy i przy 200 punktach nadaje status `trusted`, a zasilają ją wartości `Csirt::KarmaEvent` ze znakiem: `report_validated` +5, `bounty_awarded` +10, po drugiej stronie `spam_dismissed` -10, `ai_slop_confirmed` -15, `policy_violation` -25. Karma jest z założenia liczona osobno dla każdego konta, więc ocena wystawiona w jednym programie nie ciągnie się za badaczem po całym internecie.

Domyślne ustawienia Kit i tak odcięłyby kogoś takiego jak Bynario. `SpamConfig` blokuje po 5 zgłoszeniach w 300 sekund, a limiter zapytań ogranicza zgłoszenia CSIRT do **10 na godzinę z jednego IP**. Zgłaszający z czterdziestoma zweryfikowanymi znaleziskami przekracza oba progi.

To ten sam tryb awarii co u Apple'a, tyle że w naszych własnych domyślnych ustawieniach, a lekarstwem nie jest większa liczba. Trzeba liczyć **partie** zamiast żądań i pozwolić, żeby `karma_tier` podnosił pułap temu, kto sobie na to zapracował.

## Najpierw odtworzenie, potem triaż: pięć pól, których musi wymagać twoja polityka

Ross McKerchar, CISO w Sophosie, i Ryan Westman ujmują standard zwięźle: programy potrzebują *„jasnych PoC, logów, śladów wykonania, wersji, których dotyczy problem, i powtarzalnych kroków. Jeśli twierdzenia nie da się odtworzyć, nie ma dla niego miejsca w kolejce.”*

Zamień to na wymagane pola formularza, a nie na akapit polityki. Wymagaj:

1. **Działającego proof of concept.** Skryptu, żądania albo śladu wykonania. Opis exploita prozą to nie exploit.
2. **Dokładnych wersji, których dotyczy problem.** SHA commita albo tag wydania. Nigdy „najnowsza”.
3. **Kroków odtworzenia, które wykona ktoś zupełnie obcy**, od czystego stanu po zaobserwowany skutek.
4. **Czy jakakolwiek część tego znaleziska powstała z pomocą modelu?** Tak albo nie, plus jaki system. Nie po to, żeby karać, tylko żeby wiedzieć, gdzie to skierować.
5. **Czy człowiek zweryfikował to znalezisko od początku do końca?** Tak albo nie, plus kto.

Całą robotę wykonuje piąte pole. To ono odróżnia przypadek Bynario, gdzie wynik pracy AI sprawdził człowiek i wyszło z tego krytyczne znalezisko, od zwykłych śmieci AI. Dziś prawie nikt o to nie pyta, a kosztuje to dwa pola tak/nie i jedno tekstowe. W chwili, w której zaczniesz przyjmować kampanie, dołóż jeszcze dwa: **identyfikator partii albo nazwę kampanii** oraz **oczekiwaną datę ujawnienia**. Niech zgłaszający zapisze swój zegar w twoim rejestrze, a nie na swoim blogu.

<div class="blog-inline-cta">
  <p><strong>Prowadzisz VDP z prawdziwym rejestrem?</strong> Moduł CSIRT w Kit ma ustrukturyzowane przyjmowanie zgłoszeń, wykrywanie pochodzenia z AI, rozpoznawanie duplikatów, SLA osobno dla każdego poziomu ważności i generowany plik security.txt.</p>
  <p><a href="/users/sign_up">Zacznij bezpłatny okres próbny</a></p>
</div>

## Zegar regulatora rusza 11 września 2026

Jeśli sprzedajesz do UE produkty z elementami cyfrowymi, jedno zgłoszenie z zewnątrz potrafi uruchomić termin prawny, który z twoją kolejką nie ma nic wspólnego. Od **11 września 2026 roku** Cyber Resilience Act wymaga wczesnego ostrzeżenia w ciągu **24 godzin**, pełnego powiadomienia w ciągu **72 godzin** i raportu końcowego w ciągu **14 dni** od zastosowania środka naprawczego, składanych do krajowego CSIRT przez CRA Single Reporting Platform i przekazywanych równocześnie do ENISA.

Ten zegar rusza w chwili, w której dowiadujesz się o aktywnym wykorzystywaniu podatności. Nie obchodzi go, że zgłoszenie przyszło jako pozycja 23 z 40, że nikt jeszcze go nie przeczytał ani że napisał je model. Partia leżąca cztery dni bez odczytu to już ryzyko niezgodności z przepisami, nie tylko zaległość. Cały obowiązek opisuje nasz [przewodnik po unijnym Cyber Resilience Act](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure).

## Bez przyjmowania zgłoszeń kanałem ujawnienia staje się cudzy rejestr

Kiedy zgłaszający nie znajdzie sposobu, żeby się z tobą skontaktować, nie przestaje zgłaszać. Publikuje.

`security.txt` to najtańsza naprawa w bezpieczeństwie i zarazem najrzadziej stosowana. Przegląd miliona najpopularniejszych domen z 2025 roku wykazał, że plik publikuje **1,25% (12 510 witryn)**, wobec 0,7% w kwietniu 2024, a zgodnych z RFC 9116 jest wśród nich zaledwie **44%**. Około 99% sieci nie ma czytelnego maszynowo adresu kontaktowego ds. bezpieczeństwa, a ponad połowa tych nielicznych ma go wadliwy.

Kit generuje zgodny plik na podstawie `Csirt::SecurityTxtConfig`, z polami `Contact`, `Policy`, `Acknowledgments`, `Encryption` oraz kroczącą datą `Expires`, ustawianą zawsze 365 dni naprzód. Jeśli nie masz jeszcze żadnego programu, zacznij od naszego [przewodnika po uruchomieniu programu ujawniania podatności](/blog/how-to-set-up-vulnerability-disclosure-program), zanim zaczniesz myśleć o partiach.

## Jak CSIRT w Kit radzi sobie z kampanią i czego mu jeszcze brakuje

Część tego, czego wymaga ta chwila, w Kit już działa. Część nie, a ten podział mówi więcej niż lista funkcji.

**Co się broni dzisiaj:**

- **Ustrukturyzowane przyjmowanie zgłoszeń zamiast pola na prozę.** `Csirt::Report` wymaga `title`, `description`, `vulnerability_type` z zamkniętej listy oraz `affected_endpoint`, a do tego ma osobną kolumnę `reproduction_steps`. Ta kolumna dopuszcza wartość NULL, co według checklisty powyżej jest błędem. Ustawienie jej jako wymaganej to dokładnie ta zmiana konfiguracji, po którą trzeba dziś sięgnąć.
- **Wykrywanie pochodzenia z AI jako pełnoprawny rekord.** `Csirt::AiScreening` ocenia każde nowe zgłoszenie i zwraca `ai_confidence_score` wraz z sygnałami z zamkniętej listy (`hallucinated_functions`, `fabricated_cves`, `no_specific_poc`, `vague_reproduction_steps` i kolejne) oraz rekomendacją `pass` / `review` / `flag`. To test odtwarzalności wg Sophosa wdrożony jako kolumna, a nie jako akapit polityki.
- **Grupowanie po przyczynie źródłowej istnieje już jako prymityw.** Zgłoszenia niosą ze sobą wektor o 3 072 wymiarach, a wykrywanie duplikatów szuka najbliższych sąsiadów wg podobieństwa kosinusowego w obrębie programu. Tam, gdzie czterdzieści znalezisk to jedna klasa błędu, właśnie ten mechanizm zwija czterdzieści zgłoszeń w jedno.
- **Reputacja zamiast limitów**, przez `karma_tier`.
- **SLA rozdzielone na potwierdzenie i rozwiązanie.** `Csirt::SlaConfig` domyślnie daje 72 godziny na potwierdzenie i terminy rozwiązania zależne od poziomu ważności: od 24 godzin przy `super_critical` po 720 przy niskim, plus powtarzane alerty o naruszeniu i eskalację na dyżur przy krytycznych.

**Czego brakuje, ujęte jako plan, a nie jako lista funkcji:**

1. **Brak obiektu kampanii.** Czterdzieści zgłoszeń to wciąż czterdzieści wierszy z czterdziestoma zegarami.
2. **Brak pól osi czasu ujawnienia.** Cykl życia biegnie od `submitted` przez `resolved` do `paid` i nie ma w nim żadnego pojęcia opisującego zegar zgłaszającego.
3. **Brak deklarowanych flag „wygenerowane przez model” i „zweryfikowane przez człowieka”.** Wykrywanie pochodzenia z AI działa po fakcie, a samego zgłaszającego nikt o to nie pyta.
4. **Domyślne limity, które odcięłyby zgłaszającego masowo w dobrej wierze**, dokładnie tak jak limit Apple'a.

Każdy inny tekst o tym rejestrze traktuje go jako historię o modelu. To historia o skrzynce odbiorczej: znaleziska są w większości prawdziwe, w większości niezgłoszone i nadchodzą.

Zmiana, która cię na to przygotuje, jest niewielka: to **kampania**, a nie zgłoszenie, ma być tym, co twój program potwierdza, za co odpowiada i co odlicza. A potem wpisz datę zgłaszającego do swojego rejestru, zanim on wpisze ją na swoim blogu.