Home AIMože li GitHub issue da napadne programera preko AI agenta?

Može li GitHub issue da napadne programera preko AI agenta?

od itn
AI alati za programiranje

AI alati za programiranje više nisu samo asistenti koji predlažu nekoliko linija koda dok programer radi. Savremeni coding agenti mogu da otvore projekat, analiziraju veliki broj fajlova, menjaju kod, pokreću testove, koriste terminal i pripreme pull request. Neki od njih mogu da dobiju zadatak direktno preko GitHub issue-a: programer ili drugi korisnik opiše problem, a agent zatim samostalno pokušava da pronađe uzrok i napravi potrebne izmene.

Upravo ta mogućnost otvara novu bezbednosnu slabost. GitHub issue više nije samo tekst koji čovek čita. Za AI agenta on istovremeno predstavlja podatak koji treba analizirati i skup instrukcija na osnovu kojih treba postupati. Ako napadač može da ubaci dodatne, zlonamerne instrukcije u issue, komentar, PDF ili drugi sadržaj koji agent obrađuje, postoji mogućnost da ga navede da uradi nešto što programer nije tražio.

Istraživanje objavljeno u julu 2026. pokazuje da to nije samo teorijska mogućnost. Autori benchmark-a IssueTrojanBench testirali su Cursor, Claude Code i Codex Desktop pomoću zlonamerno konstruisanih GitHub issue zahteva. U eksperimentima je 66,5 odsto takvih issue-a uspelo da prođe sve testirane zaštitne mehanizme coding agenata i modela na kojima su zasnovani.

AI alati za programiranjeKada zahtev za ispravku greške postane ulaz za napad

GitHub issue je napravljen upravo da bi neko mogao da prijavi grešku, zatraži novu funkcionalnost ili opiše problem u projektu. U klasičnom razvojnom procesu programer pročita prijavu, proceni šta treba uraditi i odlučuje koje delove koda će menjati. Ako je u tekstu issue-a nešto sumnjivo, odgovornost za njegovo tumačenje ostaje na čoveku.

Kod coding agenta deo tog procesa preuzima model. Agent dobija opis problema, analizira repozitorijum, pronalazi relevantne fajlove i koristi alate kako bi izvršio zadatak. To znači da sadržaj issue-a više nije samo informacija za programera već ulaz koji može direktno da utiče na ponašanje sistema.

Autori IssueTrojanBench-a napravili su zlonamerne issue zahteve u kojima su instrukcije dostavljane kroz šest različitih kanala, uključujući sam tekst issue-a, komentare i dokumente poput PDF fajlova. Cilj nije bio samo da se agent navede na pisanje lošeg koda, već i da se ispita da li može biti usmeren ka zloupotrebi alata, spoljnim API-jima, iznošenju podataka ili trajnim izmenama razvojnog okruženja. Testirani su modeli iz OpenAI i Anthropic porodica u kombinaciji sa stvarnim coding alatima.

Problem je u tome što zlonamerna instrukcija može izgledati kao legitimni deo zadatka. Ako se od agenta traži da popravi bug i u priloženoj dokumentaciji se nalazi dodatno „uputstvo“ koje nalaže izvršavanje određene komande, sistem mora da odluči da li je to deo stvarnog tehničkog zahteva ili pokušaj manipulacije.

Zašto je coding agent posebno privlačna meta

Prompt injection kod običnog četbota može da dovede do neželjenog odgovora. Kod coding agenta posledice mogu biti ozbiljnije zato što agent često raspolaže alatima koje klasični četbot nema. Može da čita lokalne fajlove, menja izvorni kod, izvršava komande i komunicira sa razvojnim servisima.

GitHub je još tokom 2025. upozorio da indirect prompt injection u razvojnom okruženju može dovesti do otkrivanja poverljivih fajlova ili tokena, pa čak i do izvršavanja koda bez eksplicitne namere korisnika. Kompanija zbog toga kod svojih agentic sistema primenjuje ograničavanje mrežnog pristupa, kontrolu privilegija i dodatne sigurnosne provere.

OpenAI slično upozorava korisnike Codex-a da uključivanje mrežnog pristupa povećava rizik od prompt injection napada, jer agent može da pronađe i sledi nepouzdane instrukcije iz spoljnih izvora. Zbog toga Codex koristi sandbox i različite nivoe odobrenja za operacije koje izlaze iz unapred dozvoljenih granica.

Coding agent zato predstavlja zanimljivu metu upravo zbog kombinacije dve osobine: sposoban je da razume prirodni jezik, ali istovremeno može da deluje u okruženju u kojem se nalazi stvarni kod.

Problem se ne završava na jednom issue-u

Još širu sliku daje istraživanje agentic workflow-a u GitHub Actions sistemima objavljeno u maju 2026. Autori su analizirali 13.392 stvarna workflow-a iz 10.792 repozitorijuma i tražili situacije u kojima se nepouzdani sadržaj iz issue-a, pull request opisa ili komentara prenosi do AI agenta ili skripte koja zatim izvršava neku radnju. Identifikovali su 519 potencijalnih ranjivosti, od kojih je prema njihovom threat model-u potvrđeno 496, uključujući 343 do tada nepoznate zero-day ranjivosti.

Istraživači ovaj problem nazivaju Agentic Workflow Injection. Jedan obrazac nastaje kada se sadržaj koji kontroliše spoljni korisnik direktno ubaci u prompt agenta. Drugi se javlja kada odgovor modela zatim postane ulaz za skriptu ili drugu komponentu koja ima mogućnost izvršavanja komandi. U oba slučaja problem nastaje zato što sadržaj koji nije pouzdan prelazi granicu između informacije i operativne instrukcije.

GitHub je početkom avgusta 2026. i sam upozorio na isti obrazac kod pregleda agent-generated pull requestova: workflow može da pročita sadržaj pull requesta, issue-a ili commit poruke, ubaci ga u prompt, prosledi rezultat modela shell komandi i sve to izvrši sa dozvolama koje poseduje GITHUB_TOKEN.

To je već veoma različit bezbednosni model od onog na koji su programeri navikli.

Kada AI dobije pristup razvojnim alatima

Coding agent ne mora automatski da ima neograničene privilegije. Upravo zbog ovih rizika proizvođači pokušavaju da ograniče šta agent može da uradi bez dodatne potvrde. GitHub, na primer, primenjuje bezbednosne provere i na kod koji stvaraju third-party agenti kao što su Claude i OpenAI Codex. Od juna 2026. kod koji generišu takvi agenti može automatski da prolazi iste sigurnosne i quality provere koje se koriste za GitHub Copilot cloud agent.

Anthropic problem postavlja još šire. Kompanija upozorava da svaki spoljni resurs koji agent dobije predstavlja dve moguće vrste rizika: klasičan rizik izvršavanja nepouzdanog koda i prompt injection rizik. Provera verzije biblioteke, potpisa ili porekla dependency-ja može pomoći protiv prvog problema, ali ne rešava situaciju u kojoj sadržaj legitimnog resursa pokušava da manipuliše samim agentom.

Zato zaštita više ne može da se zasniva samo na proveri koda koji agent na kraju napiše. Potrebno je kontrolisati i izvore iz kojih dobija instrukcije, dozvole koje poseduje tokom rada, mrežni pristup, izvršavanje komandi i način na koji se rezultati modela prenose drugim komponentama sistema.

AI alati za programiranjeNovi problem za open-source razvoj

GitHub je zasnovan na ideji da veliki broj ljudi može da prijavljuje greške, komentariše kod i šalje predloge izmena. Upravo ta otvorenost postaje novi bezbednosni izazov kada se u proces uključe autonomni agenti.

Čovek koji otvori issue tradicionalno dobija veoma ograničenu mogućnost da utiče na projekat: može da pošalje tekst koji će maintainer pročitati. Ako isti sadržaj automatski preuzima agent koji ima pristup repozitorijumu i alatima, odnos se menja. Nepouzdanom korisniku se indirektno otvara put do sistema koji može da izvršava znatno složenije operacije.

To ne znači da GitHub issue sam po sebi može da „hakuje programera“, niti da će svaki coding agent poslušati zlonamernu instrukciju. Rezultati istraživanja pokazuju nešto preciznije: kada se nepouzdan tekst automatski predaje agentu koji istovremeno ima mogućnost da koristi razvojne alate, nastaje nova površina napada koju klasični razvojni proces nije imao.

Granica bezbednosti zato se pomera. Više nije dovoljno proveriti samo kod koji ulazi u repozitorijum. U svetu AI coding agenata moraće da se proverava i tekst koji agent čita pre nego što taj kod uopšte nastane.

Milena Šović, M.Sc.,CSM, CSPO
AI Implementation Specialist & Content Trainer

Banner

Banner

Možda će vam se svideti i