პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის სასიცოცხლო ციკლის განმავლობაში პროგრამული უზრუნველყოფის შემუშავების პროგრესირებასთან ერთად, პაკეტის ეტაპი გადამწყვეტ ეტაპად გვევლინება, რომელიც საწყისი კოდის გარდაქმნას გავრცელებისთვის მომზადებულ შესასრულებელ არტეფაქტებად. თუმცა, ეს კრიტიკული ეტაპი დაუცველი არ არის, რაც მას პროგრამული უზრუნველყოფის მთლიანობისა და უსაფრთხოების შელახვის მცდელობის მქონე მავნე აქტორების მთავარ სამიზნედ აქცევს. ეს ბლოგპოსტი ამ ფაზაში წარმოშობილ გავრცელებულ საფრთხეებს იკვლევს და მათი შემცირების ეფექტურ სტრატეგიებს ასახავს. ეს კონტენტი ჩვენი ბლოგების სერიის გაგრძელებას წარმოადგენს, რომელიც... software supply chain security მასშტაბით SDLC.
პროგრამული უზრუნველყოფის შემუშავების სასიცოცხლო ციკლის პაკეტის ეტაპი
პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის სასიცოცხლო ციკლის პაკეტის ეტაპი მოიცავს პროგრამული უზრუნველყოფის შეფუთვისა და მომხმარებლებისთვის გავრცელებისთვის მომზადების პროცესს. ეს ეტაპი მოიცავს ინსტალაციის პაკეტების შექმნას, დამოკიდებულებების მართვას და პროგრამული უზრუნველყოფისთვის მეტამონაცემების გენერირებას.
აწყობის მთლიანობის საფრთხეები არის დაუცველობები, რომლებმაც შეიძლება თავდამსხმელებს საშუალება მისცენ შეფუთვის პროცესის დროს პროგრამულ უზრუნველყოფაში არაავტორიზებული ცვლილებები შეიტანონ. ეს საფრთხეები შეიძლება შეიყვანონ სხვადასხვა მეთოდით, როგორიცაა პაკეტის რეესტრის კომპრომეტირება, შეფუთვის ინსტრუმენტებში დაუცველობების გამოყენება ან მესამე მხარის დამოკიდებულებების მანიპულირება.
თანამედროვე პროგრამული უზრუნველყოფის ღია კოდის კომპონენტებზე სრული დამოკიდებულება ამ ეტაპს ყველაზე ხშირ S-ად აქცევდა.SCA სამიზნე. პოპულარულ ღია კოდის კომპონენტში ფარული მავნე პროგრამის დანერგვა ბევრი კიბერდამნაშავის ოცნებაა. სწორედ ამიტომ, 2023 წელს 245 000 მავნე პაკეტი აღმოაჩინეს.
მაგალითები Software Supply Chain Security საფრთხეები პაკეტის ეტაპზე
კომპრომეტირებული პაკეტის გამოყენება
ეს ეხება ისეთი პროგრამული პაკეტის განლაგების ან გამოყენების აქტს, რომელშიც მოწინააღმდეგემ შეცვალა ან დააზიანა თავი.
ეს შეიძლება მოხდეს პაკეტის ოფიციალური პაკეტების რეესტრის დატოვების შემდეგ, ან მომხმარებლის სისტემაზე პირდაპირი წვდომის გზით, ან სოციალური ინჟინერიის ტაქტიკის მეშვეობით, რომელიც მომხმარებელს ატყუებს და მავნე პაკეტის ჩამოტვირთვას ან ინსტალაციას აიძულებს. ამ ვექტორის მაგალითი იყო ბრაუზერიფი ტიპოსქვატირება შეტევა.
Linux-ისა და Mac სისტემების კომპრომეტირების მცდელობისას, თავდამსხმელმა შეიჭრა პოპულარული Node.js ბიბლიოთეკის, Browserify-ის, შემუშავების პროცესში. თავდამსხმელმა პროექტის საწყის კოდში მავნე კოდი შეიტანა, რათა NPM პაკეტების რეესტრის მეშვეობით გაევრცელებინა იგი. როგორც კი დაზიანებულ Browserify პაკეტს NPM-ზე აიტვირთებოდა, არაფრისმომცემი დეველოპერები ჩამოტვირთავდნენ და დააინსტალირებდნენ მას, რადგან თვლიდნენ, რომ ეს იყო ლეგიტიმური ვერსია. პაკეტში ჩაშენებული მავნე კოდი ჩუმად იმუშავებდა, რაც საფრთხეს უქმნიდა ინფიცირებული სისტემების მთლიანობას. ამან შეიძლება გამოიწვიოს მონაცემების მოპარვა, სისტემის არასტაბილურობა ან თავდამსხმელისთვის დისტანციური წვდომაც კი.
პაკეტების რეესტრის კომპრომეტირება
კომპრომეტირებული პაკეტების რეესტრი არის პროგრამული უზრუნველყოფის საცავი, რომელშიც შეაღწია მოწინააღმდეგემ, რომელმაც მოიპოვა არაავტორიზებული წვდომა რეესტრის ადმინისტრაციულ ინტერფეისზე ან ინფრასტრუქტურაზე.
ეს საშუალებას აძლევს მოწინააღმდეგეს შეცვალოს ან ჩაანაცვლოს ლეგიტიმური პროგრამული პაკეტები მავნე პროგრამებით, რომელთა გავრცელებაც შემდეგ შესაძლებელია მოულოდნელ დაინსტალირებულ მომხმარებლებზე. ამ ტიპის საფრთხის მაგალითი იყო შეტევა პაკეტის სარკეებზე: ღია კოდის პროგრამული უზრუნველყოფის პოპულარიზაციის მიზნით, მკვლევარმა რამდენიმე პოპულარული პაკეტის რეესტრი გატეხა, მათ შორის Maven Central, NPM და RubyGems. ამ რეესტრებზე წვდომის მოპოვებით, მკვლევარმა შეძლო ორიგინალური საცავების სარკეებისა და რეპლიკების შექმნა, რაც დეველოპერებს პაკეტების ჩამოტვირთვის მოსახერხებელ ალტერნატივას სთავაზობდა.
თუმცა, ამ სარკეებს ბოროტი მიზანი ჰქონდათ. კომპრომეტირებული სარკეები მკვლევარისთვის მავნე პაკეტების გავრცელების არხებად იქცნენ. ამ პაკეტებმა ჩაანაცვლეს ლეგიტიმური პაკეტები, რომლებიც პირველადი რეესტრების მიერ შეუმჩნეველი იყო და არაფრისმთქმელი დეველოპერები უნებლიეთ იტვირთავდნენ და აინსტალირებდნენ მათ. ინსტალაციის შემდეგ, ეს მავნე პაკეტები ათავისუფლებდნენ თავიანთ დატვირთვას, ასრულებდნენ თვითნებურ კოდს, იპარავდნენ მგრძნობიარე მონაცემებს ან არღვევდნენ ოპერაციებს.
შეცვლილი პაკეტის ატვირთვა
მოწინააღმდეგე საცავში ან დისტრიბუციის არხში ატვირთავს მოდიფიცირებულ პაკეტს, რომელიც შეიცავს მავნე კოდს ან დატვირთვას. ეს შეიძლება გაკეთდეს პაკეტის საწყისი კოდის, შეფუთვის ან მეტამონაცემების შეცვლით.
ამ ტიპის ერთ-ერთი ყველაზე ცნობილი საფრთხე იყო CodeCov-ის შეტევა 2021 წელს. თავდამსხმელი, რომელიც ცდილობს პროგრამული პროექტების კომპრომეტირებას CodeCov-ის გამოყენებით, პოპულარული უწყვეტი ინტეგრაციისა და უწყვეტი მიწოდების საშუალებით (CI/CD) ინსტრუმენტი, გაჟონილი სერთიფიკატების გამოყენებით, პროექტის Google Cloud Storage (GCS) ბაკეტზე არაავტორიზებული წვდომის მოპოვებას ცდილობდა. როგორც კი თავდამსხმელმა GCS ბაკეტზე წვდომა მოიპოვა, მან ატვირთა მავნე არტეფაქტი, CodeCov პაკეტის მოდიფიცირებული ვერსია, რომელიც შემდეგ მომხმარებლებისთვის CodeCov სერვისის საშუალებით გავრცელდა. ავტომატური განახლების ფუნქციაზე დაყრდნობით, არაფრისმომცემი დეველოპერები ჩამოტვირთავდნენ და დააინსტალირებდნენ მავნე პაკეტს, რადგან თვლიდნენ, რომ ის ლეგიტიმური იყო. ინსტალაციის შემდეგ, მავნე კოდი ჩუმად იმუშავებდა, რაც საფრთხეს უქმნიდა მის მიერ ინფიცირებული სისტემების მთლიანობას. ამან შეიძლება გამოიწვიოს მონაცემთა ქურდობა, სისტემის არასტაბილურობა ან თავდამსხმელისთვის დისტანციური წვდომაც კი.
პაკეტების რეესტრებზე თავდასხმები იმდენად გავრცელებულია, რომ ზოგიერთ თავდასხმის ნიმუშს შემდეგი სახელი ეწოდა:
In ტიპოქტაცია, მავნე პირი რეესტრში ატვირთავს რამდენიმე მავნე პაკეტს მცირე ორთოგრაფიული შეცდომებით ან მსგავსი სახელებით ლეგიტიმურ, პოპულარულ პაკეტებთან, იმ იმედით, რომ დეველოპერები არასწორად დაწერენ პაკეტის სასურველ სახელს მავნე სახელით. ხშირად მავნე პაკეტი ლეგიტიმურ პაკეტად იქცევა და შეუმჩნევლად გადის, რაც ზრდის ვარსკვლავების დაკვირვების ალბათობას.
დამოკიდებულების დაბნეულობა იყენებს იმ მეთოდს, რომლითაც ზოგიერთი პაკეტის მენეჯერი ამოწმებს მოთხოვნილ პაკეტებს მრავალი რეესტრიდან. როდესაც ორგანიზაცია იყენებს შიდა რეესტრში გამოქვეყნებულ შიდა კომპონენტებს, თავდამსხმელმა, რომელმაც იცის ეს ფაქტი, შეიძლება გამოაქვეყნოს მავნე კომპონენტი იმავე სახელით საჯარო რეესტრში. თუ შიდა კომპონენტისთვის გამოყენებული სახელი არ არის განსაზღვრული, ზოგიერთი პაკეტის მენეჯერი მიიღებს მავნე კომპონენტს შიდა კომპონენტის ნაცვლად.
ერთად ტროიანის პაკეტები, კიბერდანაშაული მავნე პროგრამას სასარგებლო ვალიდურ კოდს შორის მალავს. ეს შეიძლება გამოყენებულ იქნას რეალური ავტორის ან კონტრიბუტორის მიერ, რომელიც პაკეტის შენარჩუნებას სთავაზობს საკუთარ თავს. ეს ასევე ცნობილია, როგორც პაკეტის გატაცებათავდამსხმელებმა არსებული პაკეტის გასატეხად მრავალი ტექნიკა გამოიყენეს, მაგალითად დომენის აღება სადაც თავდამსხმელმა აიღო მიტოვებული და ვადაგასული დომენი, რომელმაც ხელახლა შექმნა ძველი მომვლელის ელ.ფოსტა და პაროლის აღდგენა მოახდინა მომვლელის ანგარიშის ასაღებად.
დასკვნითი შენიშვნა
რადგან ორგანიზაციები სულ უფრო ხშირად იყენებენ პროგრამული უზრუნველყოფის შემუშავების მეთოდოლოგიებს, რომლებიც პრიორიტეტს ანიჭებენ ავტომატიზაციას და უწყვეტ მიწოდებას, პროგრამული პაკეტის ეტაპის უსაფრთხოების მნიშვნელობა არასდროს ყოფილა ასეთი მნიშვნელოვანი. ამ კრიტიკულ ფაზაში ძლიერი უსაფრთხოების ზომების განხორციელებით, ორგანიზაციებს შეუძლიათ მნიშვნელოვნად შეამცირონ მავნე შეტევების რისკი, რამაც შეიძლება საფრთხე შეუქმნას მათი პროგრამული უზრუნველყოფის მთლიანობას და უსაფრთხოებას.
ამ ბლოგ პოსტში აღწერილი სტრატეგიები, მოწოდებულ მაგალითებთან ერთად, მკაფიო შეხსენებაა იმისა, რომ პაკეტის ეტაპი პროგრამული უზრუნველყოფის მიწოდების ჯაჭვში დაუცველ წერტილს წარმოადგენს. ორგანიზაციებმა ყურადღება უნდა მიაქციონ ამ საფრთხეებს და განახორციელონ საჭირო უსაფრთხოების ზომები მათი პროგრამული უზრუნველყოფის თავდასხმისგან დასაცავად. ამით მათ შეუძლიათ უზრუნველყონ თავიანთი პროგრამული უზრუნველყოფის მთლიანობა, უსაფრთხოება და საიმედოობა მომხმარებლებისა და მომხმარებლებისთვის.
შემოგვიერთდით უსაფრთხო პროგრამული ეკოსისტემისკენ მიმავალ ჩვენს მოგზაურობაში
არ გაუშვათ ხელიდან შანსი, ერთი ნაბიჯით წინ იყოთ ამ სფეროში software supply chain securityგამოიწერეთ ჩვენი ბლოგი დღესვე და იყავით პირველები, ვინც მიიღებს ჩვენს უახლეს ინფორმაციას, რაც უზრუნველყოფს თქვენი ორგანიზაციის მდგრადობასა და უსაფრთხოებას მზარდი საფრთხეების ფონზე. ერთად ჩვენ შეგვიძლია შევქმნათ უფრო ძლიერი და უსაფრთხო პროგრამული უზრუნველყოფის ეკოსისტემა ყველასთვის.
გახსოვდეთ, software supply chain security ეს არის მიმდინარე მოგზაურობა და არა დანიშნულების ადგილი. უსაფრთხოების პრაქტიკის მუდმივი შეფასებითა და ადაპტირებით, ახალი საფრთხეების მოსაგვარებლად, ორგანიზაციებს შეუძლიათ დაიცვან თავიანთი პროგრამული უზრუნველყოფის მიწოდების ჯაჭვი და მიაწოდონ მომხმარებლებს სანდო პროგრამული უზრუნველყოფა.
ნახეთ ჩვენი ვიდეო დემო
