დეველოპერი ხსნის IDE-ს, მარტივ ენაზე აღწერს, რა სურს და უყურებს, როგორ წერს ხელოვნური ინტელექტის აგენტი ფუნქციას იმ დროში, რაც ყავის მიღებას სჭირდება. ის კომპილირდება. ის გადის ხელით დაწკაპუნების პროცესს. ის იგზავნება. არავინ კითხულობს, უსაფრთხო იყო თუ არა ის, რადგან არავინ არაფერს ითხოვდა. მოთხოვნამ ჩაანაცვლა pull requestდა „მუშაობს“-მა ჩაანაცვლა „მე გადავხედე“. ეს არის ვიბრაციული კოდირება და ის აღარ არის მეორეხარისხოვანი ჩვევა. ეს არის ის, თუ როგორ იწერება საწარმოო კოდის მზარდი წილი პროფესიონალური გუნდების მიერ და არა მხოლოდ მოყვარულების მიერ, რომლებიც ექსპერიმენტებს ატარებენ შაბათ-კვირის აპლიკაციასთან. და სწორედ ამიტომ გახდა ვიბრაციული კოდირების უსაფრთხოება სასაუბრო თემა ყველა ინჟინერიისა და უსაფრთხოების ლიდერისთვის, უკვე დაასახელეს თუ არა ეს.
რას ნიშნავს სინამდვილეში „ვიბრაციული კოდირება“
Vibe კოდირება არის პროგრამული უზრუნველყოფის შემუშავება, სადაც ადამიანი აღწერს სასურველ შედეგს ბუნებრივი ენით და ხელოვნური ინტელექტის მოდელი, ან მასზე აგებული აგენტი, წარმოქმნის მუშა კოდს. ადამიანი მართავს შედეგის მიხედვით („შექმენი login „flow“, „CSV ექსპორტის დამატება“) იმპლემენტაციის წერის ან სტრიქონ-სტრიქონ მიმოხილვის ნაცვლად. ტერმინმა პოპულარობა მოიპოვა, რადგან ის რეალურ რამეს ასახავს: დეველოპერი იმედოვნებს, რომ გამომავალი სწორია და არა თავად კოდის წაკითხვას.
ეს ცვლილება მთელი ამბავია. კოდის მიმოხილვა ადრე პროგრამული უზრუნველყოფის წერის პროცესში ჩადებული საკონტროლო წერტილი იყო. Vibe კოდირება ამას თავისით გვერდს უვლის. სიჩქარე იზრდება. „რას აკეთებს ეს სინამდვილეში“ კითხვის ჩვევა ქრება.
რატომ არის „მუშაობს“ არასწორი ზოლი
„მუშაობს“ ნიშნავს, რომ კოდმა შეასრულა ის, რაც მოითხოვეს ტესტირების სცენარში. ის არაფერს ამბობს იმაზე, თუ რას აკეთებს კოდი იმ სცენარებში, რომლებზეც არავინ უკითხავს: არასწორად ფორმირებული შეყვანა, ავტორიზებული მომხმარებელი, რომელიც იკვლევს საბოლოო წერტილს, რომელიც მას ზედმეტად ენდობოდა, დამოკიდებულება, რომელიც არასდროს შემოწმებულა, მყარი კოდით დაცული საიდუმლო, რომელიც თვალსაჩინო ადგილასაა. სწორედ აქ ირღვევა Vibe კოდირების უსაფრთხოება მანამ, სანამ ვინმე პრობლემას შეამჩნევს.
ხელოვნური ინტელექტის კოდირების მოდელები გაწვრთნილია ისე, რომ წარმოქმნან ფუნქციური გამომავალი, რომელიც შეესაბამება მოთხოვნის მიზანს. უსაფრთხოება არ არის ობიექტური ფუნქცია. მოდელი, რომელიც ოპტიმიზირდება „ეს აკმაყოფილებს მოთხოვნას“, სიამოვნებით წარმოქმნის მოთხოვნას, რომელიც აგებულია სტრიქონების შეერთებით პარამეტრების ნაცვლად, საბოლოო წერტილს წვდომის კონტროლის გარეშე, რადგან მოთხოვნაში არასდროს არის მითითებული, ვის არ უნდა ჰქონდეს წვდომა, ან API გამოძახებას, რომელიც ენდობა პასუხს, რომლის დადასტურებაც მან უნდა განახორციელოს. ის კომპილაციას ახდენს. ის მუშაობს. ის ასევე წარმოგვიდგენს იმავე დაუცველობის კლასებს, რომელთა გადამზადებასაც AppSec-ის გუნდებმა ათწლეული დაუთმეს დეველოპერებს, რომლებიც გენერირებულია ისეთი ტემპით, რომლის შესატყვისადაც არ შექმნილა ხელით განხილვის პროცესი.
ხელოვნური ინტელექტის მიერ გენერირებული კოდის შიდა კვლევა რეალურ ციფრებს ინტუიციის მიღმა აყენებს: აგენტური კოდირების ინსტრუმენტების მიერ წარმოქმნილი ინფორმაციის მნიშვნელოვანი ნაწილი პირველივე გავლისას, ნებისმიერი განხილვის დაწყებამდე, ექსპლუატაციაში მყოფ უსაფრთხოების ხარვეზს შეიცავს. ეს ერთი მოდელის დეფექტი არ არის. ეს არის „მუშაობს“ ოპტიმიზაციის მოსალოდნელი შედეგი და არა „მუშაობს“ და ეს არის ზუსტად ის ხარვეზი, რომელიც Vibe კოდირების უსაფრთხოებამ უნდა შეავსოს.
რისკის ზედაპირი უფრო ფართოა, ვიდრე თავად კოდი
Vibe კოდირება უსაფრთხოება ხშირად განიმარტება, როგორც კოდის ხარისხის პრობლემა, მაგრამ ექსპოზიცია მთელ სამუშაო პროცესს გადის აგენტი ეხება და არა მხოლოდ მის ფუნქციას წერს:
რატომ ჩამორჩება ტრადიციული AppSec ინსტრუმენტები აქ
აპლიკაციების უსაფრთხოების ინსტრუმენტების უმეტესობა რიტმის გარშემო იყო აგებული: კოდი იწერება, შემდეგ სკანირდება CI-ში ან PR-ში. ეს რიტმი ვარაუდობს, რომ არსებობს სტაბილური, ადამიანის მიერ შექმნილი არტეფაქტი, რომელზეც სკანერი უნდა იყოს მიმართული და რომ ცვლილების მოცულობა არის რაღაც... pipeline შეუძლია განზრახ გადახედვა.
Vibe კოდირება არღვევს დროის ინტერვალს და ეს დროის ინტერვალი Vibe კოდირების უსაფრთხოების პრობლემის არსს წარმოადგენს. კოდი IDE-ში წამებში იცვლება, ხშირად მანამ, სანამ ის ნიშნულს მიაღწევს. pull requestსკანერი, რომელიც მხოლოდ CI-ში მუშაობს, პრობლემას ფაქტის შემდეგ აღმოაჩენს, როგორც კი დაუცველი ნიმუში უკვე გაერთიანებულია, რაც უკვე შემდეგი ფუნქციის ნაწილია, რომელზეც სხვა ადამიანი აშენებს. ხოლო სკანერი, რომელიც ხელოვნური ინტელექტის მიერ გენერირებულ კოდს ისევე ეპყრობა, როგორც ნებისმიერ სხვა კოდს, გამოტოვებს რისკის იმ ნაწილებს, რომლებიც სპეციფიკურია მისი დაწერის წესისთვის: პაკეტი, რომელიც აგენტმა აირჩია მისი დასაბუთების მოთხოვნის გარეშე, ინსტრუქციის ფაილი, რომელიც აგენტს ეუბნებოდა, რა უნდა გაეკეთებინა, სანამ ადამიანი განსხვავებას დაინახავდა.
რა ამცირებს სინამდვილეში ხარვეზს
ორგანიზაციები, რომლებიც ამას წინ აღუდგებიან, არ ანელებენ Vibe კოდირებას. ისინი რეალურ Vibe კოდირების უსაფრთხოებას ნერგავენ სამუშაო პროცესში: საკონტროლო პუნქტს უკან, სადაც კოდი რეალურად იწერება, გადააქვთ და ხელოვნური ინტელექტის მიერ გენერირებულ კოდს არასანდო შეყვანად მიიჩნევენ, სანამ საპირისპირო არ დამტკიცდება:
- დაასკანირეთ IDE-ში და არა მხოლოდ CI-ში. დაუცველი ნიმუშის დაჭერა მაშინ, როდესაც აგენტი ჯერ კიდევ ქმნის ფუნქციას, განსხვავებული პრობლემაა, ვიდრე მისი დაჭერა მას შემდეგ, რაც მასზე კიდევ სამი ფუნქცია იქნება დამოკიდებული.
- აგენტის მიერ შემოტანილი ყველა დამოკიდებულების დადასტურება, ისევე როგორც დაადასტურებდით დეველოპერის მიერ ხელით აკრეფილ ვერსიას ინსტალაციამდე.
- აგენტის მიერ წაკითხული კონფიგურაციის ფაილები კოდად და არა დოკუმენტაციად უნდა განიხილოთ. წესების ფაილებს, უნარების ფაილებს და MCP სერვერის კონფიგურაციებს შეიძლება ჰქონდეთ ინსტრუქციები, რომლებიც ცვლის აგენტის ქმედებებს და ისინი იმსახურებენ იმავე შემოწმებას, როგორც აგენტის მიერ შექმნილი კოდი.
- შესწორების შესახებ ადამიანსაც აცნობეთ და არა მხოლოდ დროშას. დეველოპერი, რომელსაც შეუძლია დაინახოს, თუ რატომ არის რაღაც ექსპლუატაციადი და არა მხოლოდ ის, რომ მან წესი გაააქტიურა, სინამდვილეში სწავლობს, თუ როგორ უნდა მოითხოვოს და გადახედოს სხვაგვარად შემდეგ ჯერზე.
- დავუშვათ, რომ „მუშაობს“ არასდროს ყოფილა უსაფრთხოების ზოლიდა სამუშაო პროცესში რეალური ზოლი მეხსიერებაში დატოვების ნაცვლად ხილული გახადოს.
სად ჯდება Xygeni
ეს ზუსტად ნაკერია Xygeni-ს DevAI დახურვისთვის შეიქმნა. DevAI მუშაობს როგორც უწყვეტი უსაფრთხოების ფენა IDE-ს შიგნით, აკვირდება ადამიანის მიერ დაწერილ და ხელოვნური ინტელექტის მიერ გენერირებულ კოდს მისი შექმნისას და არა მას შემდეგ, რაც ის მოხვდება pull requestის არ ელოდება მოთხოვნას: ის აღნიშნავს ექსპლუატაციისთვის საშიშ ნიმუშებს, განმარტავს შეტევის რეალურ გზას მარტივი ენით და გვთავაზობს გამოსწორებას, რომლის განხილვა და გამოყენებაც დეველოპერს შეუძლია თავისი ნაკადიდან გაუსვლელად. მიწოდების ჯაჭვის მხრივ, MEW (მავნე პროგრამების ადრეული გაფრთხილება) მავნე პაკეტებს ხელმოწერის არსებობამდე იჭერს, რაც აქ პირდაპირ მნიშვნელოვანია, რადგან აგენტი თქვენი სახელით დამოკიდებულებას ზუსტად იმ მომენტში ირჩევს, როდესაც უყურადღებოდ დაკავებულ ან კომპრომეტირებულ პაკეტს შეუძლია შეღწევა.
ორივეს ქვეშ, CoreAI აკავშირებს იმას, რაც ნაპოვნია კოდის ბაზაში, დამოკიდებულებებში და pipeline ერთ პრიორიტეტულ რისკ-ხედვად და ეს შეხედულება არ შემოიფარგლება მხოლოდ ქსიგენი საკუთარი სკანირებები. იგივე ეხება ხელოვნური ინტელექტის ტრიაჟი, ახსნა და გამოსწორება სხვა სკანერებიდან მიღებული დასკვნების მიხედვით, რომლებიც უკვე არსებობს, ამიტომ Vibe კოდირების უზრუნველყოფა არ ნიშნავს უკვე მომუშავე დასტის ამოღებას. ეს ნიშნავს მასზე ფენის დადებას, რომელიც საბოლოოდ იმ სიჩქარით იმოძრავებს, რომლითაც კოდი იწერება.
კითხვა-პასუხი
Vibe კოდირება თავისთავად დაუცველია?
არა. Vibe კოდირება განვითარების მეთოდია და არა დაუცველობა. რისკი წარმოიქმნება არაუსაფრთხო ნიმუშების აღმოსაჩენად გამოყენებული განხილვის ეტაპის გამოტოვებით და არა კოდის დასაწერად ხელოვნური ინტელექტის გამოყენებით. სწორედ ამიტომ, Vibe კოდირების უსაფრთხოება სამუშაო პროცესის დისციპლინაა და არა ამ პრაქტიკის თავიდან აცილების მიზეზი.
შეიძლება არსებული SAST or SCA ინსტრუმენტები აფიქსირებენ Vibe კოდირების უსაფრთხოების რისკებს?
ისინი ნაწილობრივ იჭერენ მას, მაგრამ, როგორც წესი, კოდის შერწყმის შემდეგ, რადგან უმეტესობა მუშაობს CI-ში და არა IDE-ში, სადაც კოდი გენერირდება. ასევე, როგორც წესი, ისინი არ აფასებენ ხელოვნური ინტელექტის აგენტის საკუთარ ქცევას, როგორიცაა მის მიერ არჩეული პაკეტები ან წაკითხული კონფიგურაციის ფაილები.
რა არის Vibe კოდირების უსაფრთხოების ყველაზე მაღალი ბერკეტის მქონე ერთადერთი გამოსავალი?
უსაფრთხოების შემოწმებები გადაიტანეთ IDE-ში, გენერირების ეტაპზე, იმის ნაცვლად, რომ დაეყრდნოთ მხოლოდ მოგვიანებით შემოწმებებს. pipeline სკანირება. პრობლემის აღმოჩენა მანამ, სანამ ის მასზე აგებული შემდეგი სამი ფუნქციის ნაწილი გახდება, სულ სხვა პრობლემაა, ვიდრე მისი შემდგომ აღმოჩენა.
ნიშნავს თუ არა Vibe კოდირების უზრუნველყოფა დეველოპერების შენელებას?
არა, თუ შემოწმება მოხდება უშუალოდ IDE-ში, ახსნა-განმარტებითა და მზა შესწორებით. მიზანია შევინარჩუნოთ სწრაფი ვიბრაციული კოდირების შეთავაზებები და ამავდროულად აღვადგინოთ ის შეფასება, რომელსაც ადრე ხელით განხილვა იძლეოდა.
