Zašto skoro polovina koda koji generiše AI ima bezbednosne propuste

Aplikacija može da izgleda gotovo mnogo pre nego što je bezbedno pustiti je pred korisnike. Taj jaz je ceo problem sa vibe kodiranjem: demo je ubedljiv, ekrani rade, i ništa vidljivo ne ukazuje na to da delovi koje ne vidite nikada nisu pravilno napravljeni.

Sada postoje solidni podaci o tome koliko se često to dešava.

Šta istraživanje zaista kaže

Veracode-ov izveštaj o bezbednosti koda koji generiše AI za 2025. godinu testirao je kod koji je generisalo više od 100 velikih jezičkih modela u jezicima Java, JavaScript, Python i C#. Na tim zadacima, 45% generisanih uzoraka palo je na bezbednosnom testiranju jer je unelo ranjivost sa OWASP Top 10 liste.

Dva detalja vredi držati jasnim, jer se naslov često razvlači.

• Podatak od 45% opisuje uzorke koda generisane za zadatke značajne za bezbednost, a ne „45% aplikacija napravljenih uz AI". To je mera koliko često model proizvede nebezbedan kod kada se od njega traži nešto gde je bezbednost važna.
• Stopa se veoma razlikuje po jeziku i vrsti ranjivosti. Java je u toj studiji pala u oko 72% slučajeva, dok su Python, C# i JavaScript bili u rasponu od 38-45%. Cross-site scripting je bio među najgorim kategorijama, sa stopom neuspeha od 86%.

Iskren zaključak nije „AI piše pokvaren kod". Zaključak je da AI piše uverljiv kod, a uverljiv je mnogo niži prag od bezbednog. Model od kog se traži da doda ekran za prijavu napraviće ekran za prijavu. Da li je napravio i proveru autorizacije na serveru, rezultat ne otkriva.

Problem nije kod koji ne radi. Problem je kod koji radi za idealan scenario, a o ostalom ga niko nije pitao.

Gde vibe-kodirane aplikacije pucaju

Problemi se grupišu na malom broju predvidljivih mesta, jer su to oblasti u kojima se ispravno ponašanje ne vidi na demonstraciji.

Autorizacija koja postoji samo u interfejsu

Najčešći ozbiljan propust. Aplikacija sakriva administratorsko dugme od običnih korisnika, ali endpoint iza njega nikada ne proverava ko ga poziva. Svako ko može da pročita mrežni saobraćaj - a to je svako ko ima instaliranu aplikaciju - može da ga pozove direktno.

Ovo prolazi svaki ručni test, jer tester koristi aplikaciju kroz njen interfejs.

Tajni podaci u klijentu

API ključevi, pristupni podaci za bazu i tokeni trećih strana završe ugrađeni u paket aplikacije jer je to najkraći put do funkcije koja radi. Binarni fajl mobilne aplikacije nije tajna; sve što je u njemu može da se izvuče.

Unos koji ide pravo u upit

Propusti tipa injection i cross-site scripting opstaju iz istog razloga kao i uvek: spajanje korisničkog unosa u upit ili njegovo prikazivanje bez escape-ovanja radi savršeno dok neko ne pošalje nešto zlonamerno.

Pristup podacima bez granica

Endpoint koji vraća zapis po ID-u, bez provere da li korisnik koji ga traži sme da vidi taj zapis. Promenite broj u zahtevu i dobijete tuđe podatke. Trivijalno za zloupotrebu, često u generisanom kodu i nevidljivo dok neko ne krene da traži.

Zavisnosti koje niko nije svesno izabrao

Generisani kod uvlači pakete da bi rešio trenutne probleme. Niko ne proverava da li se održavaju, da li imaju poznata bezbednosna upozorenja i da li tri od njih rade isti posao.

Zašto ovo nije argument protiv AI alata

I mi koristimo AI alate u svom razvoju, i oni zaista štede vreme na osnovnoj strukturi, migracijama i testovima. Važna razlika nije AI nasuprot čoveku. Važno je da li je neko kompetentan pregledao rezultat u odnosu na model pretnji pre nego što je isporučen.

Senior inženjer koji koristi model da napiše prvi nacrt, a zatim proveri putanju autorizacije, radi uobičajen inženjerski posao. Osnivač koji isporučuje generisani kod koji ne ume da pročita radi nešto drugo - a razlika postaje vidljiva tek kada neko krene da je ispituje.

Kako da proverite sopstvenu aplikaciju

Ako imate aplikaciju koju je uglavnom generisao AI i želite brz i jeftin uvid u njenu izloženost, počnite ovde.

1. Pretražite repozitorijum za ključevima i tokenima upisanim u kod. Ako ih pronađete, pretpostavite da su kompromitovani i zamenite ih.
2. Izaberite svoj najosetljiviji endpoint i pozovite ga direktno, bez aplikacije, kao korisnik koji ne bi trebalo da ima pristup. Ako odgovori, imate problem sa autorizacijom.
3. Uzmite ID zapisa sa sopstvenog naloga i promenite ga u susednu vrednost. Ako dobijete tuđe podatke, to je propust opisan gore.
4. Pokrenite audit komandu svog menadžera paketa i pročitajte rezultate visoke ozbiljnosti.
5. Proverite šta aplikacija beleži u logovima. Tokeni, lozinke i lični podaci u logovima su često i lako popravljivo curenje.

Ovih pet provera traje jedno popodne i hvata značajan deo onoga što se zaista zloupotrebljava. Nisu zamena za pravi pregled, ali će vam brzo reći da li vam je potreban.

Ako vas odgovori zabrinu, strukturiran pregled baze koda je upravo ono što radi naša usluga revizije i spasavanja aplikacija.

Česta pitanja