Logo StartupKit
PL
Vulnerability Disclosure

Obsługa 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 > Triage Board, 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
Znacznik ważności Kolorowe oznaczenie 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 znacznik 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 lub użyć menu Triage na stronie szczegółów zgłoszenia, aby zmienić status.

                                ┌─────────────┐
                           ┌───>│   Dismissed  │
                           │    └─────────────┘
                           │  (from any active status)
┌───────────┐  ┌─────────┐│  ┌───────────────────┐  ┌───────────┐
│ 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 dowolnego aktywnego statusu

Dwa szczególne przejścia:

  • Dismissed jest osiągalny z dowolnego aktywnego statusu. Badacz zawsze otrzymuje powiadomienie z podaniem przyczyny.
  • Dismissed > Submitted umożliwia ponowne otwarcie zgłoszenia w przypadku błędnego odrzucenia.

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 Communicating with Researchers.

Wskaźniki SLA

Każda karta zgłoszenia wyświetla znacznik SLA, dzięki czemu zespół szybko zauważy zaległości. Zegar SLA potwierdzenia odbioru startuje w momencie przesłania zgłoszenia. SLA rozwiązania zaczyna biec, gdy zgłoszenie osiągnie status „Validated”.

Znacznik 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 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 prawdopodobnie 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, 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 plakietką 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 — znacznik 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 9.5–10.0
Critical 9.0–9.4
High 7.0–8.9
Medium 4.0–6.9
Low 0.1–3.9
Informational 0.0

Po dokonaniu oceny 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 — należy podlinkować 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.

W przypadku błędnego odrzucenia zgłoszenie można ponownie otworzyć z kolumny Dismissed, co przywraca je do statusu Submitted.

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 zmian i harmonogramów opisano w On-Call Rotation.

Przypisanie zbiorcze: zaznaczenie wielu kart zgłoszeń za pomocą pól wyboru i wybranie Assign z paska akcji zbiorczych 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ń. Każda operacja zbiorcza jest rejestrowana indywidualnie w dzienniku audytu każdego objętego zgłoszenia.

Szybka lista kontrolna

  • Codzienne przeglądanie tablicy 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ń w celu utrzymania porządku 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ą

Kolejne kroki

Wpisz, aby wyszukać...