Usuwanie podatności z pomocą AI: co potrafią pull requesty z poprawkami AI

Czym jest usuwanie podatności z pomocą AI

Usuwanie podatności z pomocą AI polega na tym, że model językowy przygotowuje poprawkę znanej podatności. Występuje w trzech postaciach:

• Sugestie poprawek kodu. Model proponuje łatkę obok alertu z analizy statycznej. GitHub Copilot Autofix na przykład „automatycznie generuje sugestie zmian kodu dla alertów CodeQL znalezionych w pull requestach i w gałęzi domyślnej”.
• Aktualizacje zależności, które dostosowują kod. Podbicie wersji jest proste. Trudna część to zmieniona nazwa funkcji lub zmieniona wartość domyślna, które przynosi nowa wersja. Model może wprowadzić te dalsze zmiany w tym samym pull requeście.
• Agentowe usuwanie podatności. Agent samodzielnie przeprowadza poprawkę przez kilka kroków: zmienia kod, uruchamia build i testy, odczytuje błędy, próbuje ponownie i otwiera pull request dopiero wtedy, gdy kontrole przejdą.

Gdzie poprawki AI są warte swojej ceny

Boty aktualizacji oparte na regułach już dziś otwierają pull requesty podbijające podatny pakiet do wersji z poprawką. Utykają, gdy aktualizacja coś psuje, bo dostosowanie wywołującego kodu nie jest regułą. Właśnie tam rośnie zaległość: aktualizacja bezpieczeństwa, która miesiącami pozostaje otwarta, bo nikt nie ma czasu przejść przez zmianę wersji głównej.

Czytanie changelogu, znajdowanie miejsc wywołań i ich przepisywanie to praca, w której modele językowe są dobre. Poprawka AI, która przychodzi z aktualizacją i zmianami w kodzie, zbudowana i przetestowana, zamienia tydzień czyjejś uwagi w przegląd.

Gdzie poprawki AI zawodzą

Najjaśniej granice opisują sami dostawcy. O Copilot Autofix GitHub pisze:

• „Korzysta z modelu generatywnego, który jest niedeterministyczny. Nawet przy tym samym alercie i kodzie może nie wygenerować użytecznej sugestii, a sugestia może się różnić między próbami”.
• „System nie wie, które wersje zależności są wspierane lub bezpieczne, i może sugerować zmyślone zależności opublikowane pod statystycznie prawdopodobnymi nazwami”.

Drugi punkt nie jest hipotetyczny. Badania modeli generujących kod zmierzyły, jak często polecają pakiety, które nie istnieją: nazwy, które atakujący może zarejestrować i wypełnić złośliwym oprogramowaniem. Poprawka instalująca zmyślony pakiet zastępuje jedną podatność gorszą.

Większość ryzyka pokrywają trzy zabezpieczenia:

1. Budować i testować każdą poprawkę, zanim przejrzy ją człowiek, aby czas przeglądu trafiał do poprawek, które działają.
2. Sprawdzać każdy dodany lub zmieniony pakiet w rejestrze i pod kątem oczekiwanej wersji.
3. Zostawić decyzję o scaleniu człowiekowi. Poprawka AI to pull request kontrybutora, a nie decyzja.

Śmieci na wejściu, pull requesty na wyjściu

Narzędzie AI do usuwania podatności naprawia te podatności, które otrzyma. Jeśli ta lista jest odtwarzana z lockfile lub zeskanowanego obrazu, dziedziczy każdą lukę tej rekonstrukcji: narzędzia pobierane przez build, których nie deklaruje żaden manifest, wersje inne niż te, które build rozwiązał, pakiety przywrócone z cache. Narzędzie otwiera wtedy pewne siebie pull requesty dla części podatności, a o innych nigdy się nie dowiaduje.

Niektóre zespoły idą dalej i każą modelowi samodzielnie ustalić zależności. Wtedy niedeterministyczny staje się także inwentarz, czyli ta jedyna część procesu, która za każdym razem powinna dawać ten sam wynik. SBOM-y generowane przez AI wyjaśniają, dlaczego zgadywany inwentarz nie jest dowodem.

Sprawdza się układ, w którym pod spodem są dane deterministyczne, a na wierzchu ocena AI: zarejestrowana lista tego, co faktycznie zawiera każdy build, dopasowana do komunikatów bezpieczeństwa przez wyszukanie, i AI pisząca poprawkę.

Gdzie pasuje CRACI

CRACI jest warstwą deterministyczną. Uruchamia Państwa zadania GitHub Actions na własnych runnerach i rejestruje pakiety, które każde zadanie faktycznie pobrało, w tym zależności przechodnie i pakiety przywrócone z cache, ze stanem kompletności dla każdego zadania. Na bieżąco ponownie ocenia monitorowane SBOM-y, więc nowy komunikat bezpieczeństwa pojawia się przy buildach, których dotyczy, a zespoły bezpieczeństwa analizują każde znalezisko i przekazują je zespołowi odpowiedzialnemu za poprawkę.

Od tej listy powinna zaczynać się poprawka AI, a po jej scaleniu SBOM następnego buildu pokazuje, czy build rzeczywiście użył poprawionej wersji. Pełny opis funkcji zawiera strona śledzenie podatności, a to, gdzie pasuje każde podejście, wyjaśnia porównanie AI a bezpieczeństwo deterministyczne.

Usuwanie podatności z pomocą AI: najczęściej zadawane pytania

Czym jest usuwanie podatności z pomocą AI?

Usuwanie podatności z pomocą AI polega na tym, że model językowy przygotowuje poprawkę podatności: zmianę kodu dla znaleziska z analizy statycznej albo aktualizację zależności wraz ze zmianami w kodzie, których ta aktualizacja wymaga. Wynikiem jest zwykle sugestia lub pull request do przejrzenia przez człowieka.

Czym jest agentowe usuwanie podatności?

Agentowe usuwanie podatności daje agentowi AI narzędzia, dzięki którym samodzielnie przeprowadza poprawkę przez kilka kroków: odczytuje znalezisko, zmienia kod, uruchamia build i testy i powtarza to, aż przejdą, a następnie otwiera pull request. W odróżnieniu od jednorazowej sugestii agent sam sprawdza swoją pracę, zanim zobaczy ją człowiek.

Czy poprawki bezpieczeństwa wygenerowane przez AI można bezpiecznie scalać?

Prosimy traktować je jak pull request każdego innego kontrybutora. GitHub opisuje Copilot Autofix jako niedeterministyczny i ostrzega, że może sugerować zmyślone zależności, dlatego warto przejrzeć zmianę, uruchomić testy i sprawdzić, czy każdy dodany pakiet istnieje i jest tym, którego Państwo oczekują.

Czy AI potrafi znajdować podatności w zależnościach?

To niewłaściwe narzędzie do tej części. To, czy dana wersja pakietu jest objęta znanym komunikatem bezpieczeństwa, jest kwestią wyszukania i za każdym razem powinno dawać ten sam wynik. Listę podatnych pakietów powinny tworzyć deterministyczne narzędzia na podstawie zarejestrowanego SBOM, a AI warto używać tam, gdzie pomaga ocena: przy pisaniu i dostosowywaniu poprawki.

Czego potrzebuje narzędzie AI do usuwania podatności, aby dobrze działać?

Dokładnej listy tego, co faktycznie jest podatne, buildu i zestawu testów, na których może sprawdzić poprawkę, oraz człowieka, który decyduje o scaleniu. Najczęściej brakuje pierwszego: pull request z poprawką dla pakietu, którego produkt nie zawiera, to szum, a podatny pakiet pominięty w inwentarzu nigdy nie dostanie poprawki.