## Dlaczego to ważne

Zgłoszenie podatności żyje tygodniami i zmienia stan kilkanaście razy. Jeśli każda z tych zmian to osobny wpis w Slacku, aktywny program zasypuje własny kanał — a wyciszony `#vdp` to zegar SLA tykający tam, gdzie nikt nie patrzy.

Dlatego Kit publikuje **jedną kartę na zgłoszenie**, a wszystko inne podwiesza w wątku tej karty. Niezależnie od tego, ile razy zgłoszenie zmieni stan, w treści kanału nadal widnieje dla niego jedna pozycja.

## Karta i wątek

Pierwsze, co Kit robi z nowym zgłoszeniem, to opublikowanie jego karty. Od tej karty zaczyna się wątek i zostaje ona na miejscu przez całe życie zgłoszenia.

- **Karta jest przerysowywana w miejscu.** Kit buduje ją na nowo ze zgłoszenia i edytuje tę samą wiadomość. Nigdy nie publikuje drugiej karty ani własnej karty „zmiana statusu”.
- **Wątek jest zapisem.** Wszystko, co ktoś z zespołu może później potrzebować odtworzyć, trafia pod spodem jako krótka odpowiedź.

Ten podział jest celowy. W workspace Slacka można ustawić limit czasu na edycję wiadomości, więc edycja karty może zacząć trwale się nie udawać, gdy wiadomość jest już wystarczająco stara. Wtedy tracisz wygodę, nigdy fakt — fakt jest już w wątku.

> [!IMPORTANT]
> **Slack nie powiadamia nikogo o edycji.** Gdy karta jest przerysowywana, nikt nie dostaje pingu, a kanał nie zmienia kolejności. To właśnie utrzymuje ciszę na kanale — ale oznacza też, że karta nie jest alertem. Żeby dowiadywać się o zmianach w zgłoszeniu, obserwuj wątek; o odpowiedziach Slack powiadamia.

## Co pokazuje karta

**Otwarte** zgłoszenie na każdym etapie renderuje te same pięć sekcji, więc kanał zawsze wygląda tak samo.

**Nagłówek** — emoji poziomu ważności i tytuł zgłoszenia. Tytuły pisze badacz, więc Kit je zabezpiecza: tytuł zawierający `<!channel>` trafia tam jako tekst, a nie jako ping całego pokoju.

**Sześć stałych pól**, w tej kolejności. Pole bez odpowiedzi pokazuje myślnik (`—`), zamiast znikać.

| Pole | Co pokazuje |
| --- | --- |
| **Severity** | Poziom ważności, a po ocenie zgłoszenia także wynik CVSS. Przed oceną pokazuje deklarację samego badacza, wyraźnie opisaną jako *„własna ocena badacza, zgłoszenie jeszcze nieocenione”* — samodzielnie wystawione przez obcą osobę „Critical” nigdy nie stoi nieoznaczone w polu Severity Twojego zespołu. |
| **Status** | Bieżący status zgłoszenia. |
| **Type** | Typ podatności. |
| **Assignee** | Imię i nazwisko obecnej osoby przypisanej albo **Unassigned** (Nieprzypisane). |
| **SLA** | **Konkretna** data i godzina, do której trzeba potwierdzić odbiór, w UTC — nie odliczanie. Odliczanie na żywo przepisywałoby kartę co minutę. |
| **Bounty** | Sformatowana kwota nagrody, gdy już jakaś jest. |

**Linia zaufania** — kraj zgłaszającego (jeśli znany), nazwa, pod którą badacz jest wyróżniany, wraz z jego poziomem karmy, oraz liczba prawidłowych zgłoszeń, które ma **w tym programie**. Pozycja badacza w programie innej firmy nigdy nie przecieka do Twojego. Segmenty bez danych są pomijane, a nie renderowane jako puste.

**Linia pochodzenia** — ID zgłoszenia, czas przesłania w UTC i nazwa programu.

**Przyciski** — **Reply to researcher ↗** (tylko gdy zgłoszenie ma konto badacza) oraz **Open in Kit ↗**, zawsze na końcu. Oba to zwykłe adresy URL Kit: kliknięcie loguje Cię i na miejscu ponownie sprawdza Twoje uprawnienia. Żaden przycisk nie niesie tokenu, linku do udostępniania ani wstępnie podpisanego adresu URL załącznika.

Gdy zgłoszenie osiągnie status **Paid** lub **Dismissed**, karta zwija się do nagłówka, jednej linii z wynikiem (`💸 Paid · $250 USD` albo `🚫 Dismissed` z przyczyną odrzucenia) i przycisku **Open in Kit ↗**. Zamknięta sprawa nie powinna wiecznie zajmować pół ekranu kanału. *Fix Verified* nie powoduje zwinięcia — zgłoszenie wciąż czeka na wypłatę, więc zachowuje pełną kartę.

## Co dodaje odpowiedź, a co tylko przerysowuje kartę

Zasada: **odpowiedź w wątku powstaje wtedy, gdy wydarzyło się coś, co człowiek może później potrzebować odtworzyć.** Wszystko inne tylko przerysowuje kartę.

| Zdarzenie | Odpowiedź w wątku | Karta |
| --- | --- | --- |
| Nowe przesłane zgłoszenie | — to *jest* ta karta | Publikowana |
| Dowolna zmiana statusu | Tak | Przerysowana |
| Naruszenie SLA | Tak | Przerysowana |
| Zatwierdzenie nagrody | Tak | Przerysowana |
| Zrealizowana wypłata nagrody | Tak | Przerysowana |
| Otrzymanie odwołania | Tak | Przerysowana |
| Eskalacja — zgłoszenie ocenione na poziomie ważności wyzwalającym eskalację albo [zaległe zgłoszenie](/docs/stalled-report-nudges), o którym trzeba było powiadomić administratorów | Tak | Przerysowana |
| Przypisanie lub zmiana przypisania | Nie | Przerysowana |

> [!WARNING]
> **Eskalacja to odpowiedź w wątku, więc nie pojawia się w treści kanału.** Nikt, kto nie obserwuje już tego wątku, jej nie zobaczy. Nie licz na to, że kanał przerwie komuś pracę z powodu znaleziska Critical — tym, co naprawdę wzywa człowieka, jest [rotacja dyżurów](/docs/on-call-rotation): alarmuje osobę dyżurującą DM-em lub e-mailem, gdy zgłoszenie o poziomie ważności wyzwalającym eskalację zostaje zwalidowane.

Odpowiedzi są celowo zwykłym tekstem, a nie kartami. Czyta się je w wątku pod kartą, która i tak niesie tytuł, poziom ważności, status i linki — powtarzanie tej struktury zrobiłoby z wątku coś nieczytelnego. Odpowiedź o statusie zawiera przejście (`Submitted → Validated`), autora zmiany oraz jego komentarz, jeśli go zostawił, przycięty tak, żeby wklejony stack trace nie zamienił się w ścianę tekstu.

Każde zdarzenie publikuje **najwyżej jedną** odpowiedź, niezależnie od tego, ile razy job zostanie ponowiony. Kit wiąże każdą odpowiedź z rekordem źródłowym — przejściem statusu, odwołaniem, wypłatą — więc ponowienie zastaje odpowiedź już na miejscu.

## Zgłoszenia z ograniczonym dostępem nigdy nie trafiają do Slacka

[Zgłoszenie z ograniczonym dostępem](/docs/per-item-access-grants) **nie dostaje ani karty, ani wątku** — nie dostaje też wersji ocenzurowanej.

> [!WARNING]
> **Grono odbiorców kanału Slack nie jest granicą kontroli dostępu.** Na kanałach siedzą goście wielokanałowi i członkowie Slack Connect z innych firm; kartę opublikowaną dziś nadal przeczyta ktoś, kto jutro zostanie odłączony od Kit. Przy zgłoszeniu z ograniczonym dostępem tajemnicą jest tytuł, poziom ważności i sam fakt, że takie zgłoszenie istnieje — dlatego Kit nie publikuje nic, zamiast publikować ocenzurowaną kartę.

Jeśli zgłoszenie zostanie objęte ograniczeniem **po** opublikowaniu wątku, Kit go wycofuje:

- Karta główna zostaje zredukowana do neutralnej zaślepki — bez tytułu, bez poziomu ważności, bez ID, bez linku. Kanał dowiaduje się, że rozmowa przeniosła się do Kit, a nie czego dotyczyła.
- Własne odpowiedzi Kit w wątku są usuwane.
- Sama wiadomość główna nigdy nie jest usuwana, bo jej usunięcie osierociłoby wątek.
- Odpowiedzi napisane przez Twoich współpracowników **nie** są usuwane. To ich własne słowa, a nie dane, które umieścił tam Kit — Kit nie może ich usunąć i tego nie robi.

