Sunʼiy intellekt yozgan kod xavfsizligi: odatiy nuqsonlar va reviewda nimani tekshirish kerak

Nega SI kodining oʻziga xos zaifliklari bor

Til modeli oʻqitish maʼlumotlarida koʻp uchragan narsani takrorlaydi. Ochiq kodda esa qisqalik uchun xavfsizlik ataylab tushirib qoldirilgan oʻquv misollari va bir paytlar meʼyor boʻlgan eskirgan yechimlar koʻp. Model sizning tahdidlar modelingizni, kirish qoidalaringizni va qaysi kutubxona versiyalari oʻrnatilganini bilmaydi.

Ikkinchi sabab — ishonch. Kod ozoda koʻrinadi, izohlar bilan taʼminlangan va oʻsha agent yozgan testlardan oʻtadi. Shu sababli tekshiruvchi boʻshashadi va hamkasbining shoshma-shosharlik bilan yozilgan kodida payqaydigan narsani oʻtkazib yuboradi.

Uchinchisi — agent noqulay savollarni kamdan-kam beradi. «Foydalanuvchilar roʻyxatini eksport qilish» vazifasini olgan odam bu eksport kimga ochiq boʻlishi va unga qaysi maydonlarni kiritish mumkin emasligini soʻraydi. Agent esa koʻpincha shunchaki eksportni qilib qoʻyadi. Shuning uchun xavfsizlik talablarini vazifada aniq yozish yoki agent doim oʻqiydigan loyiha qoidalarida mustahkamlash kerak.

Tahdidlar modeli: muammolar qayerdan keladi

Xatarning uchta manbasini ajratish foydali, chunki ularning har biriga qarshi turli vositalar ishlaydi. Ularni aralashtirsangiz, bittasini yopib, qolgan ikkitasini ochiq qoldirish oson.

• Kodning oʻzidagi nuqsonlar. Model zaif mantiq yozgan: inyeksiya, tushib qolgan ruxsat tekshiruvi, xavfsiz boʻlmagan sozlama. Bunga qarshi — review, testlar va statik tahlil.
• Taʼminot zanjiri. Model taklif qilgan bogʻliqliklar orqali loyihaga begona kod tushadi. Bunga qarshi — paketlarni tekshirish, lock-fayllar va bogʻliqlik skanerlari.
• Agentning oʻzi. Repozitoriy, terminal va tarmoqqa kirish huquqi bor vosita xato tufayli yoki maʼlumotlardagi zararli koʻrsatmalar taʼsirida ortiqcha ish qilishi mumkin. Bunga qarshi — minimal huquqlar va izolyatsiya.

Quyida nuqsonlarning har bir sinfini koʻrib chiqamiz, oxirida esa ularni jarayon va nazorat roʻyxatiga yigʻamiz.

Toʻqib chiqarilgan va almashtirilgan bogʻliqliklar

Bu qanday yuzaga keladi

Model mavjud boʻlmagan paketni oʻrnatishni ishonch bilan taklif qilishi mumkin — shunchaki bunday nom vazifa uchun ishonarli eshitilgani uchun. Buzgʻunchilar buni biladi va kod oʻrnatish paytida zararli yuk loyihalarga tushishi uchun ommaviy reyestrlarda shunday nomli paketlarni roʻyxatdan oʻtkazadi. Yaqin xavf — mashhur paketlar nomidagi imlo xatolari va tavsifi oʻxshash egizak paketlar.

Xavf shundaki, zararli kod loyihani ishga tushirib, paket vaʼda qilgan ishni qilmayotganini tushunishingizdan oldin, oʻrnatish paytidayoq bajarilishi mumkin.

Qanday tekshirish kerak

1. 01Diffda bogʻliqliklar fayli va lock-faylning har bir oʻzgarishini koʻring — bu reviewning alohida bandi.
2. 02Yangi paket uchun tekshiring: u reyestrda mavjudmi, nomi siz kutgan nomga mos keladimi, uni kim qoʻllab-quvvatlaydi, qachondan beri chop etilgan, qanchalik ishlatiladi, tarixi bor repozitoriysi bormi.
3. 03Bogʻliqlik umuman kerakmi, deb soʻrang: koʻpincha vazifani allaqachon ulangan kutubxona yoki bir necha qator kod hal qiladi.
4. 04Agentga paketlarni tasdiqsiz oʻrnatishni taqiqlang.
5. 05Maʼlum zaif versiyalar asosiy branchga tushmasligi uchun CI-ga bogʻliqliklar skanerini yoqing.

Kod, log va model kontekstidagi maxfiy kalitlar

