Agent AI proponuje poprawki bezpieczeństwa za pomocą Pull Requestów

Pojawia się alert bezpieczeństwa. LLM analizuje kontekst. Tworzy poprawkę konfiguracji. Otwiera Pull Request w GitHubie. Drugi LLM sprawdza wykonaną pracę. Człowiek zatwierdza (merguje) poprawkę.

Agent nigdy nie dotyka środowiska produkcyjnego. Nigdy nie dokonuje merge'a samodzielnie.

Standardowe kontrolery Kubernetes po prostu ponawiają próby. Jeśli pod ulegnie awarii z powodu błędnej konfiguracji, kontroler będzie go restartował w nieskończoność. Nie rozwiązuje to przyczyny problemu. Bezpieczeństwo ma ten sam problem. System SIEM generuje alert. Człowiek musi go przeczytać i napisać poprawkę. Ten proces jest powolny.

Zbudowaliśmy agenta, aby rozwiązać ten problem. Odczytuje on alerty bezpieczeństwa i analizuje infrastrukturę, aby przygotować projekt poprawki. To nie jest autopilot. To generator projektów. Wszystko inne pozostaje pod kontrolą człowieka i GitOps.

Jak to działa:

• Wazuh wykrywa ataki i zapisuje alerty w bazie danych. • Most (bridge) pobiera nowe alerty i uruchamia agenta. • Agent korzysta z ograniczonych narzędzi. Może odczytywać/zapisywać pliki, tworzyć gałęzie (branches) i korzystać z GitHub API. Edytuje wyłącznie pliki konfiguracyjne. • ArgoCD monitoruje repozytorium. Nic nie zostaje wdrożone, dopóki człowiek nie zatwierdzi (nie zmerguje) PR.

Stosujemy dwie warstwy bezpieczeństwa:

  1. Sprawdzanie kodu. Reguły nieoparte na LLM weryfikują diff. Sprawdzamy, czy zmiana dotyczy wyłącznie plików konfiguracyjnych. Sprawdzamy, czy ścieżka serwera odpowiada alertowi. Sprawdzamy rozmiar diffa. Jeśli test nie przejdzie, PR zostaje zatrzymany.

  2. Przegląd przez drugi model LLM. Inna rodzina modeli analizuje PR. Przedstawia swoją opinię. Używamy innego modelu, ponieważ modele często zgadzają się same ze sobą. Mówimy również modelowi, aby nie ufał tekstowi zawartemu w PR. Zapobiega to ukrywaniu komend przez atakujących w treści alertu.

Co zmieniliśmy w trakcie rozwoju:

• Przeszliśmy z chmurowych modeli LLM na własny serwer z wykorzystaniem Ollama. Dzięki temu dane pozostają prywatne, a przerwy w działaniu usług są unikane. • Zastąpiliśmy agentów „ToolCalling” agentami „CodeAgent”. Małe modele mają trudności z przesyłaniem czystego formatu JSON. CodeAgent zamiast tego pisze w Pythonie. Zmniejszyło to liczbę błędów i kroków z ponad 20 do zaledwie 3–8. • Zastąpiliśmy narzędzia „run_shell” konkretnymi narzędziami Git. Zapobiega to wykonywaniu niebezpiecznych komend, takich jak „rm -rf”. • Przeszliśmy z konfiguracji typu „push” na „pull”, aby zapewnić lepszą stabilność sieci.

Traktujemy LLM jak szybkiego junior developera. Jego projekty są przydatne, ponieważ między agentem a środowiskiem produkcyjnym znajdują się ludzie oraz dodatkowe mechanizmy kontrolne.

Źródło: https://dev.to/aisecops/an-ai-agent-that-proposes-security-fixes-as-pull-requests-2hjj

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi