Triaż AI z dostępem do kodu

Co analizuje agent

Screening AI ocenia treść zgłoszenia. Agent z dostępem do kodu może dodatkowo spróbować odtworzyć błąd, ocenić możliwość jego wykorzystania, znaleźć odpowiednie miejsca w repozytorium oraz zaproponować CVSS i poprawkę.

Najważniejsza różnica dla osoby odpowiedzialnej za AppSec: agent należy do ciebie, nie do Kit. Działa w twoim GitLab CI, analizuje twój kod i korzysta z twojego modelu. Domyślnie jest to DeepSeek, ale może nim być dowolny endpoint zgodny z Anthropic, w tym lokalny vLLM, Ollama, OpenRouter albo sam Anthropic. Kit nie pobiera repozytorium ani nie uruchamia tego modelu. Otrzymuje wynik analizy, który może zawierać fragmenty kodu i proponowaną poprawkę. Zapewniamy proces przyjmowania zgłoszeń, wykrywania duplikatów, wypłat, SLA i komunikacji z badaczami, a także rejestr zmian oraz stabilny kontrakt, do którego podłączasz własnego agenta.

Reguły sieciowe mają blokować połączenia inicjowane przez złośliwe instrukcje w zgłoszeniu. Są egzekwowane poza agentem i dopuszczają tylko endpoint modelu oraz MCP Kit. Dane nadal trafiają do tych dwóch dozwolonych odbiorców. Model bezpieczeństwa opisuje Jak działa izolacja sieciowa.

Jak działa cykl

Po wysłaniu zgłoszenia przez badacza Kit uruchamia pipeline w twoim forku przykładowego repozytorium. Runner CI wykonuje resztę i odsyła wynik do zgłoszenia.

Krok	Gdzie	Co się dzieje
1. Wysłanie zgłoszenia	Kit	Badacz wysyła zgłoszenie VDP. Kit tworzy przebieg triażu o statusie pending.
2. Uruchomienie pipeline	Kit → GitLab	Kit wywołuje API triggera pipeline w twoim forku i przekazuje identyfikator zgłoszenia, ograniczony adres MCP oraz krótkotrwały token jako zmienne CI.
3. Praca agenta	Twój GitLab CI	Runner pobiera kod, odczytuje zgłoszenie przez ograniczony token MCP, skanuje repozytorium i tworzy wynik triażu bez dostępu do sieci poza endpointem modelu i hostem MCP Kit.
4. Odesłanie wyniku	Twój agent → Kit	Agent sprawdza wynik względem schematu i wysyła go przez POST z tym samym ograniczonym tokenem. Panel triażu w zgłoszeniu aktualizuje się na żywo.

Cały cykl zwykle trwa 2–5 minut. Czas zależy m.in. od uruchomienia runnera i pracy modelu. Podczas pracy CI na stronie zgłoszenia widać aktualizowany status.

Co tworzy agent

Agent zwraca ocenę, którą inżynier może sprawdzić przed dalszym triażem. Kit pokazuje ją w osobnym panelu Triaż z dostępem do kodu na karcie Szczegóły zgłoszenia, bezpośrednio pod kartą Screeningu AI:

• Odtworzono: tak, nie albo częściowo wraz z uzasadnieniem agenta.
• Możliwość wykorzystania: prosty opis, jak realne jest wykorzystanie podatności.
• Sugerowana ważność i wektor CVSS: obok samooceny badacza, żeby od razu było widać różnicę („Badacz: Critical · Twój agent: High”).
• Miejsca w kodzie, których dotyczy problem: path:line → function() z linkami do odpowiednich plików w repozytorium GitLab.
• Wykrywanie duplikatów: zestawione z własnym mechanizmem Kit opartym na embeddingach. Jeśli oba wyniki są zgodne, zobaczysz jeden wspólny baner.
• Sugerowana poprawka: opis, a jeśli agent potrafi ją przygotować, także diff w zwijanej sekcji z kopiowaniem do schowka. Nigdy nie jest stosowana automatycznie.

Przycisk [Użyj CVSS agenta →] wypełnia formularz oceny, ale nadal wysyła go człowiek.

Przykładowe repozytorium

Agent znajduje się w otwartym repozytorium, które możesz sforkować i dostosować:

[email protected]:startupkit/vdp-ai-triage-example.git

To referencyjna implementacja stabilnego kontraktu, a nie usługa zarządzana. Po utworzeniu forka kontrolujesz prompt (agent/prompts/triage.md), model, zasady sieciowe i schemat wyniku. Repozytorium zawiera:

• .gitlab-ci.yml, który odbiera zmienne triggera, uruchamia agenta z ograniczonym dostępem do sieci i odsyła wynik triażu;
• tryb mock / --dry-run, dzięki któremu pipeline przechodzi dla przykładowego zgłoszenia przed konfiguracją prawdziwego klucza modelu czy połączenia z Kit;
• przykładowe zgłoszenie z kanarkiem prompt injection próbującym wywołać zewnętrzny host przez curl, żeby sprawdzić, czy reguły ruchu wychodzącego blokują tę próbę.

Widoczne statusy

Status	Znaczenie
Pending / Running	Przebieg oczekuje na rozpoczęcie albo już trwa. Panel pokazuje szkielet oraz aktualizowany status.
Completed	Wynik triażu dotarł i został wyświetlony.
Failed	Pipeline zakończył się błędem albo agent nie utworzył poprawnego wyniku. Panel pokazuje konkretny błąd z linkami do pipeline i ponownego uruchomienia.
Timed out	Agent nie odpowiedział w wyznaczonym czasie, domyślnie 15 minut. Panel pokazuje błąd z tymi samymi informacjami.

Przebieg zakończony błędem albo przekroczeniem limitu czasu nigdy nie blokuje zgłoszenia. Triaż jest tylko wskazówką, więc zgłoszenie pozostaje w kolejce dokładnie tak, jak bez agenta.

Lista kontrolna

• Przeczytaj Jak działa izolacja sieciowa, zanim cokolwiek podłączysz
• Sforkuj vdp-ai-triage-example i uruchom pipeline z --dry-run dla przykładowego zgłoszenia; powinien przejść bez połączenia z Kit i klucza modelu
• Skonfiguruj endpoint modelu, domyślnie DeepSeek, i powtórz przebieg z prawdziwym triażem
• Postępuj zgodnie z Konfiguracją izolowanego agenta triażu, żeby połączyć go z Kit
• Dostosuj agent/prompts/triage.md do swojego stosu; zobacz Dostosowywanie promptu i modelu triażu

Co dalej

• Skonfiguruj izolowanego agenta triażu: kreator łączący twój fork z Kit
• Jak działa izolacja sieciowa: model zagrożeń i granica sieciowa
• Dostosowywanie promptu i modelu triażu: zmiana modelu, promptu i schematu wyniku
• Integracja AI: screening i narzędzia codziennego triażu, na których opiera się ten proces