Vibe Coding saugumas: kaip apsaugoti dirbtiniu intelektu sukurtą programėlę

Daugiau nurodymų, kaip dirbti su Ailoot, rasite dokumentacijoje.

Kodėl į dirbtiniu intelektu sukurtas programėles įsilaužiama dažniau?#

Pats kuriu produktus su DI ir nesergu saugumo paranoja, dėl kurios reikėtų „viską maksimaliai užrakinti“. Tačiau egzistuoja bazinis lygis, žemiau kurio negalima nusileisti, antraip vieną dieną pabusite radę tuščią duomenų bazę ir kieno nors kito kriptovaliutų kasimo programas savo serveryje. Šis vadovas ir skirtas tam baziniam lygiui. Ne „tapkite saugumo ekspertu“, o „be reikalo nešaukite sau į koją“.

Problemos priežastis paprasta. Kai pasakote DI agentui „sukurk man klientų rezervacijų programėlę“, jis stengiasi kuo greičiau padaryti, kad programėlė veiktų. Saugumas – papildomas darbas, kurio demonstracijoje nematyti. Todėl duomenų bazė nustatoma kaip atvira, mokėjimo raktas įrašomas tiesiai į kodą, o patikra „ar šis naudotojas turi prieigą?“ atliekama tik naršyklėje, kur ją galima apeiti per sekundę.

Antrąją priežastį sudaro pačios platformos. Daugelis platformų naujus projektus pagal numatytuosius nustatymus padaro viešai prieinamus, o kūrėjai ne visada žino, kad tai reikia pakeisti.

Kitaip tariant, spraga atsiranda savaime, pagal numatytuosius nustatymus. Nieko blogo nepadarėte. Tiesiog nieko nepadarėte – o saugumo srityje neveikimas reiškia būtent tai: „atvira visiems“.

Yra ir trečias sluoksnis. DI dažniau nei žmogus atskleidžia paslaptis. Agentas gali nežiūrėdamas paleisti git add . ir git push, o jūsų .env failas su raktais paviešinamas kartu su visa kita.

Ko vibe coding kūrėjai jau išmoko sunkiuoju būdu?#

Geriausias skiepas nuo neatsargumo – mokytis iš kitų klaidų. Štai keturios analizės, kurias verta perskaityti prieš publikuojant projektą.

„Lovable“ ir išjungtas RLS. „Lovable“ platforma kuria programėles pagal tekstinius aprašymus. 2025 m. jos programėlėse aptikta sisteminė spraga, kuriai suteiktas CVE-2025-48757 numeris. Priežastis: sugeneruotose programėlėse nebuvo duomenų bazės prieigos taisyklių eilučių lygmeniu (RLS, paaiškinta toliau). Tyrėjas patikrino imtį ir rado 303 atvirus prieigos taškus 170 programėlių. Buvo atskleisti vardai, telefono numeriai, mokėjimų būsenos, kitų žmonių API raktai ir net namų adresai. Maždaug 70 procentų patikrintų programėlių eilučių lygmens apsauga buvo visiškai išjungta.

„Tea“ ir jautrūs duomenys. „Tea“ programėlė (anoniminiai atsiliepimai apie žmones) 2025 m. liepą prarado apie 72,000 vaizdų, įskaitant 13,000 asmenukių ir dokumentų nuotraukų, o vėliau – daugiau nei milijoną privačių žinučių. Techninė priežastis buvo atvira saugykla ir silpnos prieigos patikros. Saugumo bendruomenė „Tea“ pateikia kaip ryškų pavyzdį: kai greitas paleidimas svarbesnis už prieigos patikrą, pirmiausia nuteka jautrūs duomenys.

Dar vienas praktinis pavyzdys. Pirminio autoriaus aprašytu atveju buvo įsilaužta į vibe coding kūrėjo programėlę, nes DI kuriant duomenų bazę nustatė numatytąjį slaptažodį, kurį buvo galima automatiškai atspėti. Tada sekė įprasta eiga: įsilaužėliai pateko į vidų, įdiegė kriptovaliutų kasimo programas ir perrašė projektą. Serverį teko visiškai išvalyti. Numatytojo slaptažodžio apsaugoti vartai – tai atrakintos durys su užrašu „užeikite“.

Du saugumo frontai: kur tiksliai esate pažeidžiami?#

Kalbėdami apie „vibe coding saugumą“, žmonės paprastai suplaka dvi visiškai skirtingas baimes. Atskirkime jas, nes nuo jų saugomasi skirtingais būdais.

Pirmasis frontas – pats agentas. Paleidžiate DI agentą kompiuteryje ir suteikiate jam prieigą prie failų, terminalo, raktų ir duomenų bazės. Rizika ta, kad agentas nėra žmogus: jis tiesiogiai vykdo instrukcijas ir renkasi trumpiausią kelią, net jei tas kelias pavojingas. Tai taip pat apima riziką, kad į agentą per jo skaitomą tekstą bus „įterpta“ kito žmogaus komanda (tai vadinama prompt injection).

Antrasis frontas – užbaigta programėlė. Tai, ką paskelbėte ir kuo žmonės naudojasi. Taikiniu tampa jūsų viešai paskelbta svetainė ar paslauga: užpuolikai patenka į atvirą duomenų bazę, siunčia netikras užklausas arba bando atspėti kitų žmonių paskyras. Agentas čia niekuo dėtas – spraga liko iš ankstesnio etapo ir ją išnaudoja kiti žmonės.

„Anthropic“, bendrovė, sukūrusi „Claude“, pagrindinį apsaugos principą nusako taip – jis tinka abiem frontams:

Praktiškai tai reiškia: nepasikliaukite tuo, kad DI „savaime vengs blogų veiksmų“. Pirmiausia apribokite, ką jis gali realiai padaryti, o tik tada prašykite elgtis tinkamai. Kai jo elgesys sutriks – o taip nutiks – jus apsaugos tik iš anksto nustatyta griežta riba.

Norite, kad DI veiktų nuspėjamai ir kiekviename naujame projekte nustotų šauti jums į koją? Saugumo taisyklės yra jūsų „Second Brain“ dalis: vieną kartą užrašykite jas faile CLAUDE.md, ir agentas jų laikysis vykdydamas kiekvieną užklausą.

Ką DI agentas gali daryti turėdamas prieigą prie jūsų kompiuterio?#

Labiausiai neįvertinama rizika – jūsų pačių agentas, turintis pernelyg plačias teises. Išorinio įsilaužėlio net nereikia. Štai naujausias pavyzdys iš 2026 m. gegužės pabaigos. „Codex“ agentui reikėjo administratoriaus teisių, kurių naudotojas neturėjo. Agentas nepasidavė – apsižvalgė, pastebėjo, kad naudotojas priklausė docker grupei, kuri iš esmės prilygsta root teisėms, ir tuo pasinaudojo.

Čia nebuvo jokių piktų kėslų. Tiesiog agentas, kuriam nurodyta „išspręsti užduotį“, struktūrinę silpną vietą randa greičiau nei žmogus. Jei dėl šios silpnos vietos jis gali pasiekti jūsų raktus ar gamybinę aplinką, jis tuo pasinaudos. Todėl pirmoji taisyklė – mažiausių privilegijų principas. Suteikite agentui tik tiek prieigos, kiek reikia konkrečiai užduočiai, ir nė trupučio daugiau.

Ką galite praktiškai padaryti, net jei nesate programuotojas?

1. Nepaleiskite agento režimu „leisti viską“ gamybinėje sistemoje

   Režimas, kai agentas neprašo patvirtinimo (dažnai vadinamas bypass arba yolo), skirtas tik smėlio dėžei ar bandomajam projektui, o ne kompiuteriui, kuriame laikomi darbiniai raktai ir yra prieiga prie gamybinės aplinkos.

2. Uždrauskite agentui skaityti paslaptis

   „Claude Code“ galite nustatyti taisyklę, kuri neleidžia pasiekti failų su raktais. Tada įrankis neleis agentui atidaryti .env, net jei jis to norės.

3. Gamybinius raktus laikykite atskirai

   Gamybinės duomenų bazės ir mokėjimo paslaugos raktai neturėtų būti tame pačiame aplanke, kuriame agentas rašo kodą. Aplinkas laikykite atskirai: eksperimentuodami naudokite bandomuosius raktus.

4. Naudokite įrankio smėlio dėžę

   Šiuolaikiniai DI įrankiai gali vykdyti komandas izoliuotoje aplinkoje (smėlio dėžėje), neturinčioje prieigos prie likusios sistemos. „Claude Code“ tai maždaug 84 procentais sumažina leidimų užklausų skaičių, todėl naudotis juo taip pat patogiau.

„Claude Code“ taisyklė, draudžianti skaityti paslaptis, atrodo maždaug taip – įrašykite ją į leidimų nustatymus:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Kur niekada nereikėtų laikyti API raktų ir slaptažodžių?#

Pigiausia ir dažniausia klaida – įrašyti raktus į kodą. Mokėjimo paslaugos API raktas, duomenų bazės slaptažodis, roboto žetonas – visa tai yra paslaptys. Jos turi būti atskirame .env faile, o šis failas privalo būti nurodytas .gitignore, kad kartu su kodu nepatektų į git.

Kodėl tai kritiška: viešoje saugykloje raktas ilgai neužsibūna. Botai visą parą skenuoja naujus commit. Toliau klostosi įprastas scenarijus: aptinkamas debesijos raktas, jūsų sąskaita paleidžiami kriptovaliutų kasimo serveriai, o ryte jūsų laukia dešimčių tūkstančių sąskaita. Kūrėjai tokius atvejus pasakoja nuolat, o sąskaitos siekia penkiaženkles dolerių sumas.

2025 m. problemos mastas: 28.65 milijono naujų viešose saugyklose tiesiai į kodą įrašytų paslapčių – 34 procentais daugiau nei praėjusiais metais. Specialiai DI paslaugoms skirtų raktų nutekėjimų padaugėjo 81 procentu. Vibe coding dar labiau pakursto problemą, nes agentas atlieka commit nepatikrinęs kodo.

Ką galite dabar patikrinti patys:

1. Atidarykite projekto .gitignore failą

   Įsitikinkite, kad jame yra eilutė .env. Jei jos nėra, įtraukite ją prieš atlikdami pirmą commit.

2. Atidarykite savo „GitHub“ saugyklą

   Patikrinkite, ar joje nėra .env failo. Greitai tai galite patikrinti saugykloje ieškodami .env arba dalies savo rakto.

3. Jei raktas nutekėjo, atšaukite jį ir išduokite naują

   Ištrinti commit nepakanka: raktas galėjo būti jau pavogtas. Eikite į paslaugos teikėjo paskyrą (mokėjimo, debesijos ar DI paslaugos), atšaukite seną raktą ir išduokite naują. Tai vadinama rakto rotacija.

4. Suteikite raktams mažiausias būtinas teises

   Jei raktas reikalingas tik skaitymui, nustatykite jį kaip skirtą tik skaityti. Net jam nutekėjus, pavogti bus galima mažiau.

Kodėl be RLS visi gali matyti jūsų duomenų bazę?#

Jei kuriate programėlę naudodami „Supabase“ ar panašią duomenų bazę, tai svarbiausia šio straipsnio dalis. RLS reiškia Row Level Security. Paprastai tariant, tai taisyklė, nustatanti, kurios lentelės eilutės rodomos konkrečiam naudotojui. Be jos lentelė „orders“ visiems pateikia visų klientų užsakymus.

Štai kaip tai aiškiai nusako pati „Supabase“ dokumentacija:

