პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის სასიცოცხლო ციკლის საწყისი კოდიდან შესრულებადი არტეფაქტებისკენ პროგრესირებასთან ერთად, შექმნის ეტაპი კრიტიკულ ეტაპს წარმოადგენს. თუმცა, ეს ტრანსფორმაციული ფაზა ასევე მგრძნობიარეა მთელი რიგი საფრთხეების მიმართ, რომლებმაც შეიძლება საფრთხე შეუქმნას პროგრამული უზრუნველყოფის მთლიანობას და build securityამ საფრთხეებს შეუძლიათ შეაღწიონ შექმნის პროცესში სხვადასხვა მეთოდით, მათ შორის დადგენილი წესების გვერდის ავლით. CI/CD pipeline, კოდის შემდგომი წყაროს კონტროლის მოდიფიცირება, თავად შექმნის პროცესის კომპრომეტირება ან არტეფაქტების საცავების მანიპულირება. ამ ბლოგპოსტში ჩვენ სიღრმისეულად განვიხილავთ ამ საფრთხეებს და განვიხილავთ ყველაზე გავრცელებულ პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის შექმნის შეტევებს. ეს კონტენტი აგრძელებს ჩვენს ბლოგების სერიას, რომელიც შეისწავლის software supply chain security მთელი SDLC.
პროგრამული უზრუნველყოფის შემუშავების სასიცოცხლო ციკლის შექმნის ეტაპი
პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის სასიცოცხლო ციკლის შექმნის ეტაპი მოიცავს საწყისი კოდის შესრულებად პროგრამულ არტეფაქტებად გარდაქმნის პროცესს. ეს ეტაპი მოიცავს საწყისი კოდის კომპილაციას, დაკავშირებას და შეფუთვას, ასევე ინსტალაციის პაკეტებისა და კონფიგურაციის ფაილების გენერირებას.
Build security საფრთხეები არის დაუცველობა, რომელიც მოწინააღმდეგეს საშუალებას აძლევს, შექმნის პროცესში პროგრამული უზრუნველყოფაში არაავტორიზებული ცვლილებები შეიტანოს საწყისი კოდის შეცვლის გარეშე. ეს საფრთხეები შეიძლება შეტანილი იყოს სხვადასხვა მეთოდით, როგორიცაა შექმნის გარემოს კომპრომეტირება ან შექმნის ინსტრუმენტებში არსებული დაუცველობების გამოყენება.
პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის ყველაზე გავრცელებული საფრთხეები - Build Attacks
შემოვლითი CI/CD
ეს ეხება დადგენილი წესების გვერდის ავლის პრაქტიკას. CI/CD (უწყვეტი ინტეგრაცია და უწყვეტი მიწოდება) pipeline პროგრამული უზრუნველყოფის პირდაპირ შექმნა და გამოქვეყნება მკაცრი ტესტირების, შემოწმებისა და აუდიტის პროცესების გავლის გარეშე, რომლებსაც, როგორც წესი, ოფიციალური პირები ახორციელებენ. pipelineეს შეიძლება გაკეთდეს პროგრამული უზრუნველყოფის ხელით შექმნით გარეთ. CI/CD გარემოში ან ისეთი ხელსაწყოების ან სკრიპტების გამოყენებით, რომლებიც საშუალებას იძლევა შექმნის პროცესში არაავტორიზებული ცვლილებების შეტანის. ამ ტიპის ვექტორული შეტევის მაგალითი იყო ჯენკინსის შეტევა2022 წელს ჰაკერებმა შენობაში შეაღწიეს pipeline პოპულარული ღია კოდის პროგრამული უზრუნველყოფის პროექტის, სახელწოდებით Jenkins. ჰაკერებმა მავნე კოდი Jenkinsfile-ში შეიყვანეს, რომელიც სკრიპტია, რომელიც განსაზღვრავს შექმნის პროცესს. მავნე კოდმა ჰაკერებს საშუალება მისცა, გვერდი აევლოთ CI/CD pipelineუსაფრთხოების შემოწმებები და მათი კოდის შეყვანა შექმნის პროცესში. ეს კოდი შემდეგ სრულდება იმ ორგანიზაციების სისტემებში, რომლებმაც დააინსტალირეს პროგრამული უზრუნველყოფა.
კოდის შეცვლა წყაროს კონტროლის შემდეგ
ეს პრაქტიკა გულისხმობს წყაროს კოდში არაავტორიზებული ცვლილებების შეტანას მას შემდეგ, რაც ის უკვე... commitსანდო წყაროს მართვის სისტემაზე (SCS) და შემდეგ პროგრამული უზრუნველყოფის ამ მოდიფიცირებული კოდის გამოყენებით შექმნა. ეს შეიძლება გაკეთდეს დეველოპერის სამუშაო სადგურზე კოდის უშუალოდ შეცვლით ან გარე ხელსაწყოების ან სკრიპტების გამოყენებით, რათა მავნე კოდი შეიყვანონ შექმნის პროცესში. ამ ვექტორული შეტევის მაგალითი იყო GitLab-ის შეტევა 2022 წელს. ჰაკერებმა შეაღწიეს შექმნის სისტემაში. pipeline of გიტლაბიჰაკერებმა GitLab-ში მავნე კოდი შეიყვანეს CI/CD pipeline, რომელიც არის ინსტრუმენტი, რომელიც ავტომატიზირებს build security პროცესი. მავნე კოდმა ჰაკერებს საშუალება მისცა, კოდი შეეცვალათ წყაროს კონტროლის შემოწმების შემდეგ. ამან მათ საშუალება მისცა, თავიანთი კოდი პროგრამულ უზრუნველყოფაში შეეყვანათ, რომელიც შემდეგ იმ ორგანიზაციების სისტემებზე მუშაობდა, რომლებმაც პროგრამული უზრუნველყოფა დააინსტალირეს.
კომპრომისის შექმნის პროცესი
ეს გულისხმობს თავად შექმნის პროცესის მანიპულირებას ან შეცვლას, ან შექმნის გარემოზე პირდაპირი წვდომით, ან შექმნის ინსტრუმენტებში ან მესამე მხარის დამოკიდებულებებში დაუცველობების გამოყენებით. ეს შეიძლება გაკეთდეს შექმნის გამომავალში მავნე კოდის შეყვანის, შექმნის წყაროს გაყალბების ან შექმნის პროცესის მთლიანად ჩაშლის მიზნით. ამ ვექტორული შეტევის ყველაზე ცნობილი მაგალითი იყო SolarWinds თავდასხმათავდამსხმელმა არაავტორიზებული წვდომა მოიპოვა SolarWinds-ის შექმნის პლატფორმაზე, სისტემაზე, რომელიც გამოიყენება SolarWinds Orion პროგრამული უზრუნველყოფის კომპილაციისა და შეფუთვისთვის. ამ სკრიპტმა მავნე კოდი შეიტანა კომპილირებულ SolarWinds Orion პროგრამულ უზრუნველყოფაში. როდესაც მომხმარებლებმა დააინსტალირეს კომპრომეტირებული პროგრამული უზრუნველყოფა, მავნე კოდი მუშაობდა მათ სისტემებზე, რაც თავდამსხმელს არაავტორიზებული წვდომის საშუალებას აძლევდა მათ სისტემებზე. თავდამსხმელმა ასევე შეძლო მათი სისტემებიდან მგრძნობიარე მონაცემების მოპარვა, როგორიცაა ავტორიზაციის მონაცემები, ინტელექტუალური საკუთრება და მომხმარებლის ინფორმაცია.
არტეფაქტების საცავის კომპრომეტირება
ეს ეხება არტეფაქტების საცავის არაავტორიზებული წვდომას ან მანიპულირებას, სადაც პროგრამული უზრუნველყოფის პაკეტები და ბინარული ფაილები ინახება შიდა ან გარე მომხმარებლებისთვის გასავრცელებლად. თავდამსხმელებს შეუძლიათ გამოიყენონ ეს დაუცველობა მავნე კოდის შესატანად, პროგრამული უზრუნველყოფის ავთენტურობის შესაცვლელად ან განლაგების პროცესის ჩასაშლელად. ამ ვექტორული შეტევის მაგალითი იყო RubyGems 2022 წელსჰაკერებმა RubyGems-ის არტეფაქტების საცავში შეაღწიეს. ჰაკერებმა ლეგიტიმური არტეფაქტი მავნე არტეფაქტით შეცვალეს, რომელიც შემდეგ Ruby on Rails-ის გამოყენებით პროგრამული უზრუნველყოფის შემქმნელი ათასობით ორგანიზაციის მიერ იქნა გადმოწერილი. მავნე არტეფაქტმა ჰაკერებს საშუალება მისცა, პროგრამული უზრუნველყოფის ინსტალაციის მქონე ორგანიზაციების სისტემებზე თვითნებური კოდი შეესრულებინათ. ამან პოტენციურად შეიძლება მათ მონაცემების მოპარვის, მავნე პროგრამების ინსტალაციის ან ოპერაციების ჩაშლის საშუალება მისცეს.
დასკვნითი შენიშვნა
რადგან ორგანიზაციები აგრძელებენ პროგრამული უზრუნველყოფის შემუშავების პრაქტიკის დანერგვას, რომელიც ხაზს უსვამს ავტომატიზაციას და უწყვეტ მიწოდებას, პროგრამული უზრუნველყოფის შექმნის პროცესის უსაფრთხოების მნიშვნელობა არასდროს ყოფილა ასეთი დიდი. შექმნის ეტაპზე ძლიერი უსაფრთხოების ზომების დანერგვით, ორგანიზაციებს შეუძლიათ მნიშვნელოვნად შეამცირონ მავნე თავდასხმების მსხვერპლად გახდომის რისკი, რამაც შეიძლება საფრთხე შეუქმნას მათი პროგრამული უზრუნველყოფის მთლიანობას და უსაფრთხოებას.
ამ ბლოგ პოსტში აღწერილი სტრატეგიები და მოყვანილი მაგალითები შეგახსენებთ, რომ შექმნის ეტაპი პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის დაუცველი წერტილია. ორგანიზაციებმა ყურადღება უნდა მიაქციონ ამ საფრთხეებს და განახორციელონ საჭირო უსაფრთხოების ზომები თავიანთი პროგრამული უზრუნველყოფის თავდასხმისგან დასაცავად. ამით მათ შეუძლიათ უზრუნველყონ თავიანთი პროგრამული უზრუნველყოფის მთლიანობა, უსაფრთხოება და საიმედოობა მომხმარებლებისა და მომხმარებლებისთვის.
შემოგვიერთდით უსაფრთხო პროგრამული ეკოსისტემისკენ მიმავალ ჩვენს მოგზაურობაში
არ გაუშვათ ხელიდან ეს შესაძლებლობა, იყოთ წინ პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის საფრთხეების თავიდან აცილების კუთხით. გამოიწერეთ ჩვენი ბლოგი დღესვე და იყავით პირველი, ვინც მიიღებს ჩვენს უახლეს ინფორმაციას, რაც უზრუნველყოფს თქვენი ორგანიზაციის მდგრადობას და უსაფრთხოებას მზარდი საფრთხეების ფონზე. ერთად ჩვენ შეგვიძლია შევქმნათ უფრო ძლიერი და უსაფრთხო პროგრამული უზრუნველყოფის ეკოსისტემა ყველასთვის.
ნახეთ ჩვენი ვიდეო დემო
