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

განახლების პარადოქსი

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

რატომ ვართ დაუცველები?

  • ბრმა ნდობა: ჩვენ ვენდობით პაკეტებს, რომელთა შიგთავსი არც კი წაგვიკითხავს.
  • გადატვირთული დეველოპერები: open-source პროექტების მენეჯერებს ხშირად არ აქვთ რესურსი უსაფრთხოების სათანადო კონტროლისთვის.
  • კორპორატიული წნეხი: სწრაფი განვითარების ტემპი ხშირად უსაფრთხოების აუდიტს მეორეხარისხოვანს ხდის.

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

რა გამოსავალი არსებობს?

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

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