უკან დაბრუნება
LLM-ის მიერ დაგენერირებული კოდი არასანდო build-არტეფაქტად
SiTech AI Team2 წთ. საკითხავი

LLM-ის მიერ დაგენერირებული კოდი არასანდო build-არტეფაქტად

dev.to-ზე გამოქვეყნებული მასალა ამტკიცებს, რომ მოდელის გამომავალს სამუშაო სადგურზე შეუზღუდავი წვდომა არ უნდა ჰქონდეს: საჭიროა წარმომავლობის შენახვა, შესაძლებლობების კლასიფიკაცია და სენდბოქსი გაშვებამდე.

AI-ის პასუხიდან „ფარული კოდის“ მოცილება ტექსტის გასუფთავებად გამოიყურება. dev.to-ზე გამოქვეყნებული მასალა, რომლის ორიგინალიც cometapi.com-ზეა, ამას გაშვების უსაფრთხოებად განიხილავს: ჯერ უნდა დადგინდეს, რისი გაკეთება შეუძლია არტეფაქტს, შემდეგ — საიდან მოვიდა მისი ინსტრუქციები, და მხოლოდ ამის შემდეგ შეიზღუდოს მისი შესაძლებლობები.

ინციდენტი, რომელიც წესს უდგას საფუძვლად

პოსტი იშვებს საზოგადოების ცნობებს დაახლოებით 800 გბ წაშლილი ფაილის შესახებ, მათ შორის მთლიანად Cursor AI აპლიკაციაზე, მას შემდეგ, რაც დეველოპერმა Cursor IDE-ში Gemini 3-ის დახმარებით დაგენერირებული კოდი გაუშვა. ავტორი ხაზგასმით აღნიშნავს, რომ ეს ცნობილი ინციდენტია და არა დადასტურებული ფორენზიკული ანგარიში, და რომ დაგენერირებულ კოდს სამუშაო სადგურზე შეუზღუდავი წვდომა არ უნდა ჰქონდეს.

ჭიშკარი გენერაციასა და გაშვებას შორის

„ფარული კოდი“ რამდენიმე პრობლემას მოიცავს: არაპირდაპირი prompt injection ვებგვერდებიდან, PDF-ებიდან ან დანამატების პასუხებიდან; ბრაუზერში რენდერირებული მავნე JavaScript; დამალული შიგთავსი, მაგალითად zero-width სიმბოლოები ან base64 მონაცემები. საშიში ქცევა შემთხვევითიც შეიძლება იყოს: დირექტორიის „გასუფთავების“ თხოვნამ შეიძლება rm -rf ან shutil.rmtree გამოიწვიოს თავდამსხმელის გარეშე.

პირველ რიგში წარმომავლობაა: ორიგინალი პასუხი, საუბარი, სისტემური prompt, მოძიებული დოკუმენტები და დანამატების შედეგები უნდა შეინახოს, ამოღებული კოდი კი — ცალკე, ყველა ტრანსფორმაციისა და დადასტურების ჩანაწერით. Black-ით ან Prettier-ით ფორმატირება საოჯახო საქმეა და არა უსაფრთხოების შემოწმება; U+200B, U+200C, U+200D და U+FEFF ყურადღებას იმსახურებენ, თუმცა მათი წაშლა სტრიქონებს ცვლის.

შესაძლებლობები დადასტურებამდე კლასიფიცირდება: წყაროს პარსინგი, ლინტერები და უსაფრთხოების წესები. ყურადღების მიზეზებია sudo, rm -rf, shutil.rmtree, subprocess.Popen, os.system, eval, exec და მოულოდნელი აბსოლუტური ბილიკები. ხაზების წაშლის გამოცნობის ნაცვლად ავტორი შესაძლებლობებს ბლოკავს: AST-ზე დაფუძნებული გადაწერა, subprocess-ის დროის ლიმიტები, mock ადაპტერები, დაბლოკილი pip და npm ინსტალაციები და რეალური API გასაღებების არარსებობა ტესტირებისას.

სენდბოქსი, ხელსაწყოები, აუდიტის კვალი

სატესტო გარემოა ეფემერული კონტეინერი ან microVM ქსელის, ჰოსტის სერტიფიკატებისა და მიმაგრებული დისკების გარეშე — ვარიანტებად gVisor და Firecracker სახელდება — seccomp-ითა და რესურსების ლიმიტებით. ხელსაწყოების კრებული Python-ის ast მოდულს უმატებს Bandit-ს, Semgrep-სა და ESLint-ის უსაფრთხოების დანამატებს.

ორი პატარა შემოწმება საზღვრებს აჩვენებს. regex, რომელიც U+200B, U+200C, U+200D და U+FEFF-ს ეძებს, მათ აუდიტისთვის აფიქსირებს; ხშირად კოპირებული re.compile(r'') შაბლონი კი ცარიელ სტრიქონს ემთხვევა და არაფერს შლის. AST-ის შემოვლა პირდაპირ eval-სა და exec-ს, ისევე როგორც popen და system ატრიბუტებს იჭერს, თუმცა ალიასებითა და სტრიქონებით აწყობილი სახელებით მისი გვერდის ავლა შესაძლებელია. საზღვარი მარტივია: მოდელი საკუთარ გაშვებას არ ავტორიზებს.

SSiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.