Zdjęcie ograniczenia wypełnia tę samą kartę główną z powrotem, w miejscu. Nic nie jest odtwarzane: odpowiedzi usunięte przy nakładaniu ograniczenia pozostają usunięte.

## Tożsamość badacza na kanale

Zanim karta kogokolwiek nazwie po imieniu, sprawdza [preferencje wyróżnienia](/docs/the-researcher-portal#hall-of-fame) badacza — to samo ustawienie, które rządzi Twoim publicznym Hall of Fame.

> [!IMPORTANT]
> **Odmowa obowiązuje także w Slacku.** Badacz, który wybrał **Anonimowo** lub **Poza listą**, jest na karcie pokazywany jako anonimowy nawet wtedy, gdy Kit zna jego imię, nazwisko i pseudonim. Jego odmowa nie ogranicza się do publicznego Hall of Fame; obejmuje każde grono szersze niż samo zgłoszenie, a kanał Slack — goście, członkowie Slack Connect z innych firm — jest dokładnie takim gronem.

**Adres e-mail badacza nigdy nie pojawia się na karcie**, niezależnie od jego preferencji. Ta sama zasada obowiązuje w podglądach linków Kit w Slacku, gdy ktoś z zespołu wkleja na kanał adres URL zgłoszenia, oraz w tym, co dostaje do dyspozycji KitBot.

## Na jaki kanał trafia karta

Karta trafia na ten kanał, na który Twoje konto kieruje **New vulnerability report submitted** (Nowe przesłane zgłoszenie), rozstrzygane zwykłą kolejnością: najpierw dokładnie to przeznaczenie, potem **All VDP notifications** (Wszystkie powiadomienia VDP), potem **All notifications** (Wszystkie powiadomienia). Skonfigurujesz to w [Integracje → Slack](/integrations/slack/connections).

Dwie konsekwencje warte zapamiętania:

- **Wątek może być tylko w jednym miejscu.** Jeśli do tego samego przeznaczenia skierowanych jest kilka kanałów, karta trafia na jeden z nich, a nie na wszystkie.
- **Gdy karta już istnieje, jej kanał wygrywa.** Późniejsza zmiana kierowania przenosi tylko to, gdzie lądują *nowe* zgłoszenia; nigdy nie przenosi żywego wątku.

Pieniądze mają osobny tor. Jeśli skierujesz **Bounty approved** lub **Disbursement completed** na *inny* kanał — jakiś `#finance`, który nie powinien widzieć całego strumienia bezpieczeństwa — ten kanał i tak dostanie własny, samodzielny wpis, oprócz odpowiedzi w wątku. Jeśli kierowanie wskazuje ten sam kanał, na którym jest karta, jedynym wpisem jest odpowiedź w wątku: bez duplikatu.

## Pytanie KitBota w wątku

Ponieważ początek wątku *jest* zgłoszeniem, wspomnienie **@KitBot** w dowolnym miejscu tego wątku trafia w to zgłoszenie bez zgadywania — status, oś czasu, stan SLA, sprawdzenie duplikatów, kontekst poziomu ważności, porównania nagrody. Zobacz [Korzystanie z @KitBot w Slacku](/docs/using-kitbot-in-slack).

### Jedyna rzecz, którą potrafi zapisać

Poproś KitBota, żeby **podsumował dyskusję**, **zapisał decyzję** albo **zanotował ustalenia**, a to, co napisze, zapisze jako **notatkę wewnętrzną** przy tym zgłoszeniu — pod *Twoim* nazwiskiem, bo to Ty go o to prosisz. Potwierdzi to w wątku, dorzucając link prowadzący prosto do notatki w Kicie. Jeśli nie napisał, że zapisał, i nie podał linku — nic nie zostało zapisane.

Oznacz go w dowolnym miejscu wątku i powiedz, co ma zapisać:

```
@KitBot summarise this discussion as an internal note
@KitBot note that we're waiting on the researcher's PoC video
@KitBot record the decision: duplicate of the March report, not paying twice
@KitBot save a note with the repro steps we agreed on above
```

Zwykłe pytania działają dokładnie tak samo — `@KitBot what's the SLA on this?`. KitBot zapisuje coś tylko wtedy, gdy wyraźnie go o to poprosisz.

> [!IMPORTANT]
> **Notatka napisana przez KitBota nigdy nie dotrze do badacza.** Narzędzie, którym bot dysponuje w Slacku, nie ma jak wyrazić wiadomości zewnętrznej — to nie jest „prosimy, nie rób tego” w jego instrukcjach, tylko narzędzie, które takiego ustawienia w ogóle nie ma. Cokolwiek pojawi się w wątku, cokolwiek próbowałby mu wmówić tekst zgłoszenia, jedyne, co może powstać, to notatka widoczna wyłącznie dla zespołu, przy tym zgłoszeniu, którego dotyczy wątek.

Są jeszcze dwie rzeczy, których nie potrafi:

- **Nie wybiera, do którego zgłoszenia pisze.** Notatka trafia zawsze do tego zgłoszenia, którego karta rozpoczyna wątek, a ustala się to, zanim KitBot przeczyta choćby słowo. Żaden tekst w wątku — również taki, który napisał badacz — nie skieruje notatki do innego zgłoszenia.
- **Nie zapisuje niczego poza wątkiem zgłoszenia.** Wspomnij KitBota na zwykłym kanale, a nie ma tam w ogóle narzędzia do notatek; poprosi, żeby zadać to pytanie ponownie w wątku samego zgłoszenia.

Notatki zapisane przez KitBota to zwykłe notatki wewnętrzne: pojawiają się w zakładce **Rozmowa** zgłoszenia, a każdy, kto ma dostęp, może je edytować albo usunąć.

Jedną rzecz KitBot celowo zniekształca: [link do udostępnienia współpracownikowi](/docs/sharing-reports-with-peers). Każdy, kto ma taki adres, może uruchomić proces udostępniania dla zgłoszenia, do którego nigdy nie dostał dostępu, więc jeśli taki link pojawi się w wątku, KitBot go nie powtórzy: i w odpowiedzi, i w notatce token wraca jako `…`. Link nadal działa u osoby, do której został wysłany; KitBot po prostu nie chce być tym, kto go rozpowszechnia.

### Czego nadal nie potrafi

Cała reszta pozostaje w trybie tylko do odczytu. KitBot nie potrafi triażować, ocenić, przypisać ani odrzucić zgłoszenia; nie napisze do badacza ani nie wyśle mu e-maila; nie zatwierdzi ani nie skoryguje nagrody; nie zmieni ustawień Twojego programu. Poproś go o którąkolwiek z tych rzeczy, a odeśle Cię do strony zgłoszenia w Kicie.

Zapisanie notatki podlega też Twoim własnym uprawnieniom — jeśli Twoje konto w Kicie nie ma roli administratora CSIRT, KitBot powie o tym wprost i podpowie, kogo o to poprosić, zamiast po cichu nic nie zrobić.

Jeśli wspomnisz go w wątku zgłoszenia, którego nie masz prawa widzieć, po cichu odpowie zamiast tego na pytania dotyczące całego programu — nigdy nie potwierdzi, że takie zgłoszenie istnieje, i nie dostaje żadnej możliwości, żeby cokolwiek do niego zapisać.

## W skrócie

- [ ] Skieruj **New vulnerability report submitted** (albo **All VDP notifications**) na ten jeden kanał, który Twój zespół bezpieczeństwa naprawdę czyta
- [ ] Obserwuj wątek zgłoszenia, jeśli chcesz dostawać powiadomienia o jego zmianach — edycje karty są ciche
- [ ] Wypróbuj `@KitBot summarise this discussion as an internal note` w wątku zgłoszenia — potwierdzenie zawiera link prowadzący prosto do notatki w Kicie
- [ ] Kieruj **Bounty approved** na `#finance` tylko wtedy, gdy chcesz mieć tam osobny wpis
- [ ] Ogranicz dostęp do wrażliwego zgłoszenia możliwie wcześnie — nałożenie ograniczenia na już opublikowane zostawia na kanale zaślepkę zamiast niczego
- [ ] Sprawdź, kto naprawdę jest na Twoim kanale VDP: goście i członkowie Slack Connect widzą każdą kartę na tym kanale