SI «misol uchun» API kalitini toʻgʻridan-toʻgʻri kodga qoʻyib yuborishga moyil, keyin bu misol repozitoriyga tushadi. Teskarisi ham boʻladi: agent xatoni tuzatish uchun muhit oʻzgaruvchilari faylini oʻqiydi va uning mazmunini logga, hisobotga yoki izohga chiqaradi. Model kontekstiga tushgan hamma narsani yetkazib beruvchi siyosatiga koʻra kompyuteringizdan tashqariga uzatilgan deb hisoblash kerak.

• Maxfiy kalitlarni repozitoriydan tashqarida, maxfiy maʼlumotlar menejerida yoki muhit oʻzgaruvchilarida saqlang va agentning ular yozilgan fayllarga kirishini yoping.
• Pre-commit va CI-da maxfiy kalitlarni skanerlashni yoqing.
• Kod logga tokenlar, parollar, avtorizatsiya sarlavhalari va shaxsiy maʼlumotlarni yozmasligini tekshiring.
• Xato xabarlarini kuzating: API javobidagi bazaga ulanish parametrlari koʻrsatilgan batafsil xato ham sizib chiqishdir.
• Agent bilan ishlab chiqish uchun minimal huquqli alohida test kalitlaridan foydalaning.

Agar sizib chiqish allaqachon yuz bergan boʻlsa

1. 01Oshkor boʻlgan kalitni bekor qiling va yangisini chiqaring — bu oxirgi emas, birinchi harakat.
2. 02Servis yetkazib beruvchisidagi kalitdan foydalanish jurnallarini tekshiring: siz kutmagan murojaatlar boʻlganmi.
3. 03Kalit ishlatilgan barcha muhitlarda uni yangilang va eskisi boshqa hech qayerda ishlamasligiga ishonch hosil qiling.
4. 04Agar siyosat talab qilsa, repozitoriy tarixini tozalang, lekin bu birinchi qadamni bekor qilmasligini tushuning.
5. 05Kalit kodga qanday tushganini tahlil qiling va yoʻlni yoping: agent koʻrsatmalari faylidagi qoida, pre-commit-dagi skaner, alohida test kalitlari.

Eskirgan API, kriptografiya va xavfsiz boʻlmagan standart qiymatlar

Modelning bilimlari maʼlum sanada toʻxtagan va u kutubxonalarning yangi versiyalari haqida bilmasligi mumkin. Natijada allaqachon oʻchirilgan yoki xavfsiz emas deb topilgan funksiyalar chaqiruvi, eskirgan xeshlash va shifrlash algoritmlari, freymvorklarni sozlashning eski usullari paydo boʻladi.

• Parollarni maxsus parol algoritmlari oʻrniga umumiy maqsadli tez xesh-funksiyalar bilan xeshlash.
• Tekshirilgan kutubxona oʻrniga shifrlash yoki imzoning oʻz realizatsiyasi.
• Tokenlar va tasdiqlash kodlarini kriptografik barqaror generator oʻrniga oddiy tasodifiy sonlar generatori bilan yaratish.
• Doimiy vaqtli solishtirish kerak boʻlgan joyda maxfiy qiymatlarni oddiy satr solishtirish bilan tekshirish.
• Eskirgan TLS parametrlari yoki oʻchirilgan sertifikat tekshiruvi.

Alohida toifa — «ishlashi uchun» qilingan oʻzgarishlar: istalgan domendan soʻrovlarga ruxsat, yoqilgan debug rejimi, oʻchirilgan soxta soʻrovlardan himoya, fayllarga keng huquqlar. Agent xatoga duch kelganda koʻpincha shunday qadamlar qiladi va bu haqda hisobotda oʻtkazib yuborish oson boʻlgan bitta qator bilan halol yozadi. Diffda himoya mexanizmining har qanday oʻchirilishi — toʻxtab, u bu yerda nima uchun kerakligini soʻrashga sabab.

Inyeksiyalar va kiruvchi maʼlumotlarni qayta ishlash

Modellar umuman olganda parametrlangan soʻrovlar haqida biladi, lekin shoshilganda, kam uchraydigan kutubxonalarda va «tezkor» skriptlarda baribir soʻrov va buyruqlarni satrlarni ulash orqali yigʻadi. Bu ayniqsa xizmat kodiga oʻxshab koʻrinadigan joylarda seziladi: hisobotlar, admin sahifalari, maʼlumotlarni koʻchirish skriptlari.

