ეს მეოთხე ეპიზოდია სერიალში პოსტების სერია მავნე კომპონენტების შესახებ, სადაც ჩვენ წარმოგიდგენთ ქსიგენი ამ საფრთხის მართვის მიდგომა, როგორც ჩვენი დაფარვის ნაწილი Open Source Security.
ჩვენ ვნახეთ, რომ გაურკვეველი წყაროს მქონე ღია კოდის კომპონენტების მიმართ გადაჭარბებული ნდობა გამოიყენება ყველა სახის დამნაშავეების მიერ მოულოდნელი ქცევის გამოსაწვევად, რომელიც ან დეველოპერულ მანქანებზე უნდა გაშვებულიყო, CI/CD სისტემები, ან ჩაშენებული მსხვერპლი ორგანიზაციის პროგრამულ უზრუნველყოფაში, რათა ის გადაეცეს ორგანიზაციის კლიენტებს. ჩვენ გავაანალიზეთ ეპიზოდი #2 საჯარო რეესტრების გამოყენებით მავნე პროგრამების გავრცელების შეტევები და რა ვისწავლეთ ცუდი აქტორების მოქმედების ყურების შემდეგ და წინა ეპიზოდი #3 შესწავლილი იქნა ამ საფრთხის წინააღმდეგ ეფექტური (და უშედეგო) კონტროლის საშუალებები.
ახლა დროა, განვიხილოთ პრობლემისადმი ჩვენი მიდგომა. ამ ეპიზოდში წარმოგიდგენთ სტრატეგიას, რომელსაც Xygeni-ში ვიყენებთ ჩვენი... მავნე პროგრამების ადრეული გაფრთხილება (MEW) სისტემა. როგორ მუშაობს ეს მრავალსაფეხურიანი სისტემა რეალურ დროში, როდესაც პაკეტის ახალი ვერსია გამოდის, როგორ ხდება მტკიცებულებების შეგროვება სხვადასხვა წყაროდან, როგორ ხდება ტრიაჟი, რა კლასიფიკაციის კრიტერიუმებს ვიცავთ და რატომ არის საჭირო გარკვეული ხელით ანალიზი მავნე პაკეტის კანდიდატის ბუნების დასადასტურებლად. ჩვენ ასევე ავხსნით, თუ როგორ ვეხმარებით NPM-ს, GitHub-ს, PyPI-ს და ღია კოდის ეკოსისტემებში არსებულ სხვა ძირითად ინფრასტრუქტურებს მავნე პროგრამების შენახვის დროის შემცირებაში.
ის pipeline
Xygeni Malware Early Warning (MEW) მუდმივად ამუშავებს კომპონენტს, ან პაკეტურ tarball ფაილებს ბიბლიოთეკებისა და ჩარჩოებისთვის მხარდაჭერილი პროგრამირების ეკოსისტემებისთვის, როგორიცაა JavaScript/Node ან Python, Docker/OCI კონტეინერის სურათები, ან გაფართოებები და დანამატები ისეთი ინსტრუმენტებისთვის, როგორიცაა IDE ან CI/CD სისტემები. ასეთი კომპონენტები გამოქვეყნებულია საჯარო რეესტრებში მომხმარებელთა შემოწმების სხვადასხვა დონით.
ქვემოთ მოცემულია სისტემის მუშაობის სქემატური ხედვა:
ის აღმომჩენი პროცესი იღებს გამოქვეყნების მოვლენების შესახებ ინფორმაციას. გამოქვეყნების მოვლენა არის ახალი ან არსებული კომპონენტის ახალი ვერსიის შექმნა. რადგან პოპულარული რეესტრები არ უზრუნველყოფენ pub-sub მექანიზმს დაინტერესებული მომხმარებლებისთვის, ეს ხშირად ხდება რეესტრის ბოლოდროინდელი მოვლენების გამოკითხვით. შესანიშნავი პროექტი OSSF-ისგან, პაკეტების მიწოდება, მხარდაჭერა პოპულარული რეესტრები, როგორიცაა PyPI ან Maven Central, და უზრუნველყოფენ ერთიან, არხზე დაფუძნებულ ინტერფეისს. MEW-ში ჩვენ დავამატეთ რამდენიმე სპეციფიკური იმპლემენტაცია, რომელიც ამცირებს ლოდინის დროს, მაგალითად, NPM-ის მიერ გამოყენებული CouchDB მონაცემთა ბაზის რეპლიკა, რომელიც სინქრონიზებულია საჯარო რეესტრის მონაცემთა ბაზასთან.
Xygeni-ში ჩვენ გვაქვს ინვენტარი[1] ჩვენი მომხმარებლების პროგრამული უზრუნველყოფის მიერ გამოყენებული ყველა კომპონენტის (პირდაპირ ან ირიბად). მომხმარებლების კომპონენტების კოორდინატები რეგულარულად მიეწოდება MEW-ს ანალიზის პრიორიტეტულობის დასადგენად: ჩვენი მომხმარებლების მიერ გამოყენებული კომპონენტები უფრო ადრე მუშავდება. პრიორიტეტი ასევე ეფუძნება გამომცემლის რეპუტაციას და კომპონენტის კრიტიკულობას, ამიტომ დაბალი რეპუტაციის მქონე გამომცემლებისგან მომდინარე კომპონენტებსაც ენიჭება პრიორიტეტი.
ის ანალიზატორები შემდეგ მოიხმარენ პრიორიტეტულ რიგში არსებულ მომლოდინე კომპონენტებს. როდესაც კომპონენტის ვერსია ანალიზისთვის შეირჩევა, მისი tarball იტვირთება რეესტრიდან. გაითვალისწინეთ, რომ გაანალიზებულია შეფუთული, ორობითი კომპონენტი: ღია კოდის კომპონენტების უმეტესობა, როგორც წესი, მოდის ღია კოდის საცავიდან, ხშირად github.com-ზე, რომელიც გამოიყენება მხოლოდ კონტექსტისთვის და მავნე პროგრამა ყოველთვის მოიძებნება კომპონენტის tarball-ში, რადგან საფრთხის შემქმნელები სისტემატურად იტყუებიან იმ წყაროების შესახებ, რომლებიც, მათი თქმით, გამოიყენეს მათ მიერ გამოშვებული კომპონენტის tarball-ის ასაგებად.
მომხმარებლის პერსპექტივიდან
მესმის თქვენი ფიქრი: რა სარგებელი მოაქვს მავნე პაკეტის ვერსიის შესახებ ადრეულ ეტაპზე ცოდნას? ეპიზოდში „მავნე პაკეტების ანატომია: რა ტენდენციებია?“ ჩვენ დავინახეთ, რომ საერთო დაყოვნების დრო დღეების დიაპაზონშია, ხოლო MEW-სგან დაზარალებული კომპონენტის მომხმარებლებისთვის პირველი შეტყობინება წუთების დიაპაზონშია. მარტივი დამცავი ღობით[2] შეგიძლიათ დაბლოკოთ ბილდი (არსებობს ორი განგაშის დონე, ერთი სრულიად ავტომატიზირებულია, როდესაც ძრავა დაასკვნის, რომ არსებობს პოტენციური მავნე პროგრამა და მოგვიანებით შეტყობინება, როდესაც ჩვენი უსაფრთხოების გუნდი ხელით შემოწმებით დაადასტურებს მავნე პროგრამის არსებობას). რეესტრის მიერ მავნე პროგრამის დადასტურებისა და რეესტრიდან მისი წაშლის ლოდინი, როგორც წესი, ძალიან გვიანია ხანგრძლივი ექსპოზიციის ფანჯრის გამო.
ორგანიზაციას შეუძლია გამოიყენოს დამცავი ბარიერი, რომელიც ამოწმებს, არის თუ არა პოტენციურად მავნე პროგრამის შემცველი კომპონენტი (ორი განგაშის დონედან რომელიმეში) ან, API-ის საშუალებით, სწრაფად გაიგოს, იყენებს თუ არა პროგრამული უზრუნველყოფის პროექტში რომელიმე პირდაპირი ან ირიბი დამოკიდებულება მავნე კომპონენტს.
როგორ მუშაობს MEW: დეტალები შიგნით
ბირთვი: მავნე პროგრამების აღმოჩენის ძრავა
ანალიზატორი იყენებს სხვადასხვა დეტექტორს არასწორი ქმედების მტკიცებულებების აღსაწერად. დეტექტორები აერთიანებენ სტატიკურ ანალიზს, შესაძლებლობების ანალიზს და კონტექსტის ანალიზს.[3], როგორც ეს ამ სერიის წინა პოსტშია აღწერილი.
Xygeni-ში ჩვენ გვყავს ინჟინერთა გუნდი, რომელსაც სტატიკურ ანალიზში დიდი გამოცდილება აქვს და ეს არის მთავარი განსხვავება სხვა ანტი-მავნე პროგრამების გადაწყვეტილებებთან. გაითვალისწინეთ, რომ ზოგიერთი ეკოსისტემისთვის შეფუთული tarball შეიცავს ან წყაროს კოდს (მაგ. JavaScript ან TypeScript კოდი NPM პაკეტებისთვის, Python-ის წყაროები PyPI პაკეტებისთვის), ან კომპილირებულ კოდს, რომელიც საკმარისად ახლოსაა წყაროს კოდთან სტატიკური ანალიზისთვის (მაგ. ბაიტკოდი JAR ფაილებში Maven-ისთვის). სხვებისთვის, როგორიცაა კონტეინერის სურათები, ბინარული შესრულებადი ფაილები ხშირია, ამიტომ შესაძლებლობების ინფერენცია არის გამოყენებული ტექნიკა, YARA წესებისა და მავნე პროგრამების ხელმოწერების საფუძველზე ტრადიციული მავნე პროგრამების აღმოჩენასთან ერთად.
გთხოვთ გაითვალისწინოთ, რომ მარტივი ტექნოლოგიები, როგორიცაა რეგულარული გამოსახულებები ან ხელმოწერები, არ არის შესაფერისი მავნე ქცევის აღმოსაჩენად. წარმოიდგინეთ dropper-ის ან ჩამოტვირთვის პროგრამის აღმოჩენა: პაკეტში მდებარეობს გარკვეული კოდი ან ბინარული ფაილი ან გადმოწერილია გარე დომენიდან, რომელიც არ არის დაკავშირებული კომპონენტთან (შეიძლება იყოს ერთ-ერთი საფრთხის შემქმნელის მიერ შეძენილი დომენების დიდი სია[4]ან ლეგიტიმური დომენი აღმოჩენის თავიდან ასაცილებლად). შემდეგ ეს კოდი შესრულდება შესაბამისი ფუნქციებიდან ერთ-ერთის გამოყენებით. კოდის ტრანსფორმაცია შესაძლებელია ჩამოტვირთვის URL-ის ან ჩამოტვირთული კოდის გასაშვებად გამოყენებული ფუნქციის დასამალად. მის აღმოსაჩენად საჭიროა მონაცემთა ნაკადის სრული ანალიზი, რომლის აღმოჩენაც შესაძლებელია სტატიკური ანალიზის სრული მექანიზმის გამოყენებით, ან ზოგად შემთხვევაში, sandboxed შესრულების გამოყენებით (თუ მავნე ქცევის გაშვების პირობები რეალურად დაკმაყოფილებულია).
საფრთხის შემქმნელები იმავე ტექნიკას იყენებენ და მათთვის დეტექტორები შეიქმნა და დანერგილია. ასევე არსებობს წინასწარი დამუშავების რამდენიმე ეტაპი, მაგალითად, დაბინდვის მოხსნისთვის, რაც ხშირად საჭიროა დაფარული ქცევის გამოსავლენად.
კონტექსტის დამატება
ზოგიერთი დეტექტორი იყენებს კონტექსტურ ინფორმაციას. მაგალითად, კომპონენტების რეესტრში არსებულ ვერსიასა და GitHub-ის შესაბამის საცავში არსებულ ტეგს/რელიზს შორის შეუსაბამობა წარმოადგენს ძლიერ მტკიცებულებას იმისა, რომ შესაძლოა, არაკეთილსინდისიერმა პირმა მოიპოვა რეესტრის გამოქვეყნების ავტორიზაცია, მაგრამ არა GitHub-ის საცავისთვის. შეტევები, როგორიცაა კრიპტო საფულის გამყიდველზე მოქმედი შეტევები ledger ამ შეუსაბამობის ადვილად ამოცნობა შეიძლებოდა.
A მავნებლობის ქულა (MS) გამოითვლება დეტექტორების გაშვების შედეგებიდან, მოპოვებული მტკიცებულებების სიძლიერის მიხედვით. ყველა დასკვნა ერთნაირი არ არის და შესრულების თანმიმდევრობაც მნიშვნელოვანია.
მომხმარებლის და კომპონენტის რეპუტაცია
ყველა ღია კოდის დეველოპერი ერთნაირი არ არის!
შესაძლოა, სანდო დეველოპერს NPM ანგარიში გაუტეხონ (ეს უსაფრთხოების შესახებ ინფორმირებულ ადამიანებსაც კი ემართებათ) და ამ ანგარიშის გამოყენებით მავნე პროგრამა გამოაქვეყნონ. ცხადია, რეპუტაცია მკვეთრად უნდა დაეცეს და მხოლოდ მას შემდეგ აღდგეს ძველი დიდება, რაც გატეხილი ანგარიში აღდგება და დეველოპერი გამოასწორებს იმ პირობებს, რამაც ანგარიშის ხელში ჩაგდება გამოიწვია. რეპუტაციის მოპოვება რთულია, მაგრამ მისი დაკარგვა მყისიერად შეიძლება.
MEW-ში ჩვენ დანერგეთ რეპუტაციის მართვის ყოვლისმომცველი სისტემა, რომელიც დააჯილდოებს და დასჯის საეჭვო აქტივობებს. ეს სისტემა იწყება ახალი მომხმარებლებით, რომლებიც ნეიტრალურ პოზიციას იკავებენ და არეგულირებს მათ რეპუტაციას მათი მიმდინარე აქტივობების მიხედვით.
მომხმარებლის რეპუტაცია უმჯობესდება ისეთი პოზიტიური ქმედებებით, როგორიცაა აქტიური სოციალური მედიის ანგარიშების შენარჩუნება, მრავალფაქტორიანი ავთენტიფიკაციის ჩართვა, პროექტებში რეგულარული წვლილის შეტანა და ხელმოწერა. commitდამოწმებადი გასაღებებით. პირიქით, რეპუტაცია უარესდება ისეთი მტრული ქმედებების გამო, როგორიცაა მავნე პროგრამების გამოქვეყნება, ერთჯერადი ელექტრონული ფოსტის მისამართების გამოყენება, ხელმოწერის არარსებობა. commits, ან შენატანებში უჩვეულო ნიმუშების გამოვლენა.
ჩვენი სისტემის მთავარი მიზანია უსაფრთხო და სანდო გარემოს უზრუნველყოფა. ეს მიიღწევა მომხმარებლის რეპუტაციის დინამიურად რეგულირებით სხვადასხვა ფაქტორზე დაყრდნობით, კონფიდენციალურობის საკითხებისა და სხვადასხვა რეესტრის შეზღუდვების გათვალისწინებით.
მომხმარებლისთვის გამოითვლება შიდა რეპუტაციის ქულა (შესაძლებლობის შემთხვევაში, რეესტრსა და Github ანგარიშში შეერთებით) და ანალიზის ქვეშ მყოფი კომპონენტის კლასიფიკაციის დროს გამოყენებული მავნებლობის ქულასთან ერთად, ასევე კომპონენტის გამოქვეყნების ქვეშ მყოფი პირების უკეთ დასადგენად.
მავნე ქცევის მტკიცებულება აღმოჩნდა. მერე რა? ხელით განხილვის პროცესი
მიმდინარე კლასიფიკატორი კომპონენტის გაანალიზებულ ვერსიას შემდეგ კატეგორიებად ათავსებს: „დადასტურებულად მავნე“, „სავარაუდოდ მავნე“, „მაღალი რისკის“, „დაბალი რისკის“ ან „არამავნე“ დასკვნებისა და მომხმარებლის/კომპონენტის რეპუტაციის შეჯამების ქულების ზღვრული მაჩვენებლების მიხედვით. „მაღალი რისკის“ ან „სავარაუდოდ მავნე“ კატეგორიებად კლასიფიკაცია იწვევს ხელით განხილვას და პირველ შეტყობინებას. „დადასტურებულად მავნე“ კატეგორია დგინდება ხელით განხილვის შემდეგ ან როდესაც მტკიცებულებები ემთხვევა წინა ვერსიის იმავე მტკიცებულებებს, რომელიც დადასტურებულად მავნე იყო.
როდესაც პოტენციური მავნე ქცევის საკმარისი მტკიცებულება არსებობს, დაზარალებულ ორგანიზაციებს ეგზავნება პირველი განგაში (კარანტინის განგაში). როგორც ზემოთ აღინიშნა, ამან შეიძლება დაბლოკოს კარანტინში მყოფ კომპონენტზე დამოკიდებული პროგრამული უზრუნველყოფის ინსტალაცია ან აწყობა.
ეს MEW-ის შიდა პრობლემას ქმნის. dashboard ამგვარად, უსაფრთხოების ანალიტიკოსებს შეუძლიათ კომპონენტის ხელით განხილვის პროცესის დაწყება. გუნდს აქვს სპეციალიზებული ინსტრუმენტები (სატესტო გარემო, დეობფუსკატორები, მავნე პროგრამების კვლევის დისტრიბუტორი, მავნე პროგრამების შესახებ ინფორმაციის მიწოდების ინსტრუმენტები) გამოძიების ქვეშ მყოფი კომპონენტის ვერსიის ბუნების სწრაფად შესაფასებლად. მავნე პროგრამების უმეტესობა („ანჩოუსები“ ანუ მარტივი მავნე კომპონენტები) განხილულია.
განხილვის შედეგი მთავრდება შემდეგნაირად: უსაფრთხო, ანუ ავტომატური ანალიზის ძრავამ აღმოაჩინა ცრუ დადებითი შედეგი, რომელიც გამოიყენება როგორც უკუკავშირი მანქანური სწავლების კლასიფიკატორისთვის ნიმუშის შესასწავლად; ან დადასტურებული მავნე, ამიტომ კომპონენტი პასუხისმგებლობით ცხადდება, როგორც მავნებელი საჯარო რეესტრში, ანგარიშგების პროცესის შემდეგ. მეორე შეტყობინება იგზავნება დაზარალებულ ორგანიზაციებთან, რომლებმაც, თავის მხრივ, შეიძლება კომპონენტის კარანტინის მოხსნა, ან მისი დაბლოკვა მათი ვერსიის განახლების პროცესიდან ან მათ შიდა რეესტრში გამოყენებული კომპონენტის firewall-იდან.
ეს პარამეტრი საშუალებას გვაძლევს ყოველდღიურად გავაანალიზოთ ათიათასობით ახალი ვერსია და გამოვავლინოთ ათობით, რომლებიც სავარაუდოდ მავნეა, რომლებსაც შემდეგ ხელით ვამოწმებთ. წინა ეპიზოდიდან გახსოვდეთ, რომ ამჟამად ველურ ბუნებაში არსებული მავნე კომპონენტების მაჩვენებელი ათიდან ერთია.
რეესტრში ანგარიშგება
ჩვენ აღმოვაჩინეთ, რომ საჯარო რეესტრების უმეტესობა, ღია კოდის ინფრასტრუქტურის ერთ-ერთი ხერხემალი, უსაფრთხოების პრობლემების, კერძოდ კი მავნე კომპონენტების შესახებ შეტყობინების საკმაოდ შეზღუდულ მექანიზმებს გვთავაზობს. ჩვენ ვცდილობთ, გავაუმჯობესოთ შეტყობინების პროცესის ძირითადი ორგანიზება. როგორც წესი, რეესტრის უსაფრთხოების გუნდისგან მაქსიმუმ ვიღებთ უკუკავშირის ელფოსტას, რომელიც ადასტურებს, რომ კომპონენტი ამოღებულია რეესტრიდან.
ზოგჯერ რეესტრი ბოროტად გამოიყენება, რაც მისი გამოყენების პირობებს არღვევს, მაგრამ მოწოდებულ პროგრამულ უზრუნველყოფაში მავნე ქცევას არ იწვევს. ეს ასევე ეცნობება რეესტრს, მაგრამ ორგანიზაციებს არ ეცნობება ხმაურის შესამცირებლად.
მომავალი სამუშაო
ამჟამად ბევრი გაუმჯობესებაა დაგეგმილი. უპირველეს ყოვლისა, ა საჯარო პორტალი OS კომპონენტების მდგომარეობის შესახებ, განსაკუთრებით პოტენციური მავნებლობის შესახებ აღმოჩენილ მტკიცებულებებთან დაკავშირებული, ამჟამად შემუშავების პროცესშია. ეს მოკრძალებული წვლილია ღია კოდის საზოგადოებისთვის. თვალყური ადევნეთ სიახლეებს.
კიდევ ერთი მიმდინარე განვითარება გაუმჯობესებულია მანქანური სწავლების კლასიფიკატორი. MEW ისწავლის წარსული კლასიფიკაციებიდან. ძრავის დეტექტორებიდან მიღებული დასკვნების ვექტორი, პლუს კომპონენტისა და გამომცემლისთვის მიღებული მავნეობის ქულა და რეპუტაციის ქულა („ნაპოვნი მტკიცებულება“) გამოიყენება როგორც შემავალი მონაცემები მანქანური სწავლების სისტემისთვის, რომელიც აახლებს კლასიფიკატორის მოდელს. გამომავალი ცვლადი უბრალოდ არის, დაადასტურა თუ არა რეესტრმა კომპონენტი მავნე იყო თუ არა. ამას კოდური სახელი აქვს „ორაკული“ და დაეხმარება უფრო წინასწარ განსაზღვრაში.cisკვალიფიკაცია, შექმნილია ისე, რომ იყოს საიმედო (მაღალი დამახსოვრება, ანუ არ გამოტოვოს მავნე კომპონენტები), მაგრამ ნაკლები ცრუ დადებითი შედეგით (არ მოახდინოს უსაფრთხო კომპონენტების მავნედ მოხსენიება).
A კრიტიკულობის ქულა დაემატება პრიორიტეტულობის კრიტერიუმებს, მომხმარებელთა დამოკიდებულების ერთობლიობასთან კუთვნილების და გამომცემლის დაბალი რეპუტაციის გარდა. ცხადია, რომ უფრო მეტი გავლენისა და მნიშვნელობის მქონე პროექტები ანალიზისთვის ადრე უნდა იქნას განხილული. აქ ჩვენ ხელახლა არ გამოვიგონებთ ბორბალს და მივყვებით ღია კოდის პროექტის კრიტიკულობის ქულა.
დამატებითი ეკოსისტემების მხარდაჭერა შემუშავების პროცესშია. ფართოდ გავრცელებული ტექნოლოგიები და ინსტრუმენტები, როგორიცაა PHP ან Jenkins-ის დანამატები, გეგმაშია.
ჩვენ ასევე ვიკვლევთ, შეიძლება თუ არა ხელოვნური ინტელექტის დახმარებით ხელით განხილვის პროცესი უფრო დახვეწილი მავნე კომპონენტების ანალიზის გამარტივება.
ამ სერიის შემდეგ და ბოლო ნაწილში, „ღია კოდის ექსპლუატაცია: რას უნდა ველოდოთ ბოროტმოქმედებისგან„ჩვენ ყურადღებას გავამახვილებთ მოწინააღმდეგეების მიერ გამოყენებულ უახლეს გზებზე, რათა თავდასხმები უფრო ფარული, უფრო რთული აღმოსაჩენი, უფრო მეტად კონკრეტული ინდუსტრიებისთვის მიზანმიმართული და უფრო მომგებიანი გახადონ. განხორციელდება თუ არა გამოსასყიდის მოთხოვნით შექმნილი შეტევები ამ მეთოდის გამოყენებით? როგორ იყენებენ ბოროტმოქმედები ხელოვნური ინტელექტის ინსტრუმენტებს უფრო დახვეწილი მავნე პროგრამების გასავრცელებლად? ემუქრებათ თუ არა ყველაზე პოპულარული პროექტები რისკის ქვეშ? ეს კეთდება იმისათვის, რომ მკითხველს წარმოდგენა შეექმნას ამ შეიარაღების რბოლის შესახებ და რას უნდა ველოდოთ მოკლევადიან (2024 წლის მეორე ნახევარი) და საშუალოვადიან (2025) პერსპექტივაში.
დასასრულს, ჩვენ რამდენიმე ფიქრით განვიხილავთ, თუ რა მცირე ნაბიჯების გადადგმა შეუძლია საზოგადოებას ღია კოდის სამყაროს ღიაობის ზედმეტად შეცვლის გარეშე. მაგალითად, მავნე პროგრამების შესახებ საჯარო რეესტრებისთვის შეტყობინების უფრო ეფექტური მექანიზმი და პოტენციურად მავნე კომპონენტების შესახებ მტკიცებულებების რეესტრებსა და საზოგადოებასთან გაზიარება იქნებოდა მცირე ნაბიჯი სწორი მიმართულებით, რათა მიღწეული იქნას მიზნისკენ, რომელიც საფრთხეს უქმნის საფრთხეს.
ღია კოდის კომპონენტებში მავნე პროგრამებმა არ უნდა შეაფერხოს ის უზარმაზარი სარგებელი, რაც ღია კოდის საზოგადოებამ ჩვენს საზოგადოებას მოუტანა.
- [1] ჩვენი სკანერი აღმოაჩენს ღია კოდის კომპონენტებს, რომლებზეც მიუთითებს გაანალიზებული პროგრამული პროექტები, ამიტომ სრული განახლებული დამოკიდებულების გრაფიკი ცნობილია, სულ მცირე იმ პროექტებისთვის, რომლებიც რეგულარულად სკანირდება. Xygeni OSS ავლენს API-ს, რომელიც მომხმარებლებმა შეიძლება გამოიყენონ საინტერესო კომპონენტის თეთრ სიაში შეყვანისას, მათ შორის ინფორმაციას დაუცველობისა და მავნე მტკიცებულებების შესახებ.
- [2] უსაფრთხოების პრობლემების შესაბამისი პირობის აღმოჩენის შემთხვევაში, დამცავი ბარიერი შეიძლება აწყობის დარღვევას იწვევდეს. უსაფრთხოების ისეთი აღმოჩენები, როგორიცაა კრიტიკული და ხელმისაწვდომი დაუცველობა ან კარანტინში მოთავსებული კომპონენტის გამოყენება, შეიძლება საკმარისად სერიოზულად ჩაითვალოს დაზარალებული პროგრამული უზრუნველყოფის აწყობის დარღვევად.
- [3]ჩვენი უსაფრთხოების ანალიტიკოსები საჭიროების შემთხვევაში კომპონენტს ან მის ინსტალაციის სკრიპტებს საცდელ გარემოში ამუშავებენ. თუმცა, MEW არ ახორციელებს დინამიურ ანალიზს, ძირითადად იმიტომ, რომ მავნე ქცევა ყოველთვის არ ხორციელდება მიზნობრივი შეტევების დროს და იმ თავის არიდების ლოგიკის გამო, რომელსაც საფრთხის შემქმნელები იყენებენ დინამიური ანალიზისგან თავის დასაღწევად.
- [4] ამ ტექნიკას სახელი მიენიჭა, რეგისტრირებული დომენის გენერირების ალგორითმები ან RDGA და გაჩნდა ახალი საფრთხის შემქმნელები, როგორიცაა ე.წ. რევოლვერ კურდღელი 500 ათას დომენში 1 მილიონი დოლარის ინვესტიცია განხორციელდა, რაც აჩვენებს, თუ რამდენად მომგებიანია კიბერდანაშაულის ინდუსტრია.
