მესამე მხარის რისკების მართვის პროგრამული უზრუნველყოფა დეველოპერებისთვის

2. რატომ ვერ ხედავს მესამე მხარის რისკების მართვის პროგრამულ უზრუნველყოფას თქვენი კოდის შინაარსი

ტრადიციულად, მესამე მხარის რისკი მომწოდებლის რისკს ნიშნავდა. თქვენ გაგზავნიდით კითხვარს, ამოწმებდით სერტიფიკატებს, შესაძლოა ატარებდით სწრაფ აუდიტს და შემდეგ გადადიოდით. ​​თუმცა, პროგრამული უზრუნველყოფა ამ გზით აღარ მუშაობს.

დღეს თქვენი კოდის ბაზა პაკეტებს იღებს npm, PyPI, Maven, დოკერის ცენტრიდა სხვა. ესენი არ არიან მომწოდებლები, რომლებთანაც ხელშეკრულებას აფორმებთ, ისინი არიან კონტრიბუტორები, რომლებსაც არ იცნობთ. ზოგიერთი მათგანი კრიტიკულ დამოკიდებულებებს ინარჩუნებს, ზოგი კი წლების განმავლობაში არ განაახლებს კოდს. ზოგჯერ კი, ვინმე სასარგებლო მოდულის სახით შენიღბულ მავნე პროგრამას ატვირთავს.

შედეგად, ეს „უხილავი მომწოდებლები“ ​​წარმოადგენენ მზარდ თავდასხმის ზედაპირს. მათ შეუძლიათ შემოიტანონ:

• კრიტიკული დაუცველობა
• შეუთავსებელი ან სარისკო ლიცენზიები (GPL, AGPL, SSPL…)
• მიტოვებული პაკეტები მომავალი განახლებების გარეშე
• ტროიანიზებული დამოკიდებულებები ან დაბნეული დატვირთვები

შესაბამისად, მხოლოდ ტრადიციული მესამე მხარის რისკების მართვის პროგრამულ უზრუნველყოფაზე დაყრდნობა არ დაგიცავთ თქვენს შიგნით უკვე არსებული საფრთხეებისგან. pipelineთუ თქვენი მესამე მხარის რისკების სტრატეგია არ მოიცავს კომპონენტის დონის სკანირებას, თქვენ ბრმა წერტილს ღიად ტოვებთ.

უფრო მეტიც, შესაბამისობის ჩარჩოები DORA-სა და NIS2-ის მსგავსად, ახლა თქვენგან მესამე მხარის კოდის მართვას ისევე მოელიან, როგორც მესამე მხარის სერვისებს მართავთ. ეს მოიცავს ლიცენზიების მართვას, პროგრამული უზრუნველყოფის წარმომავლობას და აქტიური დაუცველობის შემცირებას.

რა მნიშვნელობა აქვს მესამე მხარის რისკების მართვის პლატფორმის შესაძლებლობებს სინამდვილეში

თუ თქვენი მესამე მხარის რისკების მართვის ინსტრუმენტი მხოლოდ მომწოდებლებს აკონტროლებს, ის რეალურ პრობლემას ვერ ამჩნევს. დეველოპერები ახლა უფრო მეტ შეუმოწმებელ კოდს იმპორტს ახდენენ, ვიდრე ოდესმე, პაკეტებიდან, კონტეინერებიდან, სკრიპტებიდან და CI/CD დანამატები. ამიტომ, თქვენს მიერ მოწოდებული პროგრამული უზრუნველყოფა ხშირად შეიცავს ასობით მესამე მხარის ელემენტს, რომლებიც თქვენ არ შეგიქმნიათ, არ გადაგიხედავთ ან არ გადაგიმოწმებიათ.

ამ რისკის სათანადოდ სამართავად, თანამედროვე მესამე მხარის რისკების მართვის პროგრამული უზრუნველყოფა უნდა აკმაყოფილებდეს ახალ მოთხოვნებს. standard და, ის უნდა მუშაობდეს იმ დონეზე, სადაც რეალური რისკებია: თქვენს კოდის ბაზაში და pipelines.

კერძოდ, აი, რას უნდა გულისხმობდეს სწორი გადაწყვეტა:

SBOMდა ხილვადობა მესამე მხარის რისკების მართვის პლატფორმაზე

თქვენ არ შეგიძლიათ დაიცვათ ის, რისი დანახვაც შეუძლებელია. თქვენმა პლატფორმამ უნდა ამოიცნოს ყველა მესამე მხარის კომპონენტი, მათ შორის გარდამავალი დამოკიდებულებები და სისტემის დონის პაკეტები. სრული და მუდმივად განახლებადი პროგრამული უზრუნველყოფის მასალების ჩამონათვალი (SBOM) ეს აღარ არის არჩევითი, ის სავალდებულოა ისეთი ჩარჩოებით, როგორიცაა DORA, NIS2 და აღმასრულებელი ბრძანება 14028.

ლიცენზიის რისკის აღმოჩენა და მართვა

ლიცენზიის დარღვევამ შეიძლება გამოიწვიოს სასამართლო პროცესები ან აიძულოთ თქვენი მთელი სტეკი ღია კოდით გამოიყენოთ. თქვენი ინსტრუმენტები უნდა მაღალი რისკის ლიცენზიების აღმოჩენა (მაგალითად, AGPL ან SSPL), განახორციელონ მორგებული პოლიტიკა და აღმოაჩინონ უცნობი ან კონფლიქტური ლიცენზიების ტიპები, სანამ ისინი წარმოებაში მოხვდებიან.

ტექნიკური მომსახურებისა და მოძველების შეტყობინებები

მოძველებული ბიბლიოთეკები ხშირად დაუცველია, არ არის განახლების სისტემა და არ არის მოვლილი. თქვენმა პლატფორმამ უნდა გაგაფრთხილოთ, როდესაც კომპონენტი წლების განმავლობაში არ განახლებულა ან როდესაც მისი შემნახველი გაქრა. ეს ხელს უშლის ტექნიკური ვალის უსაფრთხოების ვალად გადაქცევას.

რეალურ დროში მავნე პროგრამებისა და მიწოდების ჯაჭვის საფრთხის აღმოჩენა

მავნე პაკეტები აუდიტის შეფასებებს არ ელოდებიან. ისინი შექმნილია ისე, რომ ჩუმად შეერწყას და გააქტიურდეს. სწორედ ამიტომ, თქვენი რისკების მართვის პლატფორმა უნდა მოიცავდეს რეალურ დროში სკანირებას ტროასების, უკანა კარების, typosquatting-ის და საეჭვო სკრიპტების აღმოსაჩენად, სანამ ისინი თქვენს გარემოში მოხვდებიან.

ჩაშენებული ხელმისაწვდომობა და პრიორიტეტების მინიჭება

დეველოპერებისთვის 500 გამოუყენებელი დაუცველობით გადატვირთვა უსაფრთხოებას არ აუმჯობესებს. პირიქით, ეს ხმაურს ქმნის, აჭიანურებს მოქმედებას და დროს კარგავს. ამიტომ, სასარგებლო პლატფორმა უფრო შორს უნდა წავიდეს. მან უნდა აჩვენოს, რა არის რეალურად ხელმისაწვდომი და გამოსაყენებელი თქვენს აპლიკაციაში. გარდა ამისა, მან უნდა დააპრიორიტეტოს საკითხები ბიზნესზე ზემოქმედების საფუძველზე და შეამციროს შეტყობინებების დაღლილობა რეალური რისკების დამალვის გარეშე.