AI coding agent i ryzyko łańcucha dostaw oprogramowania
Agent kodujący może instalować pakiety, uruchamiać skrypty i publikować zmiany. Zabezpiecz zależności, CI, provenance, review i sekrety.
- AUTOR
- Karol Rapacz / Pentester (OSCP, PNPT)
- PUBLIKACJA
- 15 czerwca 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Bezpieczeństwo AI
AI coding agent może edytować kod, instalować pakiety, uruchamiać build i otwierać pull request. Prompt injection w issue lub README może więc stać się atakiem na łańcuch dostaw bez klasycznej podatności w IDE.
Zależności jako wejście niezaufane
Agent nie powinien dodawać pakietu tylko dlatego, że nazwa pasuje do sugestii. Wymagaj istniejącego registry, minimalnej reputacji, przypiętej wersji, lockfile i review licencji. Blokuj install scripts, gdy nie są potrzebne.
Oddziel kod od publikacji
Agent pracuje na osobnej gałęzi i nie ma prawa merge, release ani zapisu do registry. CI używa efemerycznej tożsamości, a publikacja wymaga zatwierdzenia oraz podpisanego provenance.
Testuj zmianę, nie wyjaśnienie
Uruchom SAST, testy, secret scanning, dependency scan i analizę diffu. Wygenerowane testy mogą zostać osłabione razem z kodem, dlatego krytyczne security tests mają osobnego ownera.
Ryzyko repozytorium
Komentarz, fixture i dokumentacja są niezaufaną treścią. Nie pozwalaj im zmienić uprawnień agenta. Reguły wykonawcze przechowuj poza repozytorium lub podpisuj i zatwierdzaj niezależnie.
OWASP wskazuje, że agenci codingowi mogą uruchamiać shell, instalować zależności i pushować zmiany. Połącz te kontrolki z SLSA i Sigstore oraz hardeningiem Claude Code.
Granice uprawnień agenta codingowego
Rozdziel odczyt repozytorium, modyfikację plików, uruchamianie testów, pobieranie zależności, zapis do gita i publikację artefaktu. Agent potrzebujący przygotować patch nie musi mieć prawa do pushowania na chronioną gałąź ani dostępu do klucza produkcyjnego. Każdy etap powinien używać osobnej, krótkotrwałej tożsamości z minimalnym scope.
Repozytorium jest niezaufanym wejściem. Instrukcja w README, komentarzu, issue, teście lub nazwie pliku może próbować zmienić cel agenta. Zasady wykonawcze utrzymuj w zaufanej konfiguracji poza edytowanym kontekstem i egzekwuj je w executorze. Model nie może sam zatwierdzić wyjątku od polityki.
Zależności i artefakty
Instalacje wykonuj w izolowanym środowisku bez domyślnego dostępu do sekretów. Preferuj lockfile, wewnętrzne proxy pakietów i pinning wersji, a zmiany zależności pokazuj jako osobny diff. Nowy skrypt instalacyjny, repozytorium pakietów lub binarny artefakt powinien uruchomić dodatkową kontrolę.
Build po akceptacji patcha odbywa się w czystym CI, nie w środowisku agenta. Pipeline generuje provenance, inwentaryzuje zależności i wiąże wynik z konkretnym commitem. Podpis lub atestacja potwierdza proces pochodzenia, ale nadal nie zastępuje testów bezpieczeństwa zawartości.
Bramka akceptacji zmiany
Oceniaj rzeczywisty diff oraz wyniki kompilacji, testów, SAST, secret scanning i kontroli zależności. Streszczenie agenta jest wskazówką, nie dowodem. Zmiany workflow, uprawnień, skryptów release, plików polityki i konfiguracji sieci wymagają właściciela kodu oraz niezależnej akceptacji.
Testuj prompt injection w każdym typie pliku, próbę odczytu zmiennych środowiskowych, instalację pakietu o podobnej nazwie, wyłączenie testu i modyfikację własnych reguł. Udany test kończy się bezpieczną odmową oraz czytelnym zdarzeniem audytowym.
Przegląd zmian wysokiego ryzyka
Oznaczaj automatycznie modyfikacje plików CI/CD, manifestów zależności, uprawnień chmurowych, migracji bazy, kryptografii i kodu uwierzytelniania. Wymagają one recenzenta znającego dany obszar, nawet jeśli testy są zielone. Agent nie powinien sam wybierać osoby zatwierdzającej ani usuwać etykiety ryzyka.
Diff analizuj pod kątem kodu dodanego i usuniętego. Wyłączenie walidacji lub testu może być ważniejsze niż nowa funkcja. Porównaj także wygenerowane lockfile i artefakty, ponieważ mała zmiana deklaracji potrafi wciągnąć duże drzewo zależności.
Odwracalność i wdrożenie
Patch agenta trafia na osobną gałąź i przechodzi te same bramki co kod człowieka. Wdrożenie canary, monitoring oraz plan rollbacku pozostają odpowiedzialnością pipeline’u. Nie pozwalaj agentowi reagować na alarm produkcyjny automatycznym rozszerzeniem uprawnień.
Po wdrożeniu powiąż obserwowane błędy z commitem, wersją modelu i sesją agenta. Dzięki temu można rozróżnić defekt kodu od błędu narzędzia lub niewłaściwej interpretacji repozytorium i zamienić przypadek w test regresyjny.
Wskaźniki programu obejmują odsetek zmian odrzuconych przez politykę, liczbę ręcznych wyjątków, czas recenzji plików wysokiego ryzyka i przypadki wycofania. Sama liczba zaakceptowanych patchy nie dowodzi jakości. Mierz również defekty i incydenty powiązane z kodem wygenerowanym lub zmienionym przez agenta.
Zaufanie do zmiany, nie do autora
Kod wygenerowany przez agenta przechodzi te same bramki co kod człowieka: review, testy, analizę zależności, sekretów i polityk. Agent nie powinien zatwierdzać własnego PR ani zmieniać branch protection. Przypnij wersje zależności i akcji CI do niezmiennych identyfikatorów, a zmianę lockfile traktuj jako część diffu wymagającą oceny.
Budowanie odbywa się w efemerycznym środowisku z minimalnymi poświadczeniami i bez sekretów produkcyjnych. Zachowaj pochodzenie źródła, zależności, buildera i artefaktu; podpis lub atestacja jest wartościowa tylko po weryfikacji polityką przy wdrożeniu. Testuj prompt injection w issue, README i kodzie zależności oraz próbę modyfikacji pipeline’u.
