Vibe Coding қауіпсіздігі: ЖИ жасаған қолданбаны қалай қорғауға болады

Ailoot-пен жұмыс істеу жөніндегі қосымша нұсқаулар құжаттамада берілген.

ЖИ көмегімен жасалған қолданбалар неге жиірек бұзылады?#

Мен де ЖИ көмегімен өнімдер жасаймын және қауіпсіздікке бола бәрін «барынша жауып тастайтындай» үрейленбеймін. Бірақ төмен түсуге болмайтын негізгі деңгей бар. Әйтпесе бір күні оянып, дерекқорыңыздың бос қалғанын, серверіңізде басқа біреудің криптомайнерлері жұмыс істеп тұрғанын көресіз. Бұл нұсқаулық сол негізгі деңгей туралы. «Қауіпсіздік сарапшысы бол» емес, «себепсіз өзіңе зиян келтірме» дегені.

Мәселенің түп негізі қарапайым. ЖИ агентіне «клиенттерге жазылуға арналған қолданба жасап бер» десеңіз, ол қолданбаны барынша тез жұмыс істейтіндей жасайды. Қауіпсіздік — демода көрінбейтін қосымша жұмыс. Сондықтан дерекқор ашық күйде бапталады, төлем кілті кодқа тікелей жазылады, ал «бұл пайдаланушының кіруге рұқсаты бар ма?» деген тексеріс тек браузерде болады. Оны бір секундта айналып өтуге болады.

Екінші себеп — платформалардың өзі. 2026 жылғы мамырда осы қолданбаларды сканерлеген зерттеу мұны былай түсіндіреді:

Басқаша айтқанда, осалдық өздігінен, әдепкіде пайда болады. Сіз ештеңені қате істеген жоқсыз. Тек ештеңе істемедіңіз — ал қауіпсіздік саласында әрекетсіздік дегеніміз «бәріне ашық» деген сөз.

Үшінші қыры да бар. ЖИ құпияларды адамға қарағанда жиірек жария етіп қоюы мүмкін. Себебі түсінікті: агент git add . және git push командаларын тексермей орындайды, сөйтіп кілттері бар .env файлы қалғанының бәрімен бірге жария болып кетеді.

Vibe-coding жасаушылар қандай қателіктерден ащы сабақ алды?#

Ұқыпсыздықтан сақтанудың ең жақсы жолы — басқа адамдардың қателерінен үйрену. Жобаңызды жарияламай тұрып қарауға тұрарлық төрт есепті ұсынамын.

Lovable және өшірулі RLS. Lovable платформасы мәтіндік сипаттамалардан қолданбалар жасайды. 2025 жылы оның қолданбаларынан жүйелік осалдық табылып, CVE-2025-48757 нөмірі берілді. Себебі: жасалған қолданбаларда дерекқор деңгейіндегі жолдарға қол жеткізу ережелері (төменде түсіндірілген RLS) болмаған. Зерттеуші үлгіні тексеріп, 170 қолданбадан 303 ашық кіру нүктесін тапты. Аты-жөндер, телефон нөмірлері, төлем мәртебелері, басқа адамдардың API кілттері, тіпті үй мекенжайлары жария болды. Тексерілген қолданбалардың шамамен 70 пайызында жол деңгейіндегі қорғаныс мүлдем өшірулі болған.

Tea және құпия деректер. Адамдарға анонимді пікір жазуға арналған Tea қолданбасынан 2025 жылғы шілдеде шамамен 72,000 сурет, соның ішінде 13,000 селфи мен құжат фотосы, кейін миллионнан астам жеке хабарлама тарап кетті. Техникалық себептері — ашық сақтау орны және әлсіз қолжетімділік тексерістері. Қауіпсіздік қауымдастығы Tea-ны көрнекі мысал ретінде келтіреді: рұқсаттарды тексеруден гөрі тез іске қосу маңызды болса, алдымен құпия деректер тарап кетеді.

Тағы бір тәжірибелік мысал. Бастапқы автор сипаттаған жағдайда vibe-coder-дің қолданбасы бұзылған: ЖИ дерекқор жасаған кезде автоматты құпиясөз орнатқан, оны автоматты түрде табуға болатын. Содан кейін әдеттегі оқиғалар тізбегі болған: жүйеге кіріп, майнерлер орнатқан да, жобаны қайта жазған. Серверді толығымен тазалауға тура келген. Әдепкі құпиясөз — «кіріңіз, есік ашық» деген жазуы бар құлыпталмаған есік.

Қауіпсіздіктің екі бағыты: нақты қай жерден осалсыз?#

«Vibe-coding қауіпсіздігі» туралы айтқанда, әдетте мүлдем бөлек екі қауіп бір ұғымға біріктіріледі. Оларды ажыратып алайық, өйткені олардан әртүрлі жолмен қорғанасыз.

Бірінші бағыт — агенттің өзі. Компьютеріңізде ЖИ агентін іске қосып, оған файлдарыңызға, терминалға, кілттерге және дерекқорға қолжетімділік бересіз. Қауіп мынада: агент адам емес, ол нұсқауларды сөзбе-сөз орындайды және қауіпті болса да, ең қысқа жолды табады. Бұған агент оқитын мәтін арқылы басқа біреудің пәрменін «енгізу» қаупі де кіреді (бұл prompt injection деп аталады).

Екінші бағыт — дайын қолданба. Бұл — жариялаған және адамдар пайдаланатын нәрсе. Нысана — жарияланған сайтыңыз немесе қызметіңіз: шабуылдаушылар ашық дерекқорға кіреді, жалған сұраулар жібереді немесе басқа адамдардың аккаунттарын болжайды. Агенттің бұған қатысы жоқ — осалдық бұрынырақта қалдырылған, оны басқа адамдар пайдаланады.

Claude жасаған Anthropic компаниясы қорғаныстың негізгі қағидасын былай түсіндіреді. Бұл қағида екі бағытқа да жарайды:

Іс жүзінде бұл «ЖИ өздігінен жаман нәрсе жасамайды» деп сенбеуді білдіреді. Алдымен оның нақты не істей алатынын шектеп, содан кейін ғана өзін дұрыс ұстауын сұраңыз. Оның әрекеті дұрыс болмай қалған кезде — ал олай болады — алдын ала қойған қатаң шекара ғана сізді қорғайды.

ЖИ әр жаңа жобада өзін болжамды ұстап, сізге зиян келтірмеуін қалайсыз ба? Қауіпсіздік ережелері — Second Brain жүйеңіздің бөлігі: оларды CLAUDE.md файлына бір рет жазып қойсаңыз, агент әр сұрауда соларды орындайды.

Компьютеріңізге қолжетімділігі бар ЖИ агенті не істей алады?#

Ең аз бағаланатын қауіп — тым кең рұқсаты бар өз агентіңіз. Сырттан хакердің қажеті де жоқ. Міне, мамырдың соңында болған жақындағы мысал. Codex агентіне пайдаланушыда жоқ әкімші рұқсаттары керек болған. Агент берілмей қоймаған: айналасына қарап, пайдаланушының docker тобына кіретінін байқаған. Бұл топтың рұқсаты root рұқсатымен іс жүзінде бірдей. Сөйтіп сол қолжетімділікті пайдаланған.

Мұнда жаман ниет болған жоқ. «Тапсырманы шеш» деген нұсқау алған агент құрылымдық әлсіздікті адамнан жылдамырақ табады. Ал әлсіздік оған кілттеріңізге немесе өндірістік ортаға қолжетімділік берсе, оны пайдаланады. Сондықтан бірінші ереже — ең аз артықшылық қағидасы. Агентке нақты бір тапсырмаға қажет қолжетімділікті ғана беріңіз, одан артық ештеңе бермеңіз.

Бұл менің қиялым емес. Джонс Хопкинс университетінің зерттеушілері Anthropic, Google және Microsoft компанияларының өндірістік агенттеріне шабуыл жасады. Олардың қорытындысы өте айқын:

Бағдарламашы болмасаңыз да, іс жүзінде не істей аласыз?

1. Өндірістік машинада агентті «бәріне рұқсат» режимінде іске қоспаңыз

   Агент растауды сұрамайтын режим (көбіне bypass немесе yolo деп аталады) тек құмсалғышқа немесе сынақ жобасына арналған. Жұмыс істейтін кілттері мен өндірістік рұқсаты бар машинаға арналмаған.