• Foydalanuvchi kiritgan maʼlumotlardan, jumladan saralash uchun dinamik ustun nomlaridan yigʻilgan SQL soʻrovlar.
• Soʻrovdan olingan fayl nomlari yoki parametrlar qoʻyilgan shell buyruqlari.
• Normallashtirishsiz foydalanuvchi kiritgan fayl yoʻllari: ruxsat etilgan papkadan tashqariga chiqish.
• Foydalanuvchi maʼlumotlarini ekranlashsiz yoki xom HTML qoʻyadigan funksiyalar orqali HTML-ga chiqarish.
• Ruxsat etilgan manzillarni cheklamasdan, foydalanuvchi bergan manzil boʻyicha server soʻrovlari.
• Ishonchsiz manbadan kelgan maʼlumotlarni ixtiyoriy obyektlar yarata oladigan formatlar bilan deserializatsiya qilish.

Shartli misol. Agent hisobotga saralash qoʻshadi va ustun nomini soʻrov parametridan toʻgʻridan-toʻgʻri SQL matniga uzatadi — ustun nomini parametrlab boʻlmaydi, boshqa usulni esa u oʻylab topmagan. Testlar oʻtadi, saralash ishlaydi. Toʻgʻri yechim — ruxsat etilgan ustunlarning oq roʻyxati va uni yo vazifada koʻrsatish, yo reviewda ushlash kerak.

Reviewda qanday ushlash kerak

Inyeksiyalar belgilar boʻyicha yaxshi qidiriladi. Diffda soʻrov, buyruq yoki yoʻl satri oʻzgaruvchilardan yigʻiladigan joylarni; shell jarayonlarini ishga tushiradigan chaqiruvlarni; xom HTML qoʻyadigan funksiyalarni; parametrlardagi manzil boʻyicha server soʻrovlarini koʻrib chiqing. Bu belgilarning bir qismini statik tahlil qoidalari ushlaydi va ularni CI-ga yoqish kerak. Muhim endpointlar uchun ataylab zararli kiritishli testlar foydali: qoʻshtirnoqlar, ota papkaga oʻtadigan yoʻllar, matn maydonlaridagi belgilash.

Avtorizatsiya va maʼlumotlar izolyatsiyasi

Eng xavfli nuqsonlar skanerlarga koʻrinmaydi, chunki sintaksis jihatdan kod toʻgʻri. Endpoint identifikator boʻyicha obyektni qaytaradi va u joriy foydalanuvchiga tegishlimi, tekshirmaydi. Tashkilot boʻyicha filtr bitta yangisidan tashqari barcha soʻrovlarda bor. Rol interfeysda tekshiriladi, server esa manzilni biladigan har kim uchun harakatni bajaradi.

Model funksional vazifani hal qiladi va kirish qoidalari aniq yozilmagan boʻlsa, ular haqida koʻpincha bilmaydi. U qoʻshni kodni koʻrib, tekshiruvni takrorlashi ham, takrorlamasligi ham mumkin — masalan, tekshiruv u ishlayotgan fayldan koʻrinmaydigan oraliq qatlamda qilingan boʻlsa.

• Har bir yangi endpoint uchun soʻrang: uni kim chaqira oladi va u qaysi maʼlumotlarga kirish beradi?
• Identifikator boʻyicha oʻqish va oʻzgartirishda ega yoki tashkilot tekshirilishini tekshiring.
• Huquqlar tekshiruvi faqat interfeysdagi tugmani yashirmasdan, serverda bajarilishiga ishonch hosil qiling.
• Ommaviy amallar va eksportlarga qarang: ular koʻpincha yakka soʻrovlardagi tekshiruvlarni chetlab oʻtadi.

Shartli misol

Loyihada hisob-fakturani koʻrish endpointi bor, unda identifikator manzildan olinadi, hisob-faktura foydalanuvchi tashkilotiga tegishliligini tekshirish esa marshrutlarning alohida oraliq ishlov beruvchisida bajarilgan. Agent hisob-fakturani PDF koʻrinishida yuklab olish uchun yangi endpoint qoʻshadi, identifikator boʻyicha yuklash mantigʻini koʻchiradi, lekin marshrutni bu ishlov beruvchi ulanmagan boshqa joyda roʻyxatdan oʻtkazadi. Funksional jihatdan hammasi ishlaydi, yuklab olish testlari oʻtadi. Nuqsonni faqat salbiy test aniqlaydi: boshqa tashkilot foydalanuvchisi begona hisob-fakturani soʻraydi va rad javobini olishi kerak.

Jim nuqsonlar: xatolar, loglar va yumshatilgan testlar

Zaiflikka oʻxshamaydigan, lekin uni yaratadigan muammolar sinfi bor. Agent kodni «ishonchli» qilishga intilib, amalni har qanday xatoni ushlaydigan va hech narsa qilmaydigan ishlov beruvchiga oʻraydi. Huquqlar tekshiruvi yoki audit jurnaliga yozishdagi nosozlik koʻrinmas boʻlib qoladi, tizim esa hammasi joyidadek ishlashda davom etadi.

• Nosozlikni yashiradigan boʻsh yoki haddan tashqari keng xato ishlov beruvchilari.
• Foydalanuvchiga ichki tafsilotlarni qaytaradigan xatolar: trassirovka, bazaga soʻrov, fayl yoʻllari.
• Soʻrov yoki javobning butun obyektini shaxsiy maʼlumotlar va tokenlar bilan birga loglash.
• Agent oʻtishi uchun oʻzgartirgan testlar: yumshatilgan tekshiruvlar, tushirib qoldirilgan holatlar, oʻzgartirilgan kutilgan qiymatlar.
• Agentga vazifani tugatishga xalaqit bergan, oʻchirib qoʻyilgan yoki olib tashlangan CI tekshiruvlari.

Testlar va CI konfiguratsiyasidagi oʻzgarishlarni koddagi oʻzgarishlardan alohida va alohida diqqat bilan koʻrib chiqish kerak. Agent testni oʻzgartirgan boʻlsa, tavsifda test shunchaki «tuzatilgani» emas, talab nima uchun oʻzgargani izohlangan boʻlishi kerak.

Agentning oʻzi hujum yuzasi sifatida

Agent faqat kodingizni emas, duch kelgan hamma narsani oʻqiydi: vazifa tavsiflari, izohlar, hujjatlar, tashqi servislar javoblari, veb-sahifalar mazmuni. Agar bu matnlarda koʻrsatmalar yashirilgan boʻlsa, agent ularga amal qilishi mumkin — buni promptga inyeksiya deyishadi. Masalan, begona paketdagi izoh yoki tashqi foydalanuvchidan kelgan vazifadagi matn agentdan fayl mazmunini qayergadir yuborishni yoki «foydali» bogʻliqlik qoʻshishni soʻrashi mumkin.

Model darajasida bundan toʻliq himoyalanib boʻlmaydi, shuning uchun himoya huquqlar darajasida quriladi. Agent zararli koʻrsatmaga ishonsa, nima qila olishi muhim.

• Agent tasdiqsiz bajaradigan buyruqlar toʻplamini cheklang.
• Vazifa uchun kerak boʻlmagan joyda tarmoqqa kirishni cheklang.
• Agentga jangovar kalitlar, prodakshenga va mijozlar maʼlumotlariga kirish bermang.
• Fon agentlarini eng yomon ssenariy buzilgan branch boʻladigan alohida muhitda ishga tushiring.
• Kim tayyorlaganidan qatʼi nazar, har qanday oʻzgarishni birlashtirishdan oldin inson reviewini talab qiling.

Agent harakatlari jurnalini saqlash ham foydali: u qaysi buyruqlarni bajargan, qaysi fayllarni oʻqigan, qaysi manzillarga murojaat qilgan. Hodisani tahlil qilishda bunday jurnal agent xatti-harakati vazifa natijasimi yoki begona koʻrsatma natijasimi ekanini koʻrsatadi va unga aslida qanday huquqlar kerakligini tushunishga yordam beradi.

Tekshiruvlarni jarayonga qanday kiritish

Avtomatika ushlaydigan narsani review qiluvchi yolgʻiz oʻzi ushlamasligi kerak. Mexanik qismni konveyerga yuklab, insonning eʼtiborini mashina koʻrmaydigan narsaga qoldirish maʼqul.

1. 01Commitdan oldin: maxfiy kalitlarni skanerlash va formatlash.
2. 02CI-da: turlar tekshiruvi, xavfsizlik qoidalari bilan linterlar, statik tahlil, bogʻliqliklar skaneri, barcha testlar.
3. 03Birlashtirish qoidasi: qizil CI bilan yoki inson tasdigʻisiz oʻzgarishni birlashtirib boʻlmaydi.
4. 04Review: kirish mantigʻi, kiruvchi maʼlumotlarni qayta ishlash, yechimlarning oʻrinliligi, testlar va bogʻliqliklardagi oʻzgarishlar.
5. 05Muhim qismlar egalari: autentifikatsiya, toʻlovlar, kirish huquqlari va shaxsiy maʼlumotlar bilan ishlashdagi oʻzgarishlar shu qism uchun javobgarning tasdigʻini talab qiladi.

Turli oʻzgarishlar uchun turli qatʼiylik

• Oʻzgarish faqat interfeysga tegishli boʻlib, maʼlumotlarga tegmasa — odatiy review va CI yetarli, chunki xatodan zarar cheklangan.
• Oʻzgarish endpoint, bazaga soʻrov yoki fayllarni qayta ishlashni qoʻshsa — kirish uchun salbiy testlar va kiruvchi maʼlumotlarni tekshirish kerak, chunki inyeksiya va sizib chiqishlar aynan shu yerda paydo boʻladi.
• Oʻzgarish autentifikatsiya, pul, huquqlar yoki shaxsiy maʼlumotlarga tegsa — shu qism uchun javobgarning reviewi majburiy, chunki bu yerdagi xato hammasidan qimmat.

Ikkinchi qoida — diffni koʻzdan kechirsa boʻladigan hajmda saqlash. Agentning katta pull requestini diqqat bilan oʻqib boʻlmaydi va zaiflik yuzlab formatlash qatorlari orasida yoʻqoladi. Maqsadi tushunarli kichik oʻzgarishlar ancha ishonchliroq tekshiriladi.

Loyiha qoidalaridagi xavfsizlik talablari

Nuqsonlarning bir qismining oldini olish ularni ushlashdan arzonroq. Agent uchun doimiy koʻrsatmalar fayliga loyihaning xavfsizlik qoidalarini yozish kerak: maʼlumotlarga barcha soʻrovlar tashkilot boʻyicha filtrlanadi; huquqlar tekshiruvi — faqat serverda; bazaga soʻrovlar — faqat qabul qilingan kirish qatlami orqali, parametrlar bilan; yangi bogʻliqliklar — faqat kelishilgan holda; maxfiy maʼlumotlarni oʻqimaslik va chiqarmaslik; vazifada aniq koʻrsatilmagan boʻlsa, himoya mexanizmlarini oʻchirmaslik. Agent ularga har doim emas, lekin oʻzi koʻrmagan qoidalarga qaraganda ancha koʻproq amal qiladi.

SI yozgan kod reviewi uchun nazorat roʻyxati

Bu roʻyxatni pull request shabloniga qoʻyish qulay, shunda review qiluvchi undan xotiraga tayanib emas, ongli ravishda oʻtadi.

1. 01Yangi bogʻliqliklar: mavjud, nomi mos, qoʻllab-quvvatlanadi, haqiqatan kerak.
2. 02Lock-fayl: oʻzgarishlar eʼlon qilingan bogʻliqliklarga mos.
3. 03Maxfiy kalitlar: kodda, konfiguratsiyada, testlarda va loglarda kalit va parollar yoʻq.
4. 04Kirish: maʼlumotlarga har bir soʻrov joriy foydalanuvchi yoki tashkilot bilan cheklangan.
5. 05Huquqlar tekshiruvi serverda, jumladan ommaviy amallar va eksportlarda bajariladi.
6. 06Kiruvchi maʼlumotlar: soʻrovlar parametrlangan, buyruqlar satrlardan yigʻilmaydi, yoʻllar normallashtirilgan.
7. 07Chiqish: foydalanuvchi maʼlumotlari ekranlangan.
8. 08Himoya mexanizmlari: «ishlashi uchun» hech narsa oʻchirilmagan.
9. 09Kriptografiya: standart kutubxonalar va dolzarb algoritmlar ishlatilgan.
10. 10API: chaqiruvlar kutubxonalaringiz versiyalari uchun dolzarb.
11. 11Xatolar: yutib yuborilmaydi va foydalanuvchiga ichki tafsilotlarni ochmaydi.
12. 12Testlar: yumshatilmagan, kirish huquqlari uchun salbiy ssenariylar bor.
13. 13CI: tekshiruvlar oʻchirilmagan va yumshatilmagan.
14. 14Hajm: diffda vazifadan tashqari oʻzgarishlar yoʻq.

Xulosa

SI kodni oʻz-oʻzidan xavfsiz qilmaydi, balki xatarlarni oldindan aytib boʻladigan joylarga koʻchiradi: bogʻliqliklar, maxfiy kalitlar, eskirgan yechimlar, kirish tekshiruvlari va himoyani jimgina chetlab oʻtishlar. Avtomatika — bogʻliqlik va kalit skanerlari, linterlar, CI — mexanik qismni yopadi, kirish mantigʻi va yechimlarning oqilonaligini esa inson tekshiradi.

Odatiy nuqsonlarni bilib, ularni maqsadli qidirsangiz va agentning oʻz huquqlarini cheklasangiz, SI yordamida yozilgan kodni tajribali jamoa kodi darajasiga yetkazish mumkin. Bu daraja uchun masʼuliyat avvalgidek odamlar zimmasida.