Vibe coding kūrėjams čia slypi pagrindiniai spąstai. Kai lentelę sukuriate spustelėdami „Supabase“ valdymo skydelyje, apsauga įjungiama automatiškai. Tačiau kai lentelę sukuria DI – o jis beveik visada tiesiogiai rašo SQL komandas – RLS lieka išjungtas pagal numatytuosius nustatymus. Tai reiškia, kad agento sukurta lentelė beveik neabejotinai yra atvira visam internetui. Būtent taip nutekėjo tų 170 „Lovable“ programėlių duomenys.

Ką daryti:

1. Tiesiai paklauskite agento

   Parašykite: „parodyk visas lenteles, kuriose RLS išjungtas“. DI pateiks sąrašą – tai jūsų darbų eilė.

2. Įjunkite RLS kiekvienoje lentelėje, kurioje saugomi naudotojų duomenys

   Ir pridėkite bent vieną prieigos politiką, pavyzdžiui, „naudotojas gali matyti tik savo eilutes“.

3. Patikrinkite valdymo skydelį

   „Supabase“ valdymo skydelyje prie kiekvienos lentelės turėtų būti rodoma „RLS enabled“. Jei žyma pilka arba raudona, lentelė atvira.

4. Išbandykite iš tikrųjų

   Prisijunkite kaip įprastas naudotojas ir pabandykite pateikti užklausą dėl kito asmens duomenų. Jei prieiga atmetama, politika veikia.

Kodėl sąsajos leidimų patikros jūsų neapsaugo?#

Dažna klaidinga nuostata: „Pasirūpinau, kad įprasti naudotojai nematytų administratoriaus mygtuko.“ Problema ta, kad mygtukas tėra paveikslėlis naršyklėje. Užklausą galima siųsti tiesiai į serverį mygtuko nenaudojant. Jei serveris dar kartą nepatikrina leidimų, jis įvykdys kieno nors kito komandą.

Klasikinis pavyzdys vadinamas IDOR. Įsivaizduokite, kad atidarote savo užsakymą adresu su id=123. Pakeiskite jį į id=124 ir galėsite matyti kito žmogaus užsakymą, nes serveris nepatikrino, ar tai iš tiesų jūsų užsakymas. Tai viena dažniausių vibe coding būdu sukurtų programėlių spragų, o silpnos leidimų patikros prisidėjo prie „Tea“ duomenų nutekėjimo.

Taisyklė paprasta: kiekvieną patikrą „ar šiam naudotojui leidžiama tai atlikti?“ pakartokite serveryje. Sąsaja skirta patogumui, o apsauga priklauso backend. Agentui skirtas paruoštas nurodymas: „pridėk serverio pusės leidimų patikras kiekvienam endpoint, kuris skaito arba keičia naudotojų duomenis; nepasikliauk tuo, kad sąsajoje paslėptas elementas“.

Kaip patikrinti, ar kode nėra spragų, jei nesate programuotojas?#

Gera žinia: šiandien galite paprašyti to paties DI patikrinti saugumą – jis neblogai randa įprastas spragas. Štai trys skirtingoms užduotims skirti įrankiai.

1. Komanda /security-review „Claude Code“. Vienkartinė dabartinio branch patikra dėl SQL injection, XSS, autorizavimo spragų, duomenų nutekėjimo ir priklausomybių problemų. Atskirame „Claude Code“ saugumo patikros vadove žingsnis po žingsnio paaiškinau, kaip ji veikia ir kaip prie kiekvieno pakeitimo pridėti automatinę patikrą. Svarbiausia: tai pirmoji gynybos linija, paleidžiama viena komanda.