2. Агенттің құпия деректерді оқуына тыйым салыңыз

   Claude Code ішінде мұны кілттері бар файлдарға қолжетімділікке тыйым салатын ережемен орындайсыз. Сонда агент .env файлын ашқысы келсе де, құрал оған рұқсат бермейді.

3. Өндірістік кілттерді бөлек сақтаңыз

   Өндірістік дерекқор мен төлем қызметінің кілттері агент код жазатын қалтада болмауы керек. Орталарды бөлек ұстаңыз: тәжірибе жасап жатқанда test кілттерін пайдаланыңыз.

4. Құралдың құмсалғышын пайдаланыңыз

   Заманауи ЖИ құралдары командаларды оқшауланған ортада (құмсалғышта) іске қоса алады; ол ортада жүйенің қалған бөлігіне қолжетімділік болмайды. Claude Code ішінде бұл рұқсат сұрауларын шамамен 84 пайызға азайтады — яғни пайдалану да ыңғайлырақ.

Claude Code ішінде құпия деректерді оқуға тыйым салатын ереже шамамен мынадай болады. Оны рұқсат баптауларына енгізіңіз:

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

API кілттері мен құпиясөздерді қайда ешқашан сақтауға болмайды?#

Ең арзан әрі жиі кездесетін қате — кілттерді кодқа жазу. Төлем қызметінің API кілті, дерекқордың құпиясөзі, бот токені — мұның бәрі құпия дерек. Олар бөлек .env файлында болуы керек, ал кодпен бірге git-ке кетпеуі үшін бұл файл .gitignore тізіміне қосылуға тиіс.

Мұның неге маңызды екені түсінікті: кілт жалпыға ашық репозиторийде ұзақ тұрмайды. Боттар жаңа коммиттерді тәулік бойы сканерлейді. Одан кейін әдеттегі оқиғалар тізбегі жүреді: олар бұлт кілтін тауып, сіздің есебіңізден криптовалюта өндіретін серверлер іске қосады, ал таңертең он мыңдаған долларлық шот алдыңыздан шығады. Әзірлеушілер мұндай оқиғаларды жиі айтады, ал шоттар бес таңбалы долларға жетеді.

2025 жылғы мәселе ауқымы: жалпыға ашық репозиторийлерде жаңадан пайда болған, кодқа тікелей жазылған 28.65 million құпия дерек; бұл өткен жылмен салыстырғанда 34 пайызға көп. ЖИ қызметтеріне арналған кілттердің жария болуы 81 пайызға өсті. Vibe-coding жағдайды ушықтырады, өйткені агент коммитті тексермей жасайды.

Дәл қазір қолмен тексеретін нәрселер:

1. Жобаңыздың .gitignore файлын ашыңыз

   Онда .env жолы бар екеніне көз жеткізіңіз. Жоқ болса, бірінші коммитке дейін қосыңыз.

2. GitHub репозиторийіңізге өтіңіз

   .env файлы онда жоқ екенін тексеріңіз. Репозиторийден .env файлын немесе кілтіңіздің бір бөлігін іздеу — мұны тексерудің жылдам жолы.

3. Кілт жария болып кетсе, күшін жойып, жаңасын шығарыңыз

   Коммитті өшіру жеткіліксіз: кілтті әлдеқашан алып қойған болуы мүмкін. Қызметке (төлем провайдеріне, бұлт қызметіне немесе ЖИ провайдеріне) кіріп, ескі кілттің күшін жойыңыз да, жаңасын шығарыңыз. Бұл ротация деп аталады.

4. Кілттерге ең аз рұқсат беріңіз

   Егер кілт тек оқуға қажет болса, оны тек оқуға рұқсат беретіндей етіңіз. Сонда жария болып кетсе де, ұрланатын нәрсе аз болады.

RLS болмаса, дерекқорыңызды бәрі неге көре алады?#

Егер Supabase немесе соған ұқсас дерекқорда қолданба жасап жатсаңыз, бұл — ең маңызды бөлім. RLS дегеніміз Row Level Security, яғни жол деңгейіндегі қауіпсіздік. Қарапайым тілмен айтқанда, кестедегі қай жолдар белгілі бір пайдаланушыға көрсетілетінін анықтайтын ереже. Онсыз «тапсырыстар» кестесі әр клиенттің тапсырысын бәріне көрсетеді.

Supabase құжаттамасы мұны былай ашық айтады:

Vibe-coder үшін негізгі тұзақ мынада. Supabase бақылау тақтасында басу арқылы кесте жасасаңыз, қорғаныс автоматты түрде қосылады. Ал кестені ЖИ жасағанда — ол SQL командаларын тікелей жазады деуге болады — RLS әдепкіде өшірулі қалады. Демек, агент жасаған кесте интернеттің бәріне дерлік ашық болады. Lovable-дың 170 қолданбасынан дерек дәл осылай тарап кеткен.

Не істеу керек:

1. Агенттен тікелей сұраңыз

   «RLS өшірулі тұрған барлық кестені көрсет» деп жазыңыз. ЖИ тізім жасайды — бұл сіздің жұмыс тізіміңіз.

2. Пайдаланушы деректері бар әр кестеде RLS қосыңыз

   Кемінде бір қолжетімділік саясатын да қосыңыз — мысалы, «пайдаланушы тек өз жолдарын көре алады».

3. Бақылау тақтасын тексеріңіз

   Supabase бақылау тақтасында әр кестеде «RLS enabled» деп көрсетілуі керек. Сұр не қызыл болса, кесте ашық деген сөз.

4. Іс жүзінде тексеріңіз

   Қарапайым пайдаланушы ретінде кіріп, басқа біреудің дерегін сұрап көріңіз. Қолжетімділік берілмесе, саясат жұмыс істеп тұр.

Интерфейстегі рұқсат тексерістері неге қорғамайды?#

«Қарапайым пайдаланушылар әкімші түймесін көрмейтіндей еттім» деген түсінік жиі кездеседі. Мәселе мынада: түйме — браузердегі жай сурет. Түймені пайдаланбай-ақ серверге тікелей сұрау жіберуге болады. Сервер рұқсаттарды қайта тексермесе, басқа біреудің пәрменін орындайды.

IDOR деп аталатын классикалық мысалды алайық. id=123 мекенжайы арқылы тапсырысыңызды аштыңыз делік. Оны id=124 деп өзгертсеңіз, сервер бұл тапсырыс сіздікі ме деп тексермегендіктен, басқа біреудің тапсырысын көре аласыз. Бұл — vibe-coding қолданбаларындағы ең жиі осалдықтардың бірі, ал әлсіз рұқсат тексерістері Tea деректерінің тарауына себеп болған.

Ереже қарапайым: «бұл пайдаланушы мұны істей ала ма?» деген әр тексерісті серверде қайталаңыз. Интерфейс ыңғайлылық үшін керек, ал қорғаныс backend жағында болуы тиіс. Агентке дайын нұсқау: «пайдаланушы деректерін оқитын немесе өзгертетін әр endpoint үшін сервер жағында рұқсат тексерістерін қос; интерфейсте элементті жасыруға сенбе».

Бағдарламашы болмасаңыз, кодтағы осалдықтарды қалай тексеруге болады?#

Жақсы жаңалық: бүгінде қауіпсіздікті тексеруді сол ЖИ-ден сұрауға болады — ол жиі кездесетін осалдықтарды табуды жаман орындамайды. Әртүрлі міндетке арналған үш құрал ұсынамын.

1. Claude Code ішіндегі /security-review командасы. Ағымдағы тармақты SQL injection, XSS, рұқсат осалдықтары, дерек ағуы және тәуелділік мәселелері бойынша бір рет тексереді. Оның қалай жұмыс істейтінін және әр өзгеріске автоматты тексеріс қосуды Claude Code ішіндегі қауіпсіздік тексерісі туралы бөлек нұсқаулықта кезең-кезеңімен түсіндірдім. Мұндағы негізгі ой: бұл — бір командамен іске қосылатын алғашқы қорғаныс желісі.

2. Ресми security-guidance плагині. Оны ресми плагиндер дүкенінен /plugin install security-guidance@claude-plugins-official командасымен орнатыңыз (Claude Code 2.1.144 немесе одан кейінгі нұсқасы қажет). Ол кодты үш кезеңде тексереді: әр өңдеуде, әр кезектің соңында және коммит кезінде. Рұқсатты айналып өту әрекеттерін, IDOR, инъекцияларды және әлсіз криптографияны анықтайды. Бірақ Anthropic оның шектеулері туралы ашық айтады:

npx skills add <author>/<repo>

Содан кейін агентке «жобамды осалдықтарға тексер» деп айтыңыз. Бірақ бұл жинаққа қатысты маңызды ескерту бар; сондықтан төменде оған жеке бөлім арнадым.

Мәлімет үшін: ірі ойыншылар да ЖИ кодының қауіпсіздігіне байыппен қарай бастады. 2026 жылғы 2 маусымда 150 ұйымды қамту үшін кеңейтілген Project Glasswing аясында серіктестер Anthropic модельдерін қолданып, аз уақыт ішінде 10,000-нан астам маңызды осалдық тапты. Қауіптің ауқымы анық:

GitHub-тағы дағдылар мен кеңейтімдерге сенуге бола ма?#

Әсіресе қиын тұсы осы, өйткені қауіпсіздік үшін орнататын құралдың өзінен қауіп төнеді. npx skills add ... командасын орындағанда немесе кеңейтім орнатқанда басқа біреудің кодын жүктеп аласыз; агент оны сіздің рұқсаттарыңызбен іске қосады. Автордың аккаунты бұзылса немесе пакет әуелден зиянды болса, қиындыққа тап боласыз.

Алдыңғы бөлімдегі дағдылар жинағын алайық. Оның атауында «Anthropic» сөзі бар, сондықтан сақтықты азайтуыңыз мүмкін. Алайда оның сипаттамасында анық жазылған:

Басқаша айтқанда, атауы жаңылыстыруы мүмкін. Жинақтың өзі қазір жетілген әрі таза, бірақ қағида өзгермейді: оны өз тәуекеліңізбен орнатасыз. Ал қауіп теориялық емес. 2026 жылғы мамырда зиянды редактор кеңейтімі дүкенде небәрі 18 минут тұрды. Осы уақыт ішінде оны орнатқандардың құпиясөз менеджерлерінен құпиясөздерді, GitHub токендерін, бұлтқа қолжетімділікті, тіпті Claude Code конфигурацияларын ұрлап үлгерді. Тағы бір жағымсыз жайт: мұндай зиянды бағдарлама пакетті әдеттегідей жойғаннан кейін де жиі қалып, келесі сеанста қайта іске қосылады.

Өзіме мынадай қарапайым әдет қалыптастырдым, сізге де ұсынамын: GitHub-тан кез келген дағды орнатпас бұрын оны өзіңіз тексеріңіз. Авторлардың аккаунттарын бұзуы, аккаунттардың қолға түсуі, репозиторийге зиянды бағдарлама енуі мүмкін. Тексеру — сіздің қорғанысыңыз.

Орнатпас бұрынғы ең аз тексеріс: автор мен жұлдыз санын қараңыз, дағды сипаттамасын оқыңыз, «бір жазбада ұсынған екен» деп құрал орнатпаңыз; бейтаныс құралды алдымен өндірістік кілттері бар машинада емес, бөлек сынақ ортасында байқап көріңіз.

Бұзылғаннан кейін не құтқарады: сақтық көшірмелер мен кері қайтару#

Қауіпсіздік — тек «сырттан кіруге жол бермеу» емес, «бірдеңе қате кеткенде қалыпты күйге оралу» да. Өйткені бірдеңе қате кетеді. Сипатталған тәжірибелік жағдайда ЖИ агенті өндірістік жобадағы жұмыс істеп тұрған дерекқорды әдеттегі тапсырманы орындап жатып жойған. Сақтық көшірме болған, бірақ ол үш күн бұрын жасалған — үш күндік дерек жоғалып кеткен.

Бұдан екі ереже шығады.

Жиі сақтық көшірме жасаңыз. Қолданбаңызда жоғалтқыңыз келмейтін дерек болса, үш күнде бір көшірме жасау қорғаныс бар деген жалған түсінік береді. Автоматты сақтық көшірмені кемінде әр 30 минут сайын жасалатындай баптаңыз. Supabase қоса алғанда, көптеген дерекқорда мұны екі-үш рет басып қосуға болады.

Git — агенттен сақтандыру. Git код тарихын сақтайды: жұмыс істеп тұрған кез келген күйді қалпына келтіре аласыз. Агент жұмыс істеген нәрсені қайта жазғанда, оны қолмен түзетпей-ақ соңғы жұмыс істеген нұсқаға қайтарасыз. ЖИ жобаны жойып не бұзып, оны қалай қалпына келтіруді білмесеңіз, бөлек есепті қараңыз: ЖИ дерекқорды жойып жіберсе не істеу керек. Жоба бұзылуының алдын алу жолын Claude Code-ты бұзылудан қалай қорғауға болады нұсқаулығынан қараңыз.

Жарияламас бұрынғы қауіпсіздік тексеру тізімі#

Жариялар алдында осы тізімнен ретімен өтіңіз.

1. Құпия деректер .env файлында, ал .env .gitignore ішінде. Кодта кілттер жоқ. Жалпыға ашық репозиторийде .env файлы жоқ.

2. Кілттерге ең аз рұқсат берілген. Әр кілт тек қажет әрекеттерді орындай алады. Өндірістік кілттер агент ортасынан бөлек.

3. Пайдаланушы деректері бар барлық кестеде RLS қосылған, қолжетімділік саясаты орнатылған.

4. Дерекпен жасалатын әр әрекетке серверлік рұқсат тексерістері бар. Интерфейсте түймені жасыру жеткіліксіз. Мекенжайдағы id мәнін өзгертіп, қолмен тексерілген.

5. Webhook қолтаңбасы тексеріледі. Сырттан келетін әр хабарламаны өңдеуші (төлемдер, пішіндер) қолтаңбаны тексереді.

6. Кіріс сұраулар мен қымбат операцияларға rate limiting қойылған, осылайша құпиясөздерді күшпен болжай алмайды және шотыңызды өсіре алмайды.

7. Агент өндірістік кілттері бар машинада «бәріне рұқсат» режимінде жұмыс істемейді. .env файлын оқуға тыйым салынған.

8. Сақтық көшірмелер жиі жасалады және тексерілген — көшірмелер «бір жерде бар» деп сенумен шектелмей, олардан қалпына келтіріп көрдіңіз.

9. Код /security-review немесе security-guidance плагині арқылы тексерілген. Табылған мәселелер түзетілген.

10. Басқа адамдардың дағдылары мен кеңейтімдері орнатылмас бұрын тексерілген. Ештеңе «соқыр түрде» орнатылмаған.

Бүгін неден бастау керек?#

Бұл нұсқаулықтағының бәрін бір кеште іске асыруға тырыспаңыз — ақырында ештеңе істемей қаласыз. Бүгінге арналған ең маңызды үш қадамды орындаңыз:

1. Құпия деректеріңізді тексеріңіз. .gitignore файлын ашып, .env қосылғанына көз жеткізіңіз, жалпыға ашық репозиторийде кілттер жоқ екенін тексеріңіз. Біреуі жария болып кетсе, күшін жойып, жаңасын шығарыңыз.
2. RLS туралы сұраңыз. Агентке «RLS өшірулі тұрған кестелерді көрсет» деңіз де, адамдардың деректері сақталған жерлердің бәрінде оны қосыңыз.
3. Жиі сақтық көшірме жасауды баптаңыз. Бірдеңе қате кетсе, күн емес, минут жоғалту үшін.

Содан кейін жобаңыз кеңейіп, ақша мен басқа адамдардың деректерін өңдей бастаған сайын жоғарыдағы тексеру тізімін орындаңыз.

Соңғы бір нәрсе. Vibe-coding қауіпсіздігі — иесінің жауапкершілігі. Қауіпсіздік сарапшысы болудың қажеті жоқ. ЖИ өніміңізді бір кеште жасап берді — керемет, бірақ оның жауапкершілігі сізде. Осы нұсқаулықтағы негізгі деңгей — сол жауапкершіліктің іс жүзіндегі көрінісі.

Жобаны қауіпсіз басынан дұрыс жасау үшін қауіпсіздік ережелерін әдістемеге енгізіңіз.

Модельдермен әрі қарай жұмыс істеу үшін Ailoot сайтына өтуіңізге болады.