DI kodas ir kibernetinis saugumas 2026

2026-04-23 · Saugumo tyrimai

Kai DI įsibėgėja

Vien tik nuo šių metų pradžios į rinką išėjo tiek daug technologinių, su dirbtinio intelekto taikymu susijusių patobulinimų, kad nustebinti vis sunkiau: lūkesčiai tik auga.

Sunku pasivyti „Anthropic" komandą su savo „Claude Code", kuris, anot rinkodarinių pareiškimų, „skaito dokumentaciją, rašo keliomis kalbomis, pats vykdo testus ir kartoja, kol produktas paruošiamas gamybai" [1].

Šalia to, sparčiai gerėjantys modeliai. Balandį pristatytas „Opus 4.7" „SWE-Bench Pro" teste pasiekė 64,3 % (beveik 11 punktų daugiau nei pirmtakas) [2]. Dar labiau dėmesį patraukė ribotai pristatytas „Claude Mythos". Laboratorijoje jis pasirodė gabus ne tik kodui rašyti, bet savarankiškai aptiko ir išnaudojo nulinių dienų pažeidžiamumus visose didžiosiose operacinėse sistemose bei naršyklėse, tarp jų - 17 metų nepastebėtą „FreeBSD" klaidą (CVE-2026-4747), leidžiančią gauti root teises per NFS [3]. Pati įmonė šį modelį pavadino žymiai pajėgesniu už „Opus 4.7" programavimo srityje ir plačiai jo neišleido bijodama, kad juo naudosis piktavaliai. Tai buvo ženklas, kad DI darosi vis pajėgesnis ne tik rašyti kodą, bet ir tikrinti, apsaugoti bei išnaudoti pažeidžiamumus.

„Fortune 500" sąraše jau 87 % įmonių pritaikiusios bent vieną „vibe coding" platformą [4], o „App Store" pateikimų skaičius per ketvirtį šoktelėjo 84 % [5].

Apple nubrėžia ribą

„Apple" atrodo atsilieka DI lenktynėse: „Apple Intelligence" nebekonkuruoja su pagrindiniais DI modeliais funkcionalumu. Tačiau kompanija nusprendė kalbėti kita kalba: ne apie gebėjimus, o apie kokybę.

2026 m. kovą „Apple" tyliai užblokavo atnaujinimus keliems „vibe coding" produktams: tarp jų „Replit" ir „Vibecode", o programą „Anything" tiesiog išėmė iš „App Store" [6].

Formali priežastis: 2.5.2 gairė, draudžianti aplikacijoms vykdyti kodą, kuris keičia jų pačių funkcionalumą. Techniškai tos platformos rodo DI sugeneruotas aplikacijas per įdėtus „web view" komponentus ir „Apple" tai vertina kaip dinaminio kodo vykdymą [7].

Tikroji žinutė platesnė: „Apple" nepasakė „ne DI", ji pasakė „ne prastos kokybės produktui", nesvarbu, kas jį parašė. Atnaujintose 2026 m. taisyklėse sustiprinti privatumo ir dinaminio kodo reikalavimai: daug DI aplikacijų nebepasiekia net vartotojo [8]. Tai pirmasis didelis platformos savininkas, aiškiai pasakęs: atsakomybė už pasekmes tebegula ant gamintojo, ne ant modelio.

Kiek DI kodo yra nesaugus

Kai „Veracode" 2025 m. išbandė 100+ didelių kalbos modelių ir patikrino jų sugeneruotą kodą keturiomis programavimo kalbomis, rezultatas buvo negailestingas: 45 % kodo pavyzdžių neišlaikė saugumo testų ir turėjo OWASP Top 10 pažeidžiamumų. DI sugeneruotame kode pažeidžiamumų aptikta 2,74 karto daugiau nei žmogaus rašytame. „Java" buvo rizikingiausia kalba: 72 % užduočių nepavyko saugiai išspręsti [9].

„Apiiro" įmonių tyrimas parodė dar dramatiškesnę tendenciją: iki 2025 m. birželio DI sugeneruotas kodas kas mėnesį generuodavo per 10 000 naujų saugumo problemų, dešimt kartų daugiau nei prieš pusmetį. Privilegijų eskalavimo kelių padaugėjo 322 %, architektūros klaidų: 153 % [10].

Stanfordo universiteto tyrimas (vadovaujamas Dan Boneh) pridėjo nemalonų niuansą: programuotojai, dirbę su DI asistentu, rašė mažiau saugų kodą nei tie, kurie dirbo be jo, bet jautėsi rašantys saugesnį. Klasikinis klaidų sustiprinimo ciklas: pasitikėjimas auga greičiau nei kompetencija [11].

2026 m. pirmąjį ketvirtį nepriklausomas skenavimas parodė, kad 91,5 % „vibe coded" aplikacijų turėjo bent vieną su DI haliucinacija susijusią klaidą. XSS pažeidžiamumų aptikta 86 % DI kodo pavyzdžių, o paslaptys (API raktai, prisijungimai) nutekinami 3,2 % DI commitų (dvigubai dažniau nei žmogaus rašytuose) [12].

Kai problemos pasiekia vartotojus

Du šių metų incidentai gerai iliustruoja, kas nutinka, kai šios problemos peržengia testavimo aplinką.

„Lovable", „vibe coding" platforma, įvertinta 6,6 mlrd. dolerių, aštuoni milijonai naudotojų. Per trumpą laiką trys dokumentuoti saugumo incidentai atskleidė išeities kodą, duomenų bazių prisijungimo duomenis ir tūkstančius naudotojų įrašų. Viena BOLA (Broken Object Level Authorization) klaida išbuvo atvira 48 dienas po to, kai saugumo tyrėjas apie ją pranešė: įmonė tiesiog uždarė pranešimą be tinkamo nagrinėjimo [13].

„Moltbook", DI agentams skirtas socialinis tinklas, pastatytas pilnai per „vibe coding". 2026 m. vasarį saugumo bendrovė „Wiz" rado netinkamai sukonfigūruotą „Supabase" duomenų bazę, atvirą internete: 1,5 milijono API autentikacijos žetonų, 35 000 el. pašto adresų ir privačių agentų susirašinėjimų, pasiekiamų bet kam [14]. Pagrindinė klaida: „Supabase" API raktas paliktas kliento pusės „JavaScript" kode be RLS („Row Level Security") politikos. Penkių minučių konfigūracijos nustatymas būtų užkirtęs kelią visam incidentui.

Svarbu: abiejuose incidentuose problema buvo ne kodo logika, o konfigūracija, infrastruktūra ir procesai, sritys, kurių DI modelio niekas iš tikrųjų neišmokė.

Saugus kodas dar nėra saugus produktas

Pirmas dalykas, kurį verta priimti atvirai: DI parašytas kodas retai būna idealus. Net tada, kai jis atrodo tvarkingas, lieka subtilios klaidos, nepatikrinti kraštiniai atvejai ir sprendimai, kurie tinka bendram atvejui, bet ne jūsų aplinkai.

Antras, kartais dar svarbesnis dalykas: DI apskritai nepagalvoja apie kitus sluoksnius, kuriuose tas kodas veiks. Tinklo segmentavimas, paslapčių valdymas, tapatybės politika, stebėsena, atitikties reikalavimai - visa tai lieka už modelio regėjimo ribų. Jis rašo funkciją, bet neklausia, kaip ji integruosis į visą sistemą.

O jei DI vis dėlto bandoma pasitelkti ir šiems sluoksniams spręsti, rezultatas dažnai neparodo realios būklės arba tiesiog suklaidina: modelis pateikia vadovėlinę gerąją praktiką, kuri jūsų konkrečioje aplinkoje gali būti dalinai klaidinga, nereikalinga ar net prieštaraujanti jau veikiančioms kontrolėms. Kontekstas skiriasi - tinklo topologija, paveldėtos sistemos, esami apsaugos sluoksniai, - o DI to nemato.

Būtent čia atsiskleidžia saugumo ekspertų vaidmuo: jie turi platesnį matymą - jungia kodą su infrastruktūra, įvertina, kurie sluoksniai jau kompensuoja kodo trūkumus, o kur iš tiesų slypi rizika. Tai klausimas, apie kurį, mūsų nuomone, šiandien turėtų galvoti kiekvienas, priimantis sprendimus dėl DI sugeneruoto kodo gamyboje.

Kaip ekspertai vertina realų sistemos saugumą

Kadangi DI pilno paveikslo nemato, sistemą tenka vertinti iš šono - stebint, kaip ji elgiasi iš tikrųjų, o ne ką byloja kodas. Tam saugumo ekspertai taiko du vienas kitą papildančius žingsnius.

1. DAST testavimas gamybinėje aplinkoje. Veikiančiai aplikacijai siunčiamos netikėtos, iškreiptos ir piktavališkos užklausos: manipuliuoti parametrai, neautorizuotos prieigos bandymai, kraštiniai įvesties atvejai. Stebima, kaip sistema reaguoja, ką grąžina, ar neatskleidžia vidinės informacijos per klaidų pranešimus, ar tinkamai autorizuoja prieigą prie gilesnių objektų. Taip išryškėja pažeidžiamumai, kurie kode atrodo nekalti, bet realioje aplikacijoje tampa atakos vektoriumi.

2. Infrastruktūros būklės patikra. Tuo pačiu vertinama ir aplinka, kurioje kodas veikia: tinklo segmentavimas, WAF taisyklės, tapatybės valdymas, paslapčių saugojimas, audito žurnalai, atsarginės kopijos, atnaujinimų būklė. Ne todėl, kad DI šiose srityse klysta, o todėl, kad būtent šie sluoksniai arba kompensuoja kodo trūkumus, arba palieka juos atvirus atakai.

Sujungus abu pjūvius - realų sistemos elgesį ir infrastruktūros būklę - galima parengti ataskaitą su konkrečiomis, kontekstą atitinkančiomis rekomendacijomis: ką taisyti kode, ką keisti konfigūracijoje, ką sustiprinti ugniasienėje, kur reikia papildomo stebėjimo. Tai medžiaga, su kuria komanda gali veikti toliau, o ne bendros vadovėlinės gairės, kurias grąžintų DI.

Kaip infrastruktūra padeda suvaldyti riziką

Iš karto svarbu pasakyti, ko infrastruktūra nedaro: ji nepaverčia nesaugaus kodo saugiu ir neatleidžia nuo pareigos tą kodą taisyti. Jos vaidmuo kitoks - tai sluoksnis iš daugybės komponentų, kiekvienas skirtas valdyti tam tikrą grėsmių kategoriją: vieni atremia tinklines atakas, kiti stabdo automatinius skenerius, treti riboja žalą, jei kažkas vis tiek pateko vidun, dar kiti fiksuoja anomalijas.

O kalbant konkrečiai apie per patikrinimą atrastas spragas - tokios priemonės kaip WAF leidžia jas greitai užkardyti kaip laikiną pataisymą, kol komanda išleidžia galutinį sprendimą kode. Kartu audito žurnalai ir SIEM parodo, ar kas nors nebando tos spragos išnaudoti ir leidžia reaguoti proaktyviai, dar nespėjus žalai išplisti.

Iš kokių priemonių dažniausiai susideda šis apsaugos sluoksnis:

Web Application Firewall (WAF). L7 sluoksnyje filtruoja nepageidaujamas ir kenkėjiškas užklausas - SQL injekcijas, XSS ir kitus žinomus šablonus - net tada, kai pačiame kode tos klaidos dar yra.
Bot apsauga. Stabdo automatinius skenerius, ieškančius pažeidžiamumų, ir užkerta kelią turinio pasisavinimui (angl. scraping).
Tinklo segmentavimas. Net kompromitavus vieną mazgą DMZ zonoje, užpuolikas negali lengvai peršokti į vidinį tinklą ir pasiekti jautresnių sistemų (angl. pivoting).
Mažiausių privilegijų principas. Pažeista paslauga gali pasiekti tik tai, ko jai realiai reikia - ne visą duomenų bazę ir ne visus API raktus.
Audito žurnalai ir SIEM. Fiksuoja įvykius, leidžia pastebėti anomaliją ir reaguoti dar nespėjus įvykti rimtai žalai.
Atsarginės kopijos ir nekeičiami infrastruktūros šablonai. Leidžia per minutes atkurti sistemą po kompromitacijos ar klaidos.

Tai ir yra gilumos gynyba (angl. defense in depth): jei vienas sluoksnis nepavyksta, kiti stabdo ataką. Infrastruktūros komponentų visuma tinkamai parinkti ir sukonfigūruoti sluoksniai, kurie sumažina riziką taip, kad vartotojui tai liktų praktiškai nepastebima - be papildomų trukdžių, lėtumo ar sudėtingesnio prisijungimo. Tiesiog mažiau galimybių įvykti tam, ko nenorime.

Išvados

Mitas apie DI kaip visa ko sprendimą pavojingas ne todėl, kad modeliai blogi, „Claude Opus 4.7", „Mythos" ar GPT šeimos modeliai tikrai pagreitina patyrusio programuotojo darbą. Mitas pavojingas todėl, kad nėra matomas pilnas kontekstas tarp sluoksnių.

„Apple" tipo reguliacinių veiksmų tik daugės. NIS2, DORA ir atsirandantys DI reglamentai vis labiau reikalaus, kad organizacijos gebėtų parodyti savo kontrolės sluoksnius, o ne tik pasitikėti kodu.

Praktiškai tai reiškia, kad šalia statinės kodo analizės (SAST) vis svarbesnis tampa ir DAST (angl. Dynamic Application Security Testing): veikiančios aplikacijos testavimas su netikėtomis užklausomis, apie kurias DI nepagalvojo. DAST nevertina kodo eilutės po eilutės, o stebi, kaip sistema iš tikrųjų elgiasi ataku metu, ką grąžina gavusi iškreiptą įvestį, ar neatskleidžia vidinės informacijos per klaidų pranešimus, ar tinkamai autorizuoja užklausas į gilesnius objektus. Būtent čia dažniausiai išryškėja tie pažeidžiamumai, kurių nei DI asistentas, nei programuotojas, rašydami kodą, nenumatė.

„Atakos vektoriaus" komanda padeda organizacijoms paruošti kelis šio konteksto sluoksnius vienu metu:

DAST pažeidžiamumų vertinimas: dinaminis veikiančios aplikacijos testavimas su netikėtomis užklausomis, atskleidžiantis tai, ko kode nesimato.

WAF konfigūracija ir valdymas: apsaugos sluoksnis, stabdantis atakas ir automatinius skenerius net tada, kai pačiame kode pažeidžiamumų lieka.

Mokymai IT inžinieriams ir programuotojams: praktinis saugumo testavimas ir web aplikacijų įsilaužimo metodai.

Jei svarstote apie DI sugeneruotą kodą savo sistemoje, turite klausimų, kurie kelia nerimą, ar kažkas tiesiog neveikia kaip turi - pasikalbėkime.