Integracja z Jira

Dlaczego to ważne

Osoby, które triażują zgłoszenie podatności, prawie nigdy nie są tymi, które je naprawiają. Triaż dzieje się w Kit, naprawa na tablicy zespołu inżynierskiego. Bez powiązania między nimi ktoś ręcznie przekleja zgłoszenie do Jira i od tego momentu oba systemy się rozjeżdżają. Ticket pokazuje „In Review”, zgłoszenie „Validated”, nikt nie umie odpowiedzieć, czy podatność faktycznie jest naprawiona, a badacz czeka.

Połączenie z Jira zamyka ten obieg. Jedno kliknięcie w zgłoszeniu tworzy ticket dla zespołu inżynierskiego, a powiązanie między nimi to prawdziwy rekord utrzymywany przez Kit, a nie adres URL wklejony przez kogoś w komentarzu.

Rozwiązuje też mniej oczywisty problem. Ręczne przeklejanie zwykle przenosi wszystko, łącznie z krokami reprodukcji i adresem e-mail badacza, do projektu, którego faktycznego kręgu odbiorców nikt nie sprawdził. Integracja w Kit wysyła zamiast tego świadomie okrojony ticket.

Czego potrzebujesz

• Konto Kit z włączonym dodatkiem VDP
• Instancja Jira Cloud (Jira Data Center i Jira Server nie są obsługiwane)
• Konto Atlassian z dostępem do docelowego projektu
• Uprawnienia administratora modułu w Kit — podłączenie trackera to decyzja na poziomie całej organizacji

Konfiguracja

1. Połącz swoje konto Atlassian

1. Wejdź na VDP > Ustawienia > Tracker ticketów
2. Kliknij Połącz z Jira
3. Zaloguj się do Atlassian i zatwierdź żądany dostęp
4. Wskaż instancję Jira, której chcesz używać, jeśli twoje konto Atlassian ma ich więcej niż jedną

Zgoda należy do osoby, która jej udzieliła. Kit zapisuje, kto to był, bo kiedy ta osoba odejdzie z organizacji, połączenie przestanie działać i trzeba wiedzieć, czyj dostęp odnowić.

2. Wybierz projekt i typ ticketu

1. Na stronie ustawień kliknij Wybierz projekt
2. Wskaż projekt, do którego ma trafiać praca nad podatnościami
3. Wybierz typ ticketu, z jakim będą tworzone nowe tickety (zwykle Bug lub Task)

Kit odczytuje przy tym typ projektu. Jeśli jest to projekt Jira Service Management, komentarze o zmianach statusu są domyślnie wyłączone: JSM wymusza, żeby komentarze tworzone przez API platformy były publiczne, więc zobaczyliby je zewnętrzni zgłaszający z twojego service desku.

Kit odczytuje też nazwy priorytetów, jakie przyjmuje wybrany projekt i typ ticketu, i mapuje na nie poziomy ważności zgłoszeń (krytyczny → Highest, wysoki → High i tak dalej). Warto znać dwa przypadki, a strona ustawień informuje, kiedy któryś z nich zachodzi:

• Twój projekt ma własne nazwy priorytetów albo działa w języku innym niż angielski. Kit nie wymyśli priorytetu, którego nie umie dopasować, więc takie zgłoszenia trafią do Jira z domyślnym priorytetem projektu. Poziom ważności i tak zawsze trafia do opisu ticketu.
• Twój projekt nie ma pola priorytetu na ekranie tworzenia, co często zdarza się w projektach zarządzanych przez zespół. Kit nie wysyła wtedy żadnego priorytetu.

Żeby samodzielnie zarządzać mapowaniem, ustaw na połączeniu nadpisanie priority_map — na razie nie ma na to ekranu.

3. Potwierdź, że działa

Kliknij Przetestuj połączenie. Kit wysyła uwierzytelnione zapytanie do twojej instancji i pokazuje wynik.

Przesyłanie zgłoszenia

Otwórz dowolne zgłoszenie. W prawej kolumnie znajdziesz kartę Tracker ticketów.

1. Kliknij Utwórz ticket
2. Przeczytaj panel z informacją, co zostanie wysłane, a co zostaje w Kit
3. Kliknij Utwórz ticket

Na czas tworzenia ticketu karta pokazuje wskaźnik postępu, a potem klucz ticketu, jego status i link otwierający Jira w nowej karcie.

Może to zrobić każdy członek zespołu, który ma wgląd w zgłoszenie. To zwykła czynność triażowa, na tym samym poziomie uprawnień co dodanie linku. Tylko konfiguracja połączenia jest zarezerwowana dla administratora.

Co opuszcza Kit

Ten fragment warto przeczytać uważnie. Domyślnie wysłany ticket jest okrojony: zawiera tyle, ile inżynier potrzebuje, żeby zaplanować pracę, i nic ponadto.

Trafia do Jira	Zostaje w Kit
Tytuł zgłoszenia i jego identyfikator w Kit	Opis podatności
Poziom ważności i wynik CVSS	Kroki reprodukcji
Typ podatności	Endpoint, którego dotyczy
Obszar produktu	Pliki proof of concept i zrzuty ekranu
Termin naprawy	Imię i nazwisko, adres e-mail oraz dane do wypłaty badacza
Link zwrotny do zgłoszenia w Kit	Notatki wewnętrzne i wątek rozmowy

