Triaż zgłoszeń
Jak korzystać z tablicy Kanban do triażu, odczytywać wskaźniki SLA, oceniać ważność oraz rozwiązywać lub odrzucać zgłoszenia.
Dlaczego to ważne
Nieustrukturyzowany triaż to najczęstsza przyczyna porażki programów ujawniania podatności. Prawidłowe zgłoszenia giną w szumie, terminy SLA są przekraczane niezauważenie, a badacze rezygnują ze współpracy z programem. Tablica Kanban zapewnia zespołowi wspólny widok w czasie rzeczywistym na wszystkie otwarte zgłoszenia z wbudowaną widocznością SLA — nic nie umknie uwadze.
Tablica triażu
Przejdź do VDP > Tablica triażu, aby zobaczyć wszystkie zgłoszenia uporządkowane według statusu. Każda kolumna reprezentuje etap cyklu życia zgłoszenia, a każda karta odpowiada pojedynczemu zgłoszeniu.
Tablica obsługuje dwa widoki:
- Widok tablicy — kolumny Kanban z kartami obsługiwanymi metodą drag-and-drop (domyślny)
- Widok listy — sortowalna tabela z tymi samymi filtrami
Każda karta zgłoszenia zawiera:
| Element | Opis |
|---|---|
| ID zgłoszenia | Identyfikator z prefiksem (np. RPT-abc123) |
| Tytuł | Tytuł podatności, skrócony do 40 znaków |
| Badge ważności | Kolorowy badge poziomu ważności z oceny |
| Odliczanie SLA | Pozostały czas ze wskaźnikiem zielonym/żółtym/czerwonym |
| Osoba przypisana | Awatar członka zespołu lub „Nieprzypisane” |
| Flagi | Ostrzeżenie o duplikacie lub badge AI screening, jeśli dotyczy |
Pasek filtrów nad kolumnami pozwala zawęzić widok:
- Ważność — wielokrotny wybór (od Informational do Super Critical)
- Osoba przypisana — lista rozwijana (członkowie zespołu + „Nieprzypisane”)
- SLA — On Track / At Risk / Breached
- Wyszukiwanie — filtrowanie po tytule, ID zgłoszenia lub adresie e-mail badacza
Trzy ostatnie kolumny (Fix Verified, Paid, Dismissed) są domyślnie zwinięte i wyświetlają jedynie liczbę elementów. Kliknięcie rozwija kolumnę.
Cykl życia zgłoszenia
Każde zgłoszenie podlega zdefiniowanej maszynie stanów. Kartę można przeciągnąć między kolumnami na tablicy albo skorzystać z przycisków statusu na banerze strony zgłoszenia — jeden główny przycisk dla oczywistego następnego kroku oraz menu z pozostałymi dozwolonymi przejściami. Do każdej zmiany statusu można dołączyć notatkę (pojawia się ona na osi czasu), a cofnięcie zgłoszenia do wcześniejszego stanu jej wymaga. Odrzucenie zawsze prosi o podanie powodu: przeciągnięcie karty do kolumny Dismissed otwiera okno odrzucania, zamiast po cichu zamykać zgłoszenie (zobacz Odrzucanie zgłoszeń).
┌─────────────┐
┌───>│ Dismissed │
│ └─────────────┘
│ (z Submitted, Triaged, Needs
│ Clarification, Validated lub In Progress)
│
┌───────────┐ ┌─────────┐│ ┌───────────────────┐ ┌───────────┐
│ Submitted ├─>│ Triaged ├┴─>│ Validated ├─>│In Progress│
└───────────┘ └────┬────┘ └─────────┬──────────┘ └─────┬─────┘
│ │ │
v v v
┌───────────────────┐ ┌──────────┐
│Needs Clarification│ │ Resolved │
└───────────────────┘ └────┬─────┘
│
v
┌──────────────┐
│ Fix Verified │
└──────┬───────┘
│
v
┌──────┐
│ Paid │
└──────┘
| Status | Znaczenie |
|---|---|
| Submitted | Stan początkowy po przesłaniu formularza przez badacza |
| Triaged | Zespół zapoznał się ze zgłoszeniem i rozpoczął ocenę |
| Needs Clarification | Zespół wysłał pytanie; oczekiwanie na odpowiedź badacza |
| Validated | Potwierdzona realna podatność w zakresie programu; rozpoczyna się praca nad poprawką |
| In Progress | Trwają prace inżynieryjne nad poprawką |
| Resolved | Poprawka wdrożona; badacz powiadomiony |
| Fix Verified | Badacz potwierdził działanie poprawki (opcjonalny krok ponownej weryfikacji) |
| Paid | Nagroda wypłacona, cykl życia zakończony |
| Dismissed | Zamknięte bez poprawki — możliwe z Submitted, Triaged, Needs Clarification, Validated lub In Progress |
Dwa szczególne przejścia:
- Dismissed jest osiągalny z Submitted, Triaged, Needs Clarification, Validated lub In Progress (nie z Resolved ani Fix Verified). Badacz zawsze otrzymuje powiadomienie z podaniem przyczyny. Jeśli zgłoszenie ma zatwierdzoną nagrodę, odrzucenie powoduje również jej cofnięcie — zobacz sekcję Odrzucanie zgłoszeń poniżej.
- Dismissed > Submitted umożliwia ponowne otwarcie zgłoszenia w przypadku błędnego odrzucenia. Ponowne otwarcie nie przywraca cofniętej nagrody — po ponownej walidacji zgłoszenia zatwierdź nową ręcznie.
Każda zmiana statusu jest rejestrowana w dzienniku audytu zgłoszenia z informacją o autorze, znacznikiem czasu i opcjonalnym komentarzem. Szczegóły wysyłania wiadomości do badaczy na poszczególnych etapach opisano w Komunikacji z badaczami.
Wskaźniki SLA
Każda karta zgłoszenia wyświetla badge SLA, dzięki czemu zespół szybko zauważy zaległości. Zegar SLA potwierdzenia odbioru startuje w momencie przesłania zgłoszenia.
| Badge | Kolor | Znaczenie |
|---|---|---|
| On Track | Zielony | W ramach okna SLA |
| At Risk | Żółty | Termin SLA się zbliża — konieczne szybkie działanie |
| Breached | Czerwony | Termin SLA został przekroczony |
Filtr SLA na tablicy triażu z wybraną opcją Breached natychmiast wyświetli zgłoszenia wymagające uwagi. Cele SLA konfiguruje się dla każdego poziomu ważności w VDP > Program Settings > SLAs.
AI Screening
Każde przesłane zgłoszenie jest automatycznie analizowane pod kątem treści niskiej jakości lub wygenerowanych przez AI, zanim trafi na tablicę triażu. Analiza odbywa się w tle, a wyniki są dołączane do zgłoszenia w ciągu kilku sekund.
Moduł sprawdza sygnały wskazujące na masowo produkowane lub sfabrykowane zgłoszenia:
| Sygnał | Co wykrywa |
|---|---|
| Zmyślone funkcje | Odwołania do nazw funkcji, metod API lub ścieżek plików, które są prawdopodobne, ale najpewniej wymyślone |
| Sfabrykowane CVE | Numery CVE nieistniejące w publicznych bazach danych |
| Znane CVE jako nowe | Znana, publicznie ujawniona podatność przedstawiona jako nowe odkrycie |
| Brak konkretnego PoC | Brak dowodu koncepcyjnego, brak kroków specyficznych dla celu, brak porównania oczekiwanego i faktycznego wyniku |
| Niejasne kroki reprodukcji | Ogólnikowe kroki typu „przejdź do strony logowania i wpisz payload”, pasujące do dowolnej aplikacji |
| Szablonowy język | Sztampowe frazy typu „As a security researcher, I discovered…” bez kontekstu specyficznego dla celu |
| Szablonowa struktura | Sztywne numerowane sekcje i pogrubione nagłówki sugerujące skopiowanie z generatora zgłoszeń |
| Ogólnikowe zalecenia naprawcze | Szablonowe porady typu „sanitize all inputs” bez wskazówek specyficznych dla celu |
| Niespójne szczegóły techniczne | Technologie, frameworki lub wersje niezgodne z badanym endpointem |
| Odwołania do nieistniejących elementów kodu | Sfabrykowane hasze commitów, nazwy funkcji lub ścieżki plików niemożliwe do zweryfikowania |
Analiza generuje wynik pewności (0–100) i rekomendację:
| Rekomendacja | Zakres wyniku | Efekt |
|---|---|---|
| Pass | 0–30 | Zgłoszenie pojawia się na tablicy normalnie |
| Review | 31–60 | Zgłoszenie pojawia się z dyskretnym znacznikiem do przeglądu |
| Flag | 61–100 | Zgłoszenie jest oznaczone badge’em AI screening na karcie Kanban |
AI screening nigdy nie odrzuca zgłoszenia automatycznie. Oflagowane zgłoszenia pozostają w pełni widoczne i dostępne do obsługi — badge jedynie informuje zespół, że treść może wymagać dodatkowej weryfikacji. Ostateczną decyzję zawsze podejmuje zespół.
Ocena ważności
Po otwarciu zgłoszenia kliknięcie Assess uruchamia scoring za pomocą CVSS v3.1. Wbudowany kalkulator przeprowadza przez osiem metryk:
| Metryka | Opcje |
|---|---|
| Attack Vector | Network, Adjacent, Local, Physical |
| Attack Complexity | Low, High |
| Privileges Required | None, Low, High |
| User Interaction | None, Required |
| Scope | Unchanged, Changed |
| Confidentiality Impact | None, Low, High |
| Integrity Impact | None, Low, High |
| Availability Impact | None, Low, High |
System automatycznie oblicza wynik bazowy i przypisuje go do poziomu ważności:
| Poziom | Zakres CVSS |
|---|---|
| Super Critical | 10.0 |
| Critical | 9.0–9.9 |
| High | 7.0–8.9 |
| Medium | 4.0–6.9 |
| Low | 0.1–3.9 |
| Informational | 0.0 |
Po ocenie poziom ważności odblokowuje sugerowany przedział nagrody z macierzy nagród. Wektor CVSS jest zapisywany w zgłoszeniu i widoczny w dzienniku audytu. Jeśli ważność wynosi Critical lub Super Critical, powiadomienie eskalacyjne jest wysyłane do skonfigurowanych kontaktów eskalacyjnych.
Odrzucanie zgłoszeń
Kliknięcie Dismiss na otwartym zgłoszeniu zamyka je bez poprawki. Wymagane jest wybranie przyczyny:
| Przyczyna | Kiedy stosować |
|---|---|
| Out of Scope | Cel nie jest objęty konfiguracją zakresu programu |
| Duplicate | Ta sama podatność została już zgłoszona — podlinkuj oryginał |
| Not Reproducible | Zespół nie zdołał odtworzyć problemu na podstawie podanych kroków |
| Informational | Brak podatności nadającej się do wykorzystania; badacz dzieli się ogólnym spostrzeżeniem |
| Spam | Automatyczne lub wyraźnie niestaranne zgłoszenie |
| AI Slop | Treść wygenerowana przez AI ze sfabrykowanymi lub zmyślonymi szczegółami |
Opcjonalna notatka pozwala wyjaśnić decyzję. Badacz otrzymuje e-mail na podstawie skonfigurowanego szablonu odrzucenia z podaną przyczyną i notatką. Przyczyna odrzucenia jest trwale zapisywana w dzienniku audytu i nie podlega edycji po zapisaniu.
Odrzucanie zgłoszenia z zatwierdzoną nagrodą
Jeśli zgłoszenie ma zatwierdzoną nagrodę, odrzucenie powoduje również jej cofnięcie. Okno odrzucania wyświetla bursztynowe ostrzeżenie z kwotą, osobą zatwierdzającą i datą zatwierdzenia, a przycisk zatwierdzenia zmienia się na Dismiss & revoke $X bounty. Cofnięcie jest rejestrowane jako wpis bounty_revoked w niezmiennej księdze finansowej, a e-mail o odrzuceniu informuje badacza, że nagroda została wycofana i nie zostanie wypłacona — standardowa procedura odwoławcza pozostaje dostępna. Szczegóły opisano w Nagrodach i wypłatach.
Obowiązują dwa zabezpieczenia:
- Nagrody, której wypłata ma status Completed (opłacona), nigdy nie można cofnąć.
- Wypłata w toku (status Pending lub Processing) blokuje odrzucenie — najpierw oznacz wypłatę jako nieudaną albo pozwól jej się zakończyć.
Przeciągnięcie karty do kolumny Dismissed na tablicy otwiera to samo okno odrzucania — z wyborem powodu oraz, gdy nagroda jest zatwierdzona, ostrzeżeniem o jej cofnięciu — więc przeciągnięcie na tablicy nigdy nie odrzuca zgłoszenia (ani nie cofa nagrody) bez tego kontekstu. To ten sam przepływ, co przycisk Dismiss na stronie zgłoszenia.
W przypadku błędnego odrzucenia zgłoszenie można ponownie otworzyć z kolumny Dismissed, co przywraca je do statusu Submitted. Ponowne otwarcie nie przywraca cofniętej nagrody — po ponownej walidacji zgłoszenia zatwierdź nową ręcznie.
Rozwiązywanie odwołań
Gdy badacz odwołuje się od decyzji (zob. Portal badacza), na stronie zgłoszenia pojawia się panel Researcher appeal z uzasadnieniem badacza, a osoba dyżurująca otrzymuje alert prowadzący prosto do niego.
Z poziomu panelu administrator rozwiązuje odwołanie:
- Akceptacja — zgadzasz się z badaczem. Jeśli zgłoszenie było odrzucone, akceptacja otwiera je ponownie i kieruje z powrotem do statusu Submitted (triaż) tą samą audytowaną ścieżką ponownego otwierania opisaną powyżej. Badacz otrzymuje e-mail z informacją, że odwołanie zostało zaakceptowane.
- Odrzucenie — podtrzymujesz pierwotną decyzję. Badacz otrzymuje e-mail z informacją, że decyzja pozostaje w mocy.
Decyzja, osoba rozpatrująca i znacznik czasu są zapisywane w zgłoszeniu i dodawane do jego osi czasu. Podobnie jak przy ponownym otwieraniu, akceptacja odwołania nie przywraca cofniętej nagrody — po ponownej walidacji zgłoszenia zatwierdź nową.
Przypisywanie zgłoszeń
Kliknięcie awatara osoby przypisanej (lub „Assign”) na karcie zgłoszenia lub w widoku szczegółów przypisuje członka zespołu. Przypisana osoba otrzymuje powiadomienie w aplikacji i e-mail.
Gdy włączone jest automatyczne przypisywanie, nowe zgłoszenia są automatycznie przypisywane osobie dyżurującej. Jeśli nikt nie pełni dyżuru, jako zapas stosowana jest domyślna osoba przypisana. Szczegóły konfiguracji dyżurów i harmonogramów opisano w Rotacji dyżurów.
Przypisanie zbiorcze: zaznacz wiele kart zgłoszeń za pomocą pól wyboru i wybierz Assign z paska akcji zbiorczych, który pojawia się na dole tablicy.
Zgłoszenia o ważności Critical i Super Critical automatycznie wysyłają e-mail eskalacyjny do skonfigurowanych kontaktów, niezależnie od przypisania. Kontakty eskalacyjne konfiguruje się w VDP > Program Settings > Triage.
Operacje zbiorcze
Zaznaczenie wielu kart zgłoszeń za pomocą pól wyboru włącza tryb zaznaczania zbiorczego. Na dole tablicy pojawia się pływający pasek akcji z trzema opcjami:
| Akcja | Opis |
|---|---|
| Assign | Przypisanie wszystkich zaznaczonych zgłoszeń do członka zespołu |
| Dismiss | Odrzucenie wszystkich zaznaczonych zgłoszeń ze wspólną przyczyną |
| Change Severity | Zmiana poziomu ważności wszystkich zaznaczonych zgłoszeń |
Zbiorcze odrzucanie wymaga wybrania jednej przyczyny stosowanej do wszystkich zaznaczonych zgłoszeń. Zgłoszenia z zatwierdzoną nagrodą są pomijane — komunikat potwierdzenia podaje liczbę pominiętych — ponieważ cofnięcie nagrody wymaga okna odrzucania na stronie pojedynczego zgłoszenia. Każda operacja zbiorcza jest rejestrowana indywidualnie w dzienniku audytu każdego objętego zgłoszenia.
W skrócie
- Codzienne przeglądanie tablicy triażu pod kątem nowych zgłoszeń
- Sprawdzanie filtra SLA „Breached” pod kątem zaległych zgłoszeń
- Ocena ważności (CVSS) dla każdego zwalidowanego zgłoszenia
- Przypisywanie zgłoszeń członkom zespołu z odpowiednią wiedzą domenową
- Niezwłoczne odrzucanie wyraźnie nieprawidłowych zgłoszeń, żeby utrzymać porządek w kolejce
- Używanie statusu „Needs Clarification”, gdy kroki reprodukcji są niewystarczające
- Weryfikacja zgłoszeń oznaczonych przez AI ze szczególną uwagą przed odrzuceniem lub walidacją
Co dalej
- Komunikacja z badaczami — wątki wiadomości, szablony e-mail, powiadomienia Slack oraz pytanie @KitBot o zgłoszenia
- Nagrody i wypłaty — przyznawanie nagród, dokumenty podatkowe i księga finansowa