Zbieram dane do pracy magisterskiej o podatnościach AI vs człowiek. Największy problem nie jest tam, gdzie się spodziewałem

Temat mojej pracy magisterskiej brzmi prosto: analiza przeżywalności podatności wygenerowanych przez AI w porównaniu do napisanych przez człowieka - od momentu wprowadzenia do repozytorium, aż do załatania. Metodologia jest zapożyczona ze statystyki medycznej (analiza przeżycia - ten sam aparat, którym bada się czas do wystąpienia zdarzenia, np. nawrotu choroby), tylko zamiast pacjentów mam commity, a zamiast remisji - patch. Skupiam się na Pythonie, z nadzieją na rozszerzenie na inne języki, jeśli starczy czasu.

Zanim jednak napiszę linijkę kodu do samej analizy, muszę rozwiązać problem, który okazał się dużo trudniejszy, niż się spodziewałem na starcie.

Jak w ogóle poznać, że podatność napisała AI?

Cała analiza stoi i pada na jednym założeniu: że da się wiarygodnie oznaczyć, czy dany fragment kodu wprowadzający podatność powstał z pomocą AI, czy nie. I tu zaczyna się problem, bo nie ma do tego żadnego oczywistego źródła prawdy.

GitHub nie publikuje danych o tym, które commity powstały z użyciem Copilota. Metadane commitów tego nie mówią. Zostają heurystyki, i żadna z nich nie jest dobra sama w sobie:

• Wzmianki w commit message albo opisie PR ("added with Copilot suggestion", "AI-assisted") - rzadkie, bo prawie nikt tego nie opisuje, więc próbka byłaby mikroskopijna i mocno obciążona (ludzie, którzy to piszą, to nie reprezentatywna grupa).
• Data commita jako proxy (np. wszystko po premierze Copilota jako "potencjalnie AI") - bezużyteczne, bo to nie mówi nic o konkretnym fragmencie kodu, tylko o kalendarzu.
• Styl kodu jako sygnał - kuszące, ale niebezpieczne: dobrzy programiści piszą coraz bardziej "przewidywalny", wzorcowy kod, a modele są trenowane na kodzie ludzi, więc granica się zaciera z każdym miesiącem.

To, co obecnie wygląda dla mnie najbardziej wiarygodnie, to szukanie repozytoriów i projektów, które jawnie i konsekwentnie oznaczają pochodzenie zmian - część większych organizacji zaczyna wymagać takiego oznaczenia w procesie review. To zawęża próbkę, ale daje etykiety, którym można w ogóle zaufać. Kompromis między wielkością zbioru danych a jego wiarygodnością - i wolę mniejszy zbiór, na którym mogę polegać, niż duży, który mówi coś przypadkowego.

Druga połowa: dopasowanie podatności do commitów

Mając już (jakoś) oznaczone pochodzenie kodu, trzeba jeszcze ustalić dwie daty dla każdej podatności: kiedy została wprowadzona i kiedy załatana. Tu plan jest bardziej konkretny - łączę dane z baz podatności (GitHub Security Advisories, OSV.dev) z historią commitów w repozytorium: baza podatności wskazuje na commit naprawiający, a historia gita pozwala cofnąć się do commita, który wprowadził podatny fragment. Różnica między tymi dwiema datami to właśnie "czas przeżycia" podatności, który trafia do analizy.

Mechanicznie to jest zadanie bardzo podobne do tego, co już robiłem - budowałem sobie pipeline w n8n do automatycznego przeszukiwania ofert pracy i wstępnej selekcji przez AI. Tu skala i rygor są dużo większe (research naukowy, nie osobiste narzędzie), ale sama natura problemu jest ta sama: przeszukać dużą, brudną przestrzeń danych, dopasować rekordy z dwóch różnych źródeł po niepewnym kluczu, i odsiać to, co się nie kwalifikuje, zanim dotrze do właściwej analizy.

Co dalej

Następny krok to zbudowanie samego pipeline'u do przeszukiwania repozytoriów - najpierw na małej, ręcznie zweryfikowanej próbce, żeby sprawdzić, czy metoda oznaczania w ogóle daje sensowne, powtarzalne wyniki, zanim puszczę to na szerszą skalę. Jeśli okaże się, że próbka z jawnym oznaczeniem pochodzenia jest zbyt mała, żeby cokolwiek policzyć - to będzie sygnał, że sama definicja badania wymaga korekty, zanim ruszę dalej. Wolę się o tym przekonać teraz, niż po dwóch miesiącach zbierania danych.