Yeni bir yıl ve siber güvenlik topluluğu şimdi başka bir yazılım tedarik zinciri güvenlik kabusunun uzun vadeli sonuçlarıyla karşı karşıya. Uygulama güvenliği sıfırıncı gün serpintisiyle dolu bir yılın ardından, Log4j güvenlik açığı çöküşü (Log4Shell olarak da anılır), yılı SolarWinds’in başlattığı şekilde kapatan 2021 için tematik bir kitap ayracı gibiydi.
Bu olayların gerçek dünyadaki sonuçları, kurumsal BT ekiplerini sayılamayacak kadar çok şekilde eğitti. Ancak belki de en önemli ders, birçok kuruluşun yazılım portföylerinde kaputun altında hangi kodun çalıştığını gerçekten anlamak ve yönetmek için ne kadar iş yapması gerektiğidir. Önceki SolarWinds olayı gibi, Log4j fiyaskosu da kurumsal yazılımlarda kaç tane gizli yazılım bağımlılığı bulunduğunu ve bu bağımlılıklar yeterince anlaşılmadığında altta yatan kritik kusurları ortadan kaldırmanın ne kadar zor olduğunu vurguladı.
Bunun büyük bir kısmı, mikro hizmetler ve yazılımın bileşenleştirilmesi dahil olmak üzere modern geliştirme tekniklerinin doğal ilerlemesinden gelir; bu sayede günümüz yazılımlarının çoğu, önceden hazırlanmış açık kaynak ve üçüncü taraf kodlarından oluşur. Yazılım mühendisleri, geliştirdikleri her uygulama için yeni bir kod gövdesi oluşturarak tekerleği yeniden icat etmek yerine, uygulamaları çalıştıran kod tabanının büyük bir kısmını oluşturmak için temel olarak mevcut kitaplıkları ve ortak işlevler için paketleri karıştırıp eşleştirir.
Göre “2021 Sonatype Yazılım Tedarik Zincirinin Durumu Raporu“Geçen yıl dünyanın dört bir yanındaki geliştiriciler, işlerinde kullanmak üzere çevrimiçi depolardan 2,2 trilyondan fazla açık kaynak paketi çekti ve bu, açık kaynak bileşenlerinin geliştirici indirmelerinde yıldan yıla %73’lük bir büyümeyi temsil ediyor.
Bu yaklaşım, geliştirme çalışmasını daha hızlı ve daha öngörülebilir hale getirir, ancak Log4j gibi temel bileşenlerin savunmasız olduğu tespit edildiğinde basamaklı bir risk etkisi de yaratır. En büyük sorunlardan biri, birçok prefabrik kitaplığın ve açık kaynak projesinin birbirine bağımlı olması ve birkaç katman derinliğe inebilen bir bağımlılıklar zinciri oluşturmasıdır. Bu, Apache’ninki gibi bir açık kaynak ekosistemindeki çeşitli oyuncular arasında çok fazla koordinasyon olmadan kurumsal savunucuların ele alması zor olabilecek dolaylı bağımlılıkların olduğu bir durum yaratır.
Google’ın Açık Kaynak Öngörüleri Ekibi tarafından yapılan en son araştırmalara göre, Apache Log4j kitaplığındaki güvenlik açığından etkilenen Java paketlerinin %80’i doğrudan güncellenemiyor ve açığı gidermek için farklı proje ekipleri arasında koordinasyon gerektirecek. Bu, uygulama güvenliği ve geliştirme profesyonellerinin bu yaygın yazılım zayıflığından kaynaklanan riski ortadan kaldırmak için yıllarca süren çalışmaları anlamına geliyor.
Bu güvenlik ve yazılım uzmanları Log4j’nin kriz modundan çıkıp 2022 için önceliklerini belirlemeye başlarken, güvenlik uzmanları geçen yılın olaylarının yazılım malzeme faturalarını (SBoM’ler) izlemek için daha yaygın bir baskıya ve bağımlılıkta daha fazla disipline yol açabileceğini umuyor. yönetmek.
ReversingLabs’in baş yazılım mimarı Tomislav Pericin, SBoM’lerin yazılım için bir içerik listesi gibidir, kullanılan bileşenleri ve uygulamalardaki bağımlılıkları tanımlamak için resmileştirilmiş bir yöntem sağlar, diye açıklıyor.
Pericin, “SBoM, yazılım paketlerindeki bağımlılıkları bilmenin temel yoludur” diyor.
“Anahtar değer, bir yazılım envanteri oluşturma yeteneğidir, böylece bir saldırı veya güvenlik açığı meydana geldiğinde ‘Nerede bulunuyor?’, ‘Nereden güncelleme alabilirim?’ diye sorabileceğiniz bir yeriniz olur. [and] ‘Neyi çevrimdışına almam gerekiyor?’ Elbette şeytan ayrıntıda gizlidir. Birçok SBoM hala manuel olarak oluşturulmakta ve yönetilmektedir. Yazılım değişikliklerinin sıklığı ve uygulamaların miktarı göz önüne alındığında, bireylerin SBoM’leri güncel tutması ve güncel tutması zor olabilir.”
Ancak, SBoM oluşturma ve standardizasyonun olgunlaşması devam etmektedir. Geçen yıl, Biden yönetimi, diline dili de dahil etti. icra emri federal kurumlara satış yapan yazılım geliştiricilerinin yazılımları için bir SBoM sağlamalarını zorunlu kılmak için siber güvenlik konusunda ve kısa süre sonra Ulusal Telekomünikasyon ve Bilgi İdaresi, minimum elemanlar bir SBoM’un. Bu arada, Linux Vakfı gibi endüstri grupları şu anda SBoM uygulamalarını küresel olarak daha iyi anlamak için çalışmalar yürütüyor. Sonuç olarak, uygulama güvenliği uzmanları ve siber güvenlik liderlerinin, günümüzün yazılım geliştirme ortamlarında riski yönetmek için SBoM izlemelerini geliştirmenin bir yolunu bulması gerekiyor.
Invicti’s Acunetix’in mühendislik başkanı Nicholas Sciberras, “Modern uygulamalarda açık kaynak ve diğer üçüncü taraf bileşenlerinin yaygın kullanımı göz önüne alındığında,” diyor ve “SBoM’ler siber dayanıklılığın temel bir unsurudur.”