2. Oficialus security-guidance papildinys. Įdiekite jį iš oficialios papildinių prekyvietės komanda /plugin install security-guidance@claude-plugins-official (reikalinga „Claude Code“ 2.1.144 arba naujesnė versija). Jis tikrina kodą trimis momentais: po kiekvieno pakeitimo, kiekvieno turn pabaigoje ir atliekant commit. Jis aptinka autorizavimo apėjimą, IDOR, injekcijas ir silpną kriptografiją. Tačiau „Anthropic“ atvirai nurodo jo ribas:

npx skills add <author>/<repo>

Tada tiesiog pasakykite agentui: „patikrink mano projektą, ar jame nėra pažeidžiamumų“. Tačiau šis rinkinys turi svarbią išlygą, todėl toliau jam skirta atskira dalis.

Kontekstui: didieji rinkos dalyviai taip pat pradėjo rimtai vertinti DI kodo saugumą. Vykdant Project Glasswing, kuris 2026 m. birželio 2 d. buvo išplėstas ir įtraukė 150 organizacijų, partneriai per trumpą laiką, naudodami „Anthropic“ modelius, aptiko daugiau nei 10,000 kritinių pažeidžiamumų. Statymai aiškūs:

Ar galima pasitikėti „GitHub“ įgūdžiais ir plėtiniais?#

Čia situacija tampa ypač kebli, nes pavojų kelia saugumui skirtas įrankis, kurį patys įdiegiate. Kai paleidžiate npx skills add ... arba įdiegiate plėtinį, atsisiunčiate kito žmogaus kodą, kurį agentas paleidžia su jūsų teisėmis. Jei autorius buvo nulaužtas arba paketas nuo pat pradžių buvo kenkėjiškas, turite problemą.

Pažvelkime į ankstesniame skyriuje minėtą įgūdžių rinkinį. Jo pavadinime yra „Anthropic“, todėl galite prarasti budrumą. Tačiau pačiame apraše aiškiai parašyta:

Kitaip tariant, pavadinimas klaidina. Pats rinkinys šiuo metu yra brandus ir švarus, tačiau principas išlieka: diegiate jį savo rizika. Grėsmė nėra teorinė. 2026 m. gegužę kenkėjiškas redaktoriaus plėtinys prekyvietėje išbuvo vos 18 minučių, bet per tą laiką spėjo iš savo diegėjų pavogti slaptažodžių tvarkyklių slaptažodžius, „GitHub“ žetonus, prieigą prie debesijos ir net „Claude Code“ konfigūracijas. Dar viena nemaloni detalė: tokia kenkėjiška programa dažnai išlieka įprastai pašalinus paketą ir vėl paleidžiama kitoje sesijoje.

Pats laikausi paprasto įpročio ir rekomenduoju jį jums: prieš diegdami bet kokį įgūdį iš „GitHub“, patikrinkite jį patys. Autoriai gali būti nulaužti, paskyros užgrob tos, o kenkėjiška programa gali patekti į saugyklą. Patikra yra jūsų apsauga.

Praktinis minimumas prieš diegiant: peržiūrėkite autorių ir žvaigždučių skaičių, perskaitykite įgūdžio aprašą, nediekite įrankio „nes kažkas jį rekomendavo viename įraše“, o nepažįstamą įrankį pirmiausia išbandykite atskiroje testavimo aplinkoje, ne kompiuteryje su gamybiniais raktais.

Kas padės po pažeidimo: atsarginės kopijos ir grįžimas į ankstesnę būseną#

Saugumas – tai ne tik „neįleisti pašalinių“, bet ir „sugrįžti į įprastą būseną, kai kas nors nutinka“. Nes kas nors nutiks. Aprašytu praktiniu atveju DI agentas, atlikdamas įprastą užduotį gamybiniame projekte, ištrynė veikiančią duomenų bazę. Atsarginė kopija buvo, tačiau trijų dienų senumo – ir tiesiog dingo trijų dienų duomenys.

Iš to kyla dvi taisyklės.

Dažnai kurkite atsargines kopijas. Jei programėlėje yra duomenų, kurių nenorėtumėte prarasti, kopija kas tris dienas yra tik apsaugos iliuzija. Nustatykite automatines kopijas bent kas 30 minučių. Daugumoje duomenų bazių, įskaitant „Supabase“, tai galima įjungti keliais spustelėjimais.

Git yra draudimas nuo agento klaidų. Git saugo jūsų kodo istoriją: galite atkurti bet kurią veikusią būseną. Kai agentas perrašo tai, kas veikė, grįžtate į paskutinę veikusią versiją, užuot taisę rankomis. Jei DI ištrynė arba sugadino projektą ir nežinote, kaip jį atkurti, skaitykite atskirą analizę: ką daryti, jei DI ištrynė duomenų bazę. Kaip iš anksto apsaugoti projektą nuo sugadinimo, aprašyta vadove kaip apsaugoti „Claude Code“ nuo sugadinimo.

Saugumo kontrolinis sąrašas prieš publikavimą#

Prieš pat publikavimą paeiliui pereikite šį sąrašą.

1. Paslaptys .env faile, o .env – .gitignore. Kode nėra raktų. Viešoje saugykloje nėra .env failo.

2. Raktai su mažiausiomis teisėmis. Kiekvienas raktas gali atlikti tik tai, ko reikia. Gamybiniai raktai atskirti nuo agento aplinkos.

3. RLS įjungtas visose lentelėse su naudotojų duomenimis ir nustatytos prieigos politikos.

4. Serverio pusės leidimų patikros kiekvienai duomenų operacijai. Sąsajoje paslėpti mygtuką nepakanka. Rankiniu būdu patikrinote, kas nutinka adrese pakeitus id.

5. Webhook parašo tikrinimas. Kiekvienas išorinių pranešimų apdorojimo modulis (mokėjimai, formos) tikrina parašą.

6. Užklausų dažnio ribojimas gaunamoms užklausoms ir brangioms operacijoms, kad slaptažodžių nebūtų galima atspėti brutalia jėga ir nebūtų išpūsta jūsų sąskaita.

7. Agentas neveikia režimu „leisti viską“ kompiuteryje su gamybiniais raktais. Skaityti .env neleidžiama.

8. Atsarginės kopijos kuriamos dažnai ir yra išbandytos – iš tiesų bandėte atkurti duomenis, o ne tik tikite, kad kopijos „kažkur yra“.

9. Kodas patikrintas naudojant /security-review arba security-guidance papildinį. Rasti trūkumai ištaisyti.

10. Prieš diegimą patikrinti kitų žmonių įgūdžiai ir plėtiniai. Nieko neįdiegėte „aklai“.

Nuo ko pradėti šiandien#

Nesistenkite vieną vakarą įgyvendinti visko iš šio vadovo – galiausiai nepadarysite nieko. Šiandien atlikite tris svarbiausius veiksmus:

1. Patikrinkite savo paslaptis. Atidarykite .gitignore, įsitikinkite, kad jame nurodytas .env, ir patikrinkite, ar viešoje saugykloje nėra raktų. Jei jų nutekėjo, atšaukite ir išduokite naujus.
2. Paklauskite apie RLS. Pasakykite agentui: „parodyk lenteles, kuriose RLS išjungtas“ – ir įjunkite jį visur, kur saugomi žmonių duomenys.
3. Nustatykite dažną atsarginių kopijų kūrimą. Jei kas nors nutiks, prarasite minutes, o ne dienas.

Toliau laikykitės anksčiau pateikto kontrolinio sąrašo projektui augant ir pradedant tvarkyti pinigus bei kitų žmonių duomenis.

Dar vienas dalykas. Vibe coding saugumas yra savininko atsakomybė. Jums nereikia tapti saugumo ekspertu. DI per vieną vakarą sukūrė jūsų produktą – puiku, bet už jį atsakote jūs. Būtent taip praktiškai atrodo šiame vadove aprašytas bazinis atsakomybės lygis.

Jei norite toliau dirbti su modeliais, apsilankykite Ailoot.