## Po co to?

W małym programie jedna osoba triażuje wszystkie zgłoszenia. W miarę jak program rośnie, pojedyncza kolejka staje się wąskim gardłem: błąd w Payments i błąd w aplikacji mobilnej trafiają na ten sam stos, a właściwy inżynier zobaczy zgłoszenie tylko wtedy, gdy ktoś pamięta, żeby go do niego dopisać.

Rozwiązuje to **katalog komponentów**. Obszary produktu opisujesz raz — „Payments API", „Mobile App", „Marketing Site" — a Kit dla każdego napływającego zgłoszenia sugeruje obszar, który je obejmuje, przekazuje własność domyślnej osobie odpowiedzialnej za ten obszar i pinguje kanał Slack odpowiedniego zespołu, gdy zgłoszenie zostanie zweryfikowane. Kierowanie działa w miarę możliwości i zawsze wymaga potwierdzenia przez człowieka: Kit proponuje, twój zespół decyduje.

> [!NOTE]
> Komponenty są całkowicie opcjonalne. Bez nich zgłoszenia działają dokładnie tak jak wcześniej — zyskujesz jedynie kierowanie. Zacznij od dwóch–trzech obszarów, które odpowiadają wyraźnym granicom zespołów, i dodawaj kolejne w miarę potrzeb.

## Czym jest komponent

**Komponent** to wpis w katalogu danego programu, opisujący jeden obszar produktu w ramach twojego programu ujawniania podatności (VDP). Każdy komponent niesie ze sobą cztery rzeczy:

| Pole | Do czego służy |
|-------|---------|
| **Nazwa** | Etykieta obszaru pokazywana na zgłoszeniach i w Slacku (np. `Payments API`). Wymagana. |
| **Opis** | Krótkie podsumowanie tego, co obejmuje dany obszar. Klasyfikator AI czyta go, gdy decyduje, do którego obszaru pasuje niejednoznaczne zgłoszenie — więc niech będzie konkretny. |
| **Maski adresów URL (globy)** | Globy adresów URL dopasowywane do punktu końcowego, którego dotyczy zgłoszenie (zobacz [Maski adresów URL (globy)](#maski-adresów-url-globy) poniżej). |
| **Kanał Slack** | Kanał odpowiedniego zespołu. Otrzymuje powiadomienie „Przejmij" (Take it over), gdy skierowane zgłoszenie zostanie zweryfikowane. |
| **Domyślna osoba odpowiedzialna** | Członek zespołu, który automatycznie przejmuje na własność zgłoszenia skierowane do tego obszaru, o ile zgłoszenie nie ma jeszcze przypisanej osoby. |

Obowiązkowa jest tylko nazwa. Komponent z samą nazwą nadal działa jako ręczna etykieta; dodaj maski adresów URL, kanał i osobę odpowiedzialną, żeby odblokować automatyczne sugestie i kierowanie.

## Konfigurowanie komponentów

Otwórz [VDP > Ustawienia programu > Komponenty](/csirt/program/components). Zakładka Komponenty to katalog — tutaj dodajesz, edytujesz i archiwizujesz obszary produktu.

Żeby dodać komponent, kliknij **Nowy komponent**, wypełnij pola i zapisz:

- [ ] Nadaj obszarowi jasną **nazwę** i konkretny **opis**
- [ ] Dodaj jedną lub więcej **masek adresów URL**, po jednym globie w wierszu
- [ ] Wybierz **kanał Slack** odpowiedniego zespołu (opcjonalnie)
- [ ] Wybierz **domyślną osobę odpowiedzialną** (opcjonalnie)

Nowi subskrybenci VDP widzą też opcjonalny krok **„Skonfiguruj obszary produktu"** podczas wdrożenia. Możesz go wtedy wykonać albo pominąć i zbudować katalog później — nic innego od niego nie zależy.

## Maski adresów URL (globy)

Maski adresów URL to globy adresów URL, po jednym w wierszu, dopasowywane do **punktu końcowego, którego dotyczy zgłoszenie**, podanego przez badacza w zgłoszeniu. Napędzają deterministyczną połowę kierowania: jeśli punkt końcowy ze zgłoszenia pasuje do masek dokładnie jednego komponentu, ten komponent wygrywa bez dyskusji.

Jedna reguła, na której wszyscy się potykają: **maska bez `*` na początku jest zakotwiczona na początku punktu końcowego.** Ponieważ punkty końcowe to zwykle pełne adresy URL zaczynające się od `https://`, prawie zawsze warto owinąć istotną część w `*`, żeby dopasowanie działało jak podciąg.

Dopasowanie **nie rozróżnia wielkości liter**, a `*` obejmuje również `/`, więc `*pay*` to prawdziwe dopasowanie podciągu.

Dla punktu końcowego `https://app.example.com/api/pay/charge`:

| Maska | Pasuje? | Dlaczego |
|---------|:--------:|-----|
| `*pay*` | ✅ | `*` na początku i na końcu — dopasowuje „pay" w dowolnym miejscu ciągu |
| `*/api/pay/*` | ✅ | Wieloznaczniki po obu stronach dopasowują ten segment ścieżki, gdziekolwiek się pojawi |
| `https://app.example.com/*` | ✅ | Brak `*` na początku, ale punkt końcowy zaczyna się dokładnie od tego tekstu |
| `app.example.com/*` | ❌ | Zakotwiczona na początku — ale punkt końcowy zaczyna się od `https://`, a nie `app.` |
| `/api/pay/charge` | ❌ | Zakotwiczona na początku — punkt końcowy nie zaczyna się od `/api/…` |

> [!TIP]
> W razie wątpliwości owiń charakterystyczną część ścieżki w `*`: `*payments*` lub `*/api/pay/*`. Maski zakotwiczone na początku (`https://…/*`) zostaw na sytuacje, gdy celowo chcesz dopasować jeden konkretny host od pierwszego znaku.

## Jak działa kierowanie

Kierowanie **tylko sugeruje**. Kit nigdy po cichu nie przypisuje zgłoszenia ponownie — każdy z poniższych kroków pokazuje sugestię, którą twój zespół potwierdza.

### 1. Kit sugeruje obszar

Gdy zgłoszenie trafia do systemu, Kit wybiera komponent-kandydata w dwóch etapach:

1. **Dopasowanie deterministyczne** — jeśli punkt końcowy ze zgłoszenia pasuje do masek adresów URL dokładnie jednego komponentu, jest to jednoznaczne dopasowanie z pełną pewnością.
2. **Klasyfikator AI** — jeśli maski nie pasują do niczego albo niejednoznacznie pasują do dwóch lub więcej komponentów, klasyfikator AI zestawia zgłoszenie z opisami twoich komponentów i proponuje najlepsze dopasowanie albo `none`.

Kit pokazuje sugestię tylko wtedy, gdy jest wystarczająco pewny. Jeśli nic nie pasuje, zgłoszenie po prostu trafia bez sugerowanego obszaru — kierowanie nigdy nie blokuje ani nie opóźnia przyjęcia zgłoszenia.

### 2. Zespół potwierdza obszar

Na stronie zgłoszenia w panelu bocznym widać kartę **„Obszar / odpowiedzialny zespół"**. Gdy Kit ma sugestię, pojawia się ona jako **„Sugerowany obszar"** z procentem pewności i jednozdaniowym uzasadnieniem. Twój zespół może wtedy:

- **Zaakceptować** sugestię,
- **wybrać inny obszar** z listy,
- albo zostawić pole puste.

Zaakceptowanie komponentu ustawia obszar zgłoszenia **oraz**, jeśli komponent ma domyślną osobę odpowiedzialną, przypisuje tę osobę jako właściciela zgłoszenia (chyba że ma ono już właściciela). Obszar możesz w każdej chwili wyczyścić lub zmienić z tej samej karty.

### 3. Odpowiedzialny zespół dostaje ping

Gdy skierowane zgłoszenie zostanie **zweryfikowane** (przejdzie triaż — zobacz [Triaż zgłoszeń](/docs/triaging-reports)), a jego komponent ma przypisany kanał Slack, Kit publikuje na tym kanale kartę powiadomienia z przyciskiem **„Przejmij"** (Take it over). Dowolny członek zespołu może go kliknąć, żeby przejąć zgłoszenie i zostać jego właścicielem. Ping wysyła się dokładnie raz na zgłoszenie, więc ponowna weryfikacja czy zmiana przypisania nie zaśmieci kanału.

> [!NOTE]
> Ping w Slacku wysyła się dopiero po weryfikacji, a nie przy przyjęciu zgłoszenia — dzięki temu kanał zespołu pozostaje cichy, dopóki zgłoszenie nie zostanie potwierdzone jako prawdziwe i mieszczące się w zakresie. Slack skonfigurujesz w [Ustawienia konta > Integracje](/integrations).

## Dobre i złe praktyki

| Rób tak | Nie rób tak |
|----|-------|
| Owijaj istotną część ścieżki w `*` (`*payments*`) | Pomijaj `*` na początku i licz na dopasowanie podciągu |
| Pisz konkretne opisy — klasyfikator AI je czyta | Polegaj wyłącznie na maskach adresów URL przy obszarach o rozmytych granicach URL |
| Traktuj każdą sugestię jako propozycję do potwierdzenia | Zakładaj, że sugerowany obszar jest już przypisany — nie jest, dopóki go nie zaakceptujesz |
| Ustawiaj domyślną osobę odpowiedzialną dla obszarów z jasnym właścicielem | Kieruj komponent na kanał Slack, do którego Kit nie należy |
| Archiwizuj obszary, które wycofujesz | Usuwaj historię — archiwizacja ją zachowuje |

## Zarządzanie przez narzędzia MCP

Katalog jest też dostępny dla agentów AI i klientów API poprzez [narzędzia MCP](/docs/ai-integration-vdp), więc możesz budować katalog i kierować zgłoszenia programowo:

- `csirt_list_components` — wyświetla katalog (odczyt)
- `csirt_create_component` / `csirt_update_component` — dodaje lub edytuje obszar (zapis)
- `csirt_archive_component` — wycofuje obszar (zapis)
- `csirt_assign_component` — ustawia, czyści lub **pyta o** sugerowany obszar na zgłoszeniu. Pomiń id komponentu, żeby dostać sugestię deterministyczną/AI bez wprowadzania zmian, a potem wywołaj ponownie z sugerowanym id, żeby ją potwierdzić.

Narzędzia zapisu wymagają zakresu `csirt_write` i zawsze proszą o potwierdzenie przed działaniem, odwzorowując znany z interfejsu przepływ „najpierw sugestia, potem potwierdzenie". Pełną dokumentację narzędzi i konfigurację połączenia znajdziesz w [Integracja z AI](/docs/ai-integration-vdp).

## Archiwizowanie komponentu

Żeby wycofać obszar, kliknij **Archiwizuj** w zakładce Komponenty. Archiwizacja to miękkie usunięcie:

- Zgłoszenia już skierowane do komponentu **zachowują swoją historię** — obszar nadal jest widoczny na tych zgłoszeniach.
- Nowe zgłoszenia **przestają być do niego kierowane** — znika z sugestii i z listy wyboru.

To bezpieczny sposób na wygaszenie obszaru produktu bez przepisywania przeszłości. Interfejs nie pozwala na trwałe usunięcie; archiwizacja jest celowo bezpieczna i odwracalna, a nie destrukcyjna.

## W skrócie

- [ ] Utwórz komponent dla każdego obszaru produktu o wyraźnej granicy zespołu
- [ ] Napisz konkretny opis — klasyfikator AI na nim polega
- [ ] Dodaj maski adresów URL, owijając charakterystyczną ścieżkę w `*` (np. `*payments*`)
- [ ] Ustaw kanał Slack, żeby odpowiedzialny zespół dostawał ping „Przejmij" (Take it over)
- [ ] Ustaw domyślną osobę odpowiedzialną dla obszarów z jasnym właścicielem
- [ ] Przy nowych zgłoszeniach potwierdzaj lub zmieniaj sugerowany obszar w karcie panelu bocznego
- [ ] Archiwizuj wycofywane obszary zamiast je usuwać

## Co dalej

- [Triaż zgłoszeń](/docs/triaging-reports) — tablica triażu, wskaźniki SLA i krok weryfikacji, który wyzwala powiadomienia zespołów
- [Konfigurowanie programu](/docs/configuring-your-program) — zakres, SLA, matryca nagród i reszta ustawień programu
- [Integracja z AI](/docs/ai-integration-vdp) — pełny zestaw narzędzi MCP, w tym narzędzia katalogu komponentów