Nie chodzi o ostrożność dla samej ostrożności. Z poziomu Kit nie da się ustalić, kto naprawdę ma wgląd w Jira: uprawnienia do projektu nadane całej organizacji, aplikacje z Atlassian Marketplace z prawem odczytu ticketów, eksporty CSV, kopie zapasowe przechowywane dłużej niż sam ticket. Pola, których Kit nie wysyła, to dokładnie te, które szyfruje w spoczynku, więc ich przesłanie przeniosłoby najlepiej chronione dane do systemu, nad którym masz najmniejszą kontrolę.

Tożsamości badacza ani kwot nagród nie da się włączyć żadnym przełącznikiem. Brak takiej opcji jest właśnie gwarancją.

Udostępnianie pełnych szczegółów mimo wszystko

Niektóre zespoły jednak chcą mieć opis w tickecie. Wymaga to przejścia dwóch niezależnych zabezpieczeń:

1. Administrator włącza Zezwól na pełne szczegóły podatności w VDP > Ustawienia > Tracker ticketów
2. Osoba przesyłająca zgłoszenie zaznacza pole wyboru przy tym konkretnym tickecie

Oba są domyślnie wyłączone. Przy wyłączonym ustawieniu na poziomie programu pola wyboru w ogóle się nie pokazują, a ręcznie spreparowane zapytanie ich nie obejdzie: Kit sprawdza ustawienie programu ponownie w momencie budowania danych do wysyłki.

Dołączony tekst zgłoszenia trafia do bloku kodu, więc Jira wyświetla go dokładnie tak, jak napisał go badacz, zamiast interpretować jako znaczniki.

Status naprawy

Karta pokazuje własną etykietę statusu ticketu, w brzmieniu z twojej tablicy („In Review”, „Ready for QA”), bo dokładnie to widzi inżynier. Wewnętrznie Kit mapuje ją na jeden z pięciu stanów: „Nierozpoczęte”, „W toku”, „Naprawione”, „Nie zostanie naprawione” i „Nieznany”. Opiera się przy tym na stałych kategoriach statusów w Jira, a nie na ich nazwach, więc nie trzeba mapować workflow osobno dla każdego projektu.

Kit nigdy nie rozwiązuje zgłoszenia tylko dlatego, że w Jira pojawiło się „Done”. Na tablicy inżynierskiej „Done” regularnie znaczy „scalone, ale nie wdrożone”, a rozwiązanie zgłoszenia pociąga za sobą skutki, których osoba przeciągająca kartę wcale nie musi mieć na myśli: badacz dostaje powiadomienie, otwiera się proces wypłaty nagrody, ruszają liczniki ujawnienia. Kit pokazuje ukończony ticket, a decyzję zostawia człowiekowi.

Odpinanie i ponowne próby

• Odepnij usuwa powiązanie wyłącznie po stronie Kit. Ticket zostaje w Jira, gdzie może już mieć komentarze inżynierów i gałąź z poprawką. Tam Kit nie jest systemem źródłowym.
• Spróbuj ponownie powtarza nieudane wysłanie. Można nacisnąć dwa razy bez obaw: Kit oznacza każdy ticket unikalnym kluczem i szuka tego oznaczenia, zanim cokolwiek utworzy. Jeśli zapytanie przekroczyło limit czasu już po tym, jak Jira utworzyła ticket, Kit podłączy istniejący zamiast tworzyć drugi.
• Rozłączenie integracji usuwa przechowywaną w Kit zgodę i powiązane z nią wpisy. Wszystkie utworzone wcześniej tickety zostają w Jira.

Rozwiązywanie problemów

Objaw	Przyczyna	Rozwiązanie
„Dostęp do Jira został cofnięty”	Zgoda została cofnięta w Atlassian albo autoryzujący użytkownik został dezaktywowany	Połącz ponownie na stronie ustawień; autoryzacji może udzielić inny administrator
„Ten projekt nie ma żadnego typu ticketu, którego dałoby się użyć”	Projekt udostępnia wyłącznie typy podzadań	Wybierz inny projekt albo dodaj w Jira standardowy typ ticketu
Ticket został odrzucony z powodu pola	Wymagane pole niestandardowe, którego okrojony ticket nie wypełnia	Sprawdź błąd pokazany na karcie, a potem zmień konfigurację pól w projekcie tak, żeby to pole było opcjonalne przy tworzeniu
Nie widać przycisku Utwórz ticket	Żaden tracker nie jest połączony albo dodatek VDP jest nieaktywny	Połącz tracker w VDP > Ustawienia > Tracker ticketów

Checklist

• Dodatek VDP aktywny na koncie
• Konto Atlassian połączone i wiadomo, kto udzielił autoryzacji
• Wybrany docelowy projekt i typ ticketu
• Test połączenia kończy się powodzeniem
• Strona ustawień sprawdzona pod kątem komunikatu o mapowaniu priorytetów w wybranym projekcie
• Świadoma decyzja, czy pełne szczegóły podatności mogą być udostępniane
• Przy projekcie Jira Service Management potwierdzone, że komentarze o zmianach statusu są wyłączone