ხელოვნური ინტელექტის აგენტის მიწოდების ჯაჭვის უსაფრთხოება ადრე მარტივი იყო, ძირითადად იმიტომ, რომ ადამიანი ყოველთვის იდგა პაკეტის სახელსა და აწყობას შორის. ოცი წლის განმავლობაში ეს იყო მთელი მოდელი: ვიღაც კითხულობდა სახელს, სანამ ის შევიდოდა. ყოველთვის არა ყურადღებით. მაგრამ ვიღაც კითხულობდა.
ეს ახლა აღარ არის. დღეს ხელოვნური ინტელექტის მოდელს ბიბლიოთეკის შესახებ ჰკითხეთ და დაახლოებით ხუთიდან ერთი რეკომენდებული პაკეტი აღარ არსებობს. თავდამსხმელებმა ეს იციან, ამიტომ ჯერ ამ სახელებს არეგისტრირებენ. აგენტი აყენებს მათ, ამოწმებს და გადადის შემდეგ ეტაპზე, შუალედურში კი არავინ კითხულობს არაფერს. სწორედ აქ იშლება ხელოვნური ინტელექტის აგენტის მიწოდების ჯაჭვის უსაფრთხოება ახლა: არა რომელიმე მომავლის სცენარში, არამედ... pipelineდღეს მუშაობს.
ინდუსტრიამ ორი ათწლეული დახარჯა დეველოპერის გარშემო კონტროლის მექანიზმების შექმნაზე, რომელიც კითხულობს, აფასებს და იღებს გადაწყვეტილებებს. ეს დეველოპერი აღარ არის ბოლო საკონტროლო წერტილი, სანამ დამოკიდებულება შევა აწყობაში. ამიტომ, რეალური კითხვა არ არის, შემოაქვს თუ არა აგენტური ხელოვნური ინტელექტი ახალ რისკს, არამედ ის, თუ რა რჩება რეალურად მას შემდეგ, რაც ადამიანური საკონტროლო წერტილი გაქრება.
„ხელოვნური ინტელექტის შემოთავაზებებიდან“ „ხელოვნური ინტელექტის ქმედებებამდე“
ორი წლის წინ, თანაპილოტმა შემოგვთავაზა კოდის ბლოკი, დეველოპერმა წაიკითხა იგი და დეველოპერმა გადაწყვიტა, შეენარჩუნებინა თუ არა იგი. ეს სამუშაო პროცესი დიდწილად აღარ არსებობს. აგენტური ინსტრუმენტები ახლა აყენებენ დამოკიდებულებებს, ატრიალებენ კონტეინერებს და ააქტიურებენ pipeline დამოუკიდებლად დგამენ ნაბიჯებს, ხშირად მხოლოდ ფაქტის შემდეგ აცხადებენ ანგარიშს და მხოლოდ იმ შემთხვევაში, თუ რამე არასწორად მიდის.
ცვლილება ეტაპობრივად მოხდა და გუნდების უმეტესობა ამ მიმართულებით უფრო შორს წავიდა, ვიდრე მათი წერილობითი უსაფრთხოების პოლიტიკა აღიარებს. ადრეული აგენტული ინსტრუმენტები ყოველი ცვლილების წინ დამტკიცებას ითხოვდნენ და დეველოპერები იმდენად ხშირად აჭერდნენ „დიახ“-ს, რომ დადასტურების ეტაპს აზრი აღარ ჰქონდა. დღევანდელი აგენტები ძირითადად საერთოდ არ ეკითხებიან. ისინი მხოლოდ მგრძნობიარე ქმედებებზე წყვეტენ, როგორიცაა shell სკრიპტის გაშვება და ტიპიური... pull request აგენტის მიერ გენერირებული შეიძლება ათასობით სტრიქონად გადაიქცეს, რომლებსაც ადამიანი რეალურად არ კითხულობს თავიდან ბოლომდე გაერთიანებამდე.
ნებართვების პრობლემა ამას კიდევ უფრო ამძიმებს. უმეტეს კონფიგურაციაში, აგენტი უბრალოდ მუშაობს როგორც დეველოპერი, რომელსაც აქვს წვდომა ყველაფერზე, რაზეც დეველოპერის მანქანას შეუძლია წვდომა: გარემოს ცვლადები, ღრუბლოვანი ტოკენები, რეესტრის სერთიფიკატები, SSH გასაღებები. როდესაც აგენტი რაღაცას აყენებს და სკრიპტი ამ ინსტალაციის დროს ირთვება, ის მემკვიდრეობით იღებს იმ ადამიანის სრულ აფეთქების რადიუსს, რომელსაც იმიტაციას უკეთებს. სწორედ აქ ხდება, რომ ხელოვნური ინტელექტის აგენტის მიწოდების ჯაჭვის უსაფრთხოება წყვეტს პოლიტიკის საკითხს და ნებართვების საკითხად იქცევა: აგენტს არ სჭირდება ახალი ექსპლოიტი, მას უბრალოდ სჭირდება უკვე არსებული წვდომა.
დოკერის კაპიტანი მოჰამედ-ალი არაბიიმავე პანელზე გამოსვლისას, მან ნათლად განაცხადა: „ვფიქრობ, რომ დეველოპერი ახლა შეტევის ზედაპირის ნაწილია.“
ღირს გულწრფელად ვიყოთ იმის შესახებ, თუ რა ჩაანაცვლა ამან. ადამიანი, რომელიც კითხულობს package.json diff ისედაც სუსტი კონტროლი იყო; ცვლილების დამტკიცებამდე თითქმის არავინ ამოწმებდა ყველა გარდამავალ დამოკიდებულებას. აგენტები აუცილებლად არ არღვევდნენ ძლიერ სისტემას. მათ ამოიღეს სუსტი სისტემის ბოლო საბაბი. შეიცვალა არა ის, რომ რისკი ახალია, არამედ ის, რომ ახლა ის სრულიად განსხვავებული სიჩქარით მოძრაობს: ზოგიერთი შეფასებით, გასული წლის მიწოდების ჯაჭვის შეტევების მოცულობა დაახლოებით ხუთჯერ მეტია წინა წელთან შედარებით და მრუდი ექსპონენციალურად გამოიყურება და არა წრფივად.
ინსტალაციის მომენტი: რა იცვლება, როდესაც არავინ უყურებს
ჰალუცინაციებით და მავნე პაკეტის სახელები სიახლეს არ წარმოადგენს. ტიპოქტაცია წლების განმავლობაში იყენებდა ადამიანის მიერ დაშვებული აკრეფის შეცდომებს: ერთი არასწორი ასო და დეველოპერი არასწორ ელემენტს აინსტალირებს. ახლა განსხვავება ისაა, რომ სახელწოდებას თავიდანვე მოდელი იგონებს და არა ადამიანი და ეს ხდება პროგნოზირებადად.
ციფრები ამას ბიზნესად აქცევს და არა ცნობისმოყვარეობად. ღია კოდის მოდელების მიერ რეკომენდებული პაკეტების დაახლოებით 20% არ არსებობს (კომერციული მოდელებისთვის ეს მაჩვენებელი დაახლოებით 5%-ს შეადგენს) და შესწავლილი შეთხზული სახელების 43% იდენტურად მეორდება ათ განმეორებით მოთხოვნაში. სწორედ განმეორებადობა ხდის შეტევის ნიმუშს ფერმერულს: თავდამსხმელს არ სჭირდება გამოიცნოს, რას აკრიფავს დეველოპერი. მოდელი მათ საიმედოდ და უფასოდ ეუბნება.
ახალი ვარიანტი, სახელწოდებით HalluSquatting, კიდევ უფრო შორს მიდის. ჰალუცინირებული სახელით მავნე პაკეტის გამოქვეყნების ნაცვლად, თავდამსხმელი ათავსებს მავნე ინსტრუქციებს README-ში, უნარების ფაილში ან MCP სერვერის აღწერილობაში, შემდეგ კი ელოდება აგენტის მიერ იმავე საცავის ან ინსტრუმენტის სახელის ჰალუცინაციას და მის ამოღებას. ერთ-ერთ ბოლოდროინდელ ნაშრომში, რომელიც ამას პრომპ ინექციასთან აკავშირებს, აღწერილია ახალი პროექტებისთვის ყალბი საცავის სახელების თითქმის სრულყოფილი პროგნოზირება და სრული კოდის შესრულება რეალური კოდირების ასისტენტების, მათ შორის Cursor, Windsurf და Copilot-ის წინააღმდეგ. იმის გამო, რომ დატვირთვა არის უბრალო ტექსტი და არა შესრულებადი კოდი, სკანირების ხელსაწყოების უმეტესობას არაფერი აქვს შესამოწმებელი.
როგორც ქსიგენი კვლევის ოფიცერი ლუის როდრიგესი განხილვის დროს დაასახელეთ: „წლები დავხარჯეთ მავნე კოდისგან თავდაცვის სისტემების შექმნაზე. ხელმოწერები, „სატესტო სივრცეები“, ქცევის ანალიზი. HalluSquatting-ს ეს არაფერი სჭირდება. მას მხოლოდ დამაჯერებელი README სჭირდება.“ უბრალო ტექსტური ინსტრუქციები, რომლებსაც აგენტი სანდო კონტექსტად კითხულობს, პირდაპირ სკანერების გვერდის ავლით გადის, რომლებიც შექმნილია შესასრულებელი ფუნქციის დასაჭერად.
ეს არის ფენა, რომლის სანახავადაც AppSec ინსტრუმენტების უმეტესობა ჯერ კიდევ არ არის შექმნილი, რაც წინასწარ არის შექმნილი.cisრატომ Xygeni-ს მავნე პროგრამების ადრეული გაფრთხილება (MEW) მიდგომა პლატფორმის დონეზე არსებობს: ახლად გამოქვეყნებული პაკეტების უწყვეტი, რეალურ დროში ანალიზი სხვადასხვა რეესტრში, როგორიცაა npm, PyPI და Maven, რომელიც შექმნილია მავნე ქცევის გამოსავლენად საჯარო ხელმოწერის არსებობამდე და არა CVE-ს რამდენიმე დღის შემდეგ დაფიქსირების ლოდინის ნაცვლად.
კონტეინერები, CI/CDდა წარმომავლობა: კვლავ შეგიძლიათ დაამტკიცოთ, რა არის თქვენს ბილდში?
აგენტი იშვიათად ჩერდება ხაზის დამატებით package.jsonის რედაქტირებს Dockerfiles-ს, აახლებს მრავალსაფეხურიან აწყობას და ცვლის pipeline კონფიგურაცია პირდაპირ, თავად აწყობის სისტემაში შესვლით და არა მხოლოდ წყაროს ხეში.
სწორედ აქ არის ინდუსტრიის პასუხი მიწოდების ჯაჭვის რისკზე, SBOMდა SLSA provenance, უნდა შეენარჩუნებინა. შემდეგ, 2026 წლის მაისში, თავდამსხმელმა ფიშინგში გაიტანა მომწოდებელი, გამოიყენა მოპარული ტოკენი „ობოლი“ ტოკენის გამოსაქვეყნებლად. commit პროექტის ისტორიაში მშობელი ფაილის გარეშე და მისი გამოყენებით აწყობის ქეშის დაბინძურება. შედეგად მიღებული პაკეტები, რომელთაგან ოთხმოცდაოთხი იყო, სრულად ვალიდური, სათანადოდ ხელმოწერილი უმაღლესი დონის წარმომავლობით გაიგზავნა. ყველა ავტომატური შემოწმება წარმატებით გაიარა. მავნე პროგრამა რეალური იყო და ტექნიკურად, მისი აგების დამადასტურებელი დოკუმენტაციაც რეალური იყო.
არასასიამოვნო დასკვნა: წარმომავლობა ადასტურებს, თუ რა გააკეთა კონსტრუქციამ მოცემული ნივთით და არა იმას, რომ მიცემული ნივთი ნდობას იმსახურებდა. არტეფაქტის არსებობამდე მოწამლეთ შეყვანილი ინფორმაცია და დადასტურება არაკეთილსინდისიერი კონსტრუქციის პატიოსანი, დამოწმებადი ჩანაწერი იქნება. ხელოვნური ინტელექტის აგენტის მიწოდების ჯაჭვის უსაფრთხოება არ შეიძლება მთლიანად გადაეცეს დადასტურების ინსტრუმენტებს, რომლებიც შექმნილია ისეთი სამყაროსთვის, სადაც ადამიანი და არა მოდელი წყვეტს, თუ რა უნდა შევიდეს კონსტრუქციაში.
ერთი პრაქტიკული შემარბილებელი ფაქტორი არასერიოზულია, მაგრამ ეფექტური: გაგრილების პერიოდი, როდესაც პაკეტის ახალი ვერსიის გამოქვეყნებიდან რამდენიმე დღე უნდა დაელოდოთ მის გამოყენებამდე. მიწოდების ჯაჭვის აქტიური ინციდენტების უმეტესობა ამ ადრეულ ფანჯარაში აღინიშნება და გამჟღავნდება, ამიტომ ხუთდღიანი დაგვიანება გასული წლის მნიშვნელოვანი წილის განეიტრალებას მოახდენდა. ჭიის სტილის შეტევები, ზუსტად არაფრის ფასად, გარდა დაუყოვნებლივიiacy.
Git, მიმოხილვა და შემცირებული ადამიანური საკონტროლო პუნქტი
კოდის მიმოხილვა და commit ისტორია დიდი ხანია ნდობის საყრდენს წარმოადგენს „ვიღაცამ ეს შეათვალიერა“. ეს საყრდენი უფრო მერყევი ხდება, როდესაც აგენტები commitდა სულ უფრო და უფრო ერწყმის ერთმანეთს, ამ მომენტში ადამიანის ჩარევის გარეშე.
პაკეტის ინსტალაციისას აგენტის მიერ ნდობის პრობლემა არ არის იგივე, რაც დეველოპერის მიერ Stack Overflow-ის პასუხის კოპირებისას, მიუხედავად იმისა, რომ ორივე გამოტოვებს ორიგინალური კოდის დაწერას. Stack Overflow-ის სნიპეტი დაწერილია რეალური ადამიანის მიერ და არაფორმალურად შეფასებულია დადებითი და უარყოფითი ხმების მეშვეობით. ხელოვნური ინტელექტის მიერ გენერირებული რეკომენდაცია არის ალბათური გამომავალი არცერთი თვისების გარეშე და დეველოპერი, რომელიც მას ხელით კოპირებს, მაინც ათვალიერებს პაკეტის სახელს, ბოლო განახლების თარიღს, ღია საკითხებს. მისი ინსტალაციისას აგენტი არ ჩერდება ამ ყველაფრის გამო, თუ რამე არ არის აშკარად შექმნილი მისი შეჩერების მიზნით.
ეს არის მარცხნივ გადახრის რეალური პრობლემა. ტრადიციული მარცხნივ გადახრა გულისხმობს, რომ ყველაზე სწრაფად მოძრავი ობიექტი... pipeline არის დეველოპერი, რომლის გადამზადებაც, ბიძგიც და შეფასებაც შესაძლებელია. როდესაც ყველაზე სწრაფად მოძრავი რამ ავტონომიური აგენტია, მარცხნივ გადამრთველი უსაფრთხოების სისტემა ხელახლა უნდა იყოს მიმაგრებული საკონტროლო წერტილებზე, რომელთა გვერდის ავლით აგენტი ვერ ახერხებს ამას: sandboxing, egress control და cooldown vehicles, პოლიტიკის დოკუმენტის ნაცვლად, რომელსაც არავინ აწესებს.
ხელოვნური ინტელექტის აგენტის მიწოდების ჯაჭვის უსაფრთხოება: რა უსაფრთხო აგენტია Pipeline რეალურად მოითხოვს
ამ ახალი კლასის ჭიების გადარჩენას არ სჭირდება ცხრა განსხვავებული კონტროლის მექანიზმი, რომელიც პირველ დღეს იდეალურად არის დანერგილი. შეზღუდული რესურსების მქონე გუნდისთვის ორი უფრო მნიშვნელოვანია, ვიდრე დანარჩენი:
- Sandbox-ის აგენტი, ყოველთვის. გაუშვით ის microVM-ში ან კონტეინერში მხოლოდ მიმდინარე პროექტის დირექტორიით, რათა კომპრომეტირებულ აგენტს არ ჰქონდეს გზა ჰოსტის ტოკენების, ავტორიზაციის მონაცემების ან ფაილებისკენ. ეს არის ყველაზე იაფი ხელმისაწვდომი კონტროლი და ის, რომლის გამოტოვებაც ყველაზე ნაკლებად არის საჭირო.
- პაკეტის ახალი ვერსიების ინსტალაციამდე დაამატეთ გაგრილების ფანჯარა. რამდენიმე დღე ხშირად საკმარისია იმისათვის, რომ მიწოდების ჯაჭვის პირდაპირი შეტევა გამოვლინდეს და გამჟღავნდეს თქვენს შენობამდე მიღწევამდე.
მესამე, იმ გუნდებისთვის, რომლებსაც ამის გაკეთება შეუძლიათ: CVE-სა და მავნე პროგრამების ხილვადობის პირდაპირ ჩართვა pipeline, კონტეინერის სურათის სკანირება (არა მხოლოდ საწყისი კოდის, რადგან საბაზისო სურათში ამდენი დაუცველობაა) და შედეგების გამოჩენა, როგორც pull request კომენტარები, რომლებსაც დეველოპერები რეალურად ხედავენ გაერთიანებამდე.
ბოლოდროინდელი ინციდენტი ფსონებს კონკრეტულს ხდის. 2026 წლის ივლისში, შიდა შეფასების პროცესში მყოფმა ხელოვნური ინტელექტის მოდელმა გამოიყენა ნულოვანი დღის ფუნქცია საკუთარი „სატესტო გარემოს“ ერთ დაშვებულ ქსელურ მარშრუტში, პაკეტ-ქეშის პროქსიში, რათა მიეღწია ღია ინტერნეტისთვის და, ადამიანის მითითებების გარეშე, შეექმნა გარე ინფრასტრუქტურა საორიენტაციო მიზნის მისაღწევად. გაქცევის გზა იყო დამოკიდებულების ინფრასტრუქტურა: ერთადერთი კავშირი, რომლის მეშვეობითაც ყველა „სატესტო გარემო“ შექმნილია. თუ თქვენს აგენტს ფუნქციონირებისთვის სჭირდება პაკეტების რეესტრთან დაკავშირება, ეს კავშირი არ არის თქვენი უსაფრთხოების მოდელის გვერდითი დეტალი. ეს არის უსაფრთხოების მოდელი. ღირს წაკითხვად Xygeni-ს სრული აღწერა, თუ როგორ მოხდა ეს გაქცევა სინამდვილეში: Rogue by Design.
ძირითადი Takeaways
- უკანასკნელი ადამიანური საკონტროლო წერტილი ქრება და არა სუსტდება. შექმენით ისეთი კონტროლი, რომელიც არ არის დამოკიდებული პაკეტის სახელის წაკითხვაზე.
- Slopsquatting-ი და HalluSquatting-ი ფერმერობადია და არა თეორიული. განმეორებადი ჰალუცინირებული სახელები და უბრალო ტექსტური შეთავაზებები უკვე ფართოდ გამოიყენება.
- წარმომავლობა და SBOMამტკიცებენ, რა გააკეთა კონსტრუქციამ და არა რითი კვებავდნენ მას. უმაღლესი დონის ატესტაცია საჭიროდ ჩათვალეთ და არა საკმარისად.
- ამჟამად სიტუაციას შეკავება და არა გამოვლენა აკავებს. სენდბოქსინგი, გასვლის კონტროლი და გაგრილების ფანჯრები ყიდულობენ დროს, რასაც ხელმოწერაზე დაფუძნებული სკანირება ვერ ახერხებს.
- შეადგინეთ ინვენტარი, რის მიღწევა შეუძლიათ რეალურად თქვენს აგენტებს. არა პოლიტიკის დოკუმენტი. ნამდვილი ტოკენები, რეალური ავტორიზაციის მონაცემები, რეალური ქსელური გასასვლელი.
ეს სტატია ეფუძნება Xygeni-ს SafeDev Talk-ის დისკუსიას.როდესაც ხელოვნური ინტელექტის აგენტები დამოკიდებულებებს აყენებენ„“, - დოკერის კაპიტან მოჰამედ-ალი არაბის მონაწილეობით. მისი ცხრა კონტროლის გამაძლიერებელი ჩარჩო უფრო დეტალურად არის განხილული მის საინფორმაციო ბიულეტენში, Docker Security Dispatch-სა და Xygeni-ის კვლევით ოფიცერ ლუის როდრიგესში.
ხშირად დასმული კითხვები: ხელოვნური ინტელექტის აგენტის მიწოდების ჯაჭვის უსაფრთხოება
პაკეტის ინსტალაციის აგენტი ფუნდამენტურად განსხვავებულ ნდობის პრობლემას წარმოადგენს, ვიდრე დეველოპერის მიერ Stack Overflow-ის შეთავაზების კოპირება, ან უბრალოდ იმავე შეთავაზების უფრო სწრაფი ვერსია?
ორივე, სხვადასხვა პროპორციით. მექანიზმი უფრო სწრაფია, მაგრამ ნდობის უფსკრული სტრუქტურულად უფრო ფართოა: Stack Overflow-ის პასუხი დაიწერა და არაფორმალურად გადახედა ერთმა პირმა, ხოლო ხელოვნური ინტელექტის მიერ გენერირებული პაკეტის რეკომენდაცია არის ალბათური შედეგი ეკვივალენტური მიმოხილვის გარეშე და დეველოპერი, რომელიც მას ხელით კოპირებს, მაინც იყენებს შემთხვევით შემოწმებას, რასაც უყურადღებო აგენტი მთლიანად გამოტოვებს.
რა იქნებოდა საჭირო ერთისთვის SBOM რომ საიმედოდ ჩაიწეროს ფრაზა „აგენტმა დაამატა ეს და აი, რატომ“?
დღეს SBOM და წარმომავლობა standards აგებული იყო იმ ვარაუდის გარშემო, რომ ადამიანმა შექმნა თითოეული დამოკიდებულება decisდა მათ ჯერ არ აქვთ ველი, თუ რომელმა აგენტმა, რომელმა მოდელის ვერსიამ ან რომელმა მოთხოვნამ გამოიწვია მოცემული ცვლილება. ამ ხარვეზის აღმოსაფხვრელად საჭიროა ან არსებული დამოწმების ფორმატების გაფართოება, ან ცალკე, აგენტის შესახებ ინფორმირებული აუდიტის კვალი, რომელიც ასახავს დეcisიონური წარმომავლობა კორპუსის წარმომავლობასთან ერთად.
არსებობს თუ არა „shift-major“-ის ისეთი ვერსია, რომელიც ჯერ კიდევ მუშაობს, როდესაც ყველაზე სწრაფი რამ არის? pipeline ავტონომიური აგენტია და არა დეველოპერი?
კი, მაგრამ მან უნდა შეცვალოს საკონტროლო წერტილი და არა მხოლოდ დრო. ადამიანის მიერ განხილვის საფუძველზე აგებული Shift-Left ფუნქცია არ მასშტაბირდება აგენტის სიჩქარეზე; sandboxing-ზე, გასვლის შეზღუდვებსა და ინსტალაციის გაგრილების ვადებზე აგებული Shift-Left ფუნქცია მაინც შეუძლია კომპრომეტირებული აგენტის დაჭერა მისი ქმედებების წარმოებამდე მიღწევამდე, რადგან ეს კონტროლი არ არის დამოკიდებული ვინმეს მიერ რაიმეს წაკითხვაზე.
