Endor Labs’a göre, açık kaynaklı bağımlılıklar veya yazılım paketlerindeki potansiyel güvenlik açıklarına ilişkin üst düzey bir bakış açısı, bağımlılık risklerine yönelik düzeltme maliyetlerinin tehlikeli derecede yüksek olmasına rağmen, işlev düzeyinde erişilebilirlik analizinin bu kritik alanda hâlâ en iyi değeri sunduğunu ortaya koyuyor.
Araştırma, Endor Labs güvenlik açığı verilerinin analizine, karşılaştırma için Açık Kaynak Güvenlik Açıkları (OSV) veritabanına, müşteri kiracılarından gelen bilgilere ve en önemli 15 açık kaynak bağımlılığının yüzlerce sürümüne ait Java Arşivlerine (JAR) dayanıyor ve önemli değişiklikleri hesaplıyor.
“Birçok kuruluş bağımlılık risklerini yönetmekle mücadele ediyor. Birçoğu ilgili riski temsil etmeyen güvenlik açığı uyarıları arasında boğuluyorlar; uyarıları araştırmak güvenlik ekipleri (ve yazılım ekipleri) için pahalı ve her şeyi düzeltmeye çalışmak daha da pahalı. Araştırmalar, analiz tabanlı güvenlik açığı önceliklendirmesinin bu nedenle kritik bir yetenek haline geldiğini gösteriyor ve bağımlılık yönetimiyle ilgili diğer eğilimleri ve zorlukları vurguluyor,” diyor Endor Labs’da personel araştırma mühendisi olan Darren Meyer.
Önceliklendirme faktörü iyileştirme maliyetlerini azaltır
Açık kaynaklı bir kütüphanedeki bir güvenlik açığının istismar edilebilir olması için, en azından uygulamadan o kütüphanedeki güvenlik açığı olan işleve bir çağrı yolu olması gerekir. Rapor, bunun keşfedilen yedi dildeki tüm güvenlik açıklarının %9,5’inden daha azında doğru olduğunu bulmuştur: Java, Python, Rust, Go, C#, .NET, Kotlin ve Scala.
Bu nedenle, ihtiyaç duyulan iyileştirme faaliyetlerinin sayısını azaltmak iyileştirme maliyetlerini %90,5’in üzerinde azaltabilir. Belki de en iyisi, bunun yalnızca bu tek önceliklendirme faktörüyle yapılmasıdır, bu da onu her yerde mevcut olan en değerli tek gürültü azaltma stratejisi yapar.
Araştırma ayrıca ortaya çıkan risklere verilen yanıtın hızına da ışık tutuyor. Güvenlik açığı uyarılarının yaklaşık %70’inin ilgili güvenlik sürümünden sonra yayınlandığını ve ortalama 25 günlük bir gecikme olduğunu ortaya koyuyor. Bu, saldırganların güvenlik açığı olan sistemleri istismar etmesi için mevcut fırsat penceresini artırıyor.
Sorunlar daha da derin: İncelenen altı ekosistemde, kamuya açık güvenlik açığı veritabanlarındaki uyarıların %47’si hiçbir kod düzeyinde güvenlik açığı bilgisi içermiyor; %51’i, düzeltmeleri içeren bir veya daha fazla referans içeriyor; ve yalnızca %2’si etkilenen işlevler hakkında bilgi içeriyor.
Bu ciddi bir dezavantajdır çünkü program analiz tekniklerinin uygulanması, etkilenen işlevlerin adları veya bir açığı aşmak için açık kaynaklı proje bakıcıları tarafından geliştirilen düzeltme taahhütleri gibi güvenlik açıkları hakkında kod düzeyinde bilgi gerektirir. Bu tür bilgiler olmadan, bilinen güvenlik açığı olan işlevlerin bir alt akış uygulaması bağlamında yürütülüp yürütülemeyeceğini belirlemek etkili bir şekilde imkansızdır.
Bu ortamda, yalnızca üretim dışı kod için geçerli olan güvenlik açıklarını hariç tutmak gibi dikkat edilmesi gereken birkaç bağlam tabanlı strateji vardır. Ancak, bu yaklaşımların farklı kombinasyonları bile işlev düzeyindeki erişilebilirlik kadar önemli değildir.
Tedarik zinciri güvenliğindeki temel sorunlar
En kötü suçluları belirlemek: Önceliklendirme, kuruluşların toplam güvenlik açıklarının %5’inden azına odaklanmasını sağlar. Örneğin, Python ekosisteminde, en önemli 20 bileşeni güvenlik açığı olmayan sürümlere güncellemek, tüm güvenlik açığı bulgularının %75’inden fazlasını ortadan kaldırır. Diğer dillerdeki sonuçlar da neredeyse aynı derecede iyidir: Java %60 ve npm %44. TensorFlow bileşeni en fazla bildirilen güvenlik açığına sahiptir ve genellikle bildirim dosyaları olmadan yüklendiğinden, “hayalet bağımlılıkları” kapsamanın önemini vurgular.
Hayalet bağımlılıklar ve diğer sorunlu noktalar: Bu rapor için taranan seçilmiş müşteriler arasında, bağımlılıklar evrenindeki Python hayalet bağımlılıklarının payı %0 ila %60 arasında değişmektedir. Ancak en önemli bulgu şudur: Bu hayalet bağımlılıklardaki (toplamdaki) güvenlik açıklarının payı %85’e kadar çıkmaktadır. Bu bağlamda, ‘yeniden paketleme’ ekosistemler genelinde ciddi bir sorundur; binlerce Python ve Java bileşeni diğer açık kaynaklı projelerden ikili kodu yeniden paketler.
Bilinen güvenlik açığı olan kodu bulma: Uygulamalar ve güvenlik açıkları arasındaki bağlantıları belirlemek güvenliği güçlendirmenin merkezinde yer alırken, çok sayıda teknik zorluk, bunların bağımlılıkları içinde birbirine bağlanmasını zorlaştırır. Ancak, özellikle verilen güvenlik açıklarının kalitesi açısından bu tür bağımlılık tanımlamalarını kapsayan veritabanları oluşturmak, yanlış pozitif ve yanlış negatifleri önlemenin anahtarıdır.
Bilinen güvenlik açıklarının giderilmesi:2016’dan sonra en sorunlu 15 kütüphane tarafından yayınlanan, güvenlik açığı olan bileşen sürümlerinden güvenlik açığı olmayan bileşen sürümlerine yapılan 1250 güncellemenin %24’ü büyük sürüm güncellemesi gerektirirken, 1250 güncellemenin %6’sı küçük veya yama sürümünü güncelleyerek yapılabiliyor.
Genel çözümler açısından, Exploit Predictability Scoring System’ı (EPSS) bir önceliklendirme aracı olarak kullanmak güçlü bir ikinci derece etkinliktir. Bu seçenekle, ulaşılabilir güvenlik açıklarının %80’inin %1 veya daha az bir oranda istismar edilme olasılığı tahmin edilir.
Mutlaka okuyun: