Yazılım malzeme listeleri veya SBOM’lar bir an yaşıyor.
Biden yönetimi tarafından Mayıs 2021’de yayınlanan bir yürütme emrinin ardından, uygulamaları geliştirmek için kullanılan hem doğrudan ithal edilen hem de dolaylı olarak güvenilen bileşenleri ve bağımlılıkları özetleyen yazılım bildirimleri artık ABD hükümeti tarafından tüm federal yüklenicilerden isteniyor. Geliştirme sırasında kullanılan artan çeşitlilikteki araçlar da bir SBOM üretebileceğinden, bunları üretmenin düşük çıtası göz önüne alındığında, uygulama bileşenlerinin listeleri çoğalıyor. Sonuç olarak, pazar araştırma şirketi Gartner’ın verilerine göre, tüm şirketlerin neredeyse yarısı artık herhangi bir yazılım için SBOM’lara ihtiyaç duyuyor; bu sayının 2025’te %60’a ulaşması ve 2022’de %5’in altına çıkması bekleniyor.
Bir yazılım geliştirme araçları firması olan Sonatype’ın ürün inovasyonundan sorumlu başkan yardımcısı Stephen Magill, federal zorunlulukların SBOM’lara akın etmesine ve geliştiricilerin yazılımlarını belgeleme yöntemlerinde değişikliklere yol açtığını söylüyor.
“Hükümetten ve düzenleyicilerden gelen SBOM yetkileri, geliştirme sürecinizi bir üst seviyeye taşımak ve bir aracı devreye sokmak için önemli bir teşvik sağlıyor” diyor. “Bu düzenlemelerin getirilmesinin büyük bir kısmı bu. Bunun nedeni, endüstrinin bu araçları evrensel olarak benimsememiş olması ve açık kaynağın, birçok kuruluşta yönetilmeyen büyük bir risk alanı olmaya devam etmesidir.”
Standartlar, yazılım geliştirmeye giden çeşitli bileşenleri hesaba katmaya çalıştıkça, hükümetin talimatlarına ayak uydurma telaşı sektörde hızlı bir evrime yol açıyor. Örneğin, Haziran ayında, Açık Dünya Çapında Uygulama Güvenliği Projesi (OWASP), artık belirli bir uygulamada kullanılan makine öğrenimi (ML) modelleri hakkında bilgilerin yanı sıra bir ölçüm de içeren SBOM standardı CycloneDX’in 1.5 sürümünü duyurdu. SBOM’un kalitesi.
Genişletilmiş IoT güvenlik şirketi NetRise’ın CEO’su Thomas Pace, mevcut SBOM’lar genellikle yazılım bileşenleri listelerinden biraz daha fazlası olsa da, nihai hedefin kuruluşlara yazılımlarındaki zayıflıkları belirlemeleri ve belgelemeleri için bir yol vermek olduğunu söylüyor.
“Şu anda, son kullanıcılar, özellikle de … kuruluşların ezici çoğunluğu için hala bir kara kutu olan üretici yazılımı çalıştıran cihazlarla ilgili olarak, eksik verilere dayalı olarak karar verme sorunu yaşıyor” diyor. “Bu SBOM’lara sahip olduklarında, sonunda kullandıkları çeşitli cihazların, uygulamaların ve sistemlerin riskleri hakkında veriye dayalı kararlar alabilirler.”
SPDX, CycloneDX ve SWID Standartları
ABD hükümeti, üç SBOM standardının minimum gereksinimlerini karşıladığını kabul etmektedir: Yazılım Tanımlama (SWID) etiketleri, Yazılım Paketi Veri Alışverişi (SPDX) ve CycloneDX.
2009 yılında, Uluslararası Standartlar Organizasyonu (ISO), kuruluşların yönetilen sistemlerinde yüklü yazılımları izlemelerinin bir yolu olarak Yazılım Tanımlama (SWID) etiketleri oluşturdu. On yılı aşkın bir süre önce Linux Vakfı, lisanslama hakkında bilgi alışverişine yardımcı olmak için yazılım paketi veri alışverişini veya SPDX’i yarattı. 2017’de Açık Web Uygulaması Güvenlik Projesi (OWASP), SBOM’larda veri alışverişi yapmanın bir yolu olarak CycloneDX’i yarattı.
Üç standart önemli ölçüde örtüşüyor, ancak SPDX ve CycloneDX en fazla ivmeye sahip gibi görünüyor ve aralarında nüanslar var – SPDX hala lisans yönetimine ve makine tarafından okunabilirliği destekleme derecesine daha fazla odaklanıyor. Bununla birlikte, Dark Reading’in bir kardeşi olan analist firması Omdia’da siber güvenlik kıdemli baş analisti Fernando Montenegro, uygulamada SBOM’un hem tüketicilerinin hem de sağlayıcılarının formatlarla çalışabilmesi gerektiğini söylüyor.
“Bir geliştiriciyseniz, farklı modüller eklerken kendi yazılımınızda miras alacağınız bağımlılıkları daha kolay izlemek için SBOM’ları kullanabilirsiniz – bu, güvenlik konusunda daha iyi kararlar almanıza yardımcı olacaktır” diyor. “Bir güvenlik ekibiyseniz, satıcılarınız tarafından sağlanan bu SBOM’lar, ortamınızda hangi bileşenlerin çalıştığını anlamanıza yardımcı olabilir … sistemlerinizde düzeltme eylemlerine daha kolay öncelik verebilirsiniz.”
Sadece Farkındalığın Ötesine Geçmek
Görünürlük ve farkındalık, şu anda SBOM’ların birincil faydalarıdır. Örneğin, CycloneDX SBOM’ları, geliştirmede kullanılan yazılım lisansları, düşük kodlu hizmetler ve makine öğrenimi modelleri ile güvenlik açığı ifşası ve ek açıklamalar hakkında bilgiler içerir. Endor’un ürün müdürü Jamie Scott, güvenlik açıklarının %95’inin yazılım oluşturmak için kullanılan doğrudan bağımlılıklarda değil, bu bileşenlerin geliştiricileri tarafından dahil edilen dolaylı bağımlılıklarda olduğu için, çoğu şirketin tedarik edilen yazılım riskine ilişkin iyi bir görüşe sahip olmadığını söylüyor. Labs, bir yazılım risk yönetimi firması.
“İnsanlar yazılımlarını ve envanterlerini anlamak istiyor, böylece bilinçli risk yönetimi kararları verebiliyorlar ve bunu oluşturdukları yazılım için SCA (yazılım bileşimi analizi) ile oldukça iyi bir şekilde yapabiliyorlar” diyor. “Ancak tedarik ettikleri yazılım için bu görünürlükten yoksunlar. Dolayısıyla SBOM’lar, tam bir yazılım envanterine sahip olmanız için birinci ve üçüncü taraf uygulamalarınıza görünürlük kazandırmakla ilgilidir.”
Bir yazılım pazarı hizmetleri firması olan Capterra’da kıdemli güvenlik analisti olan Zach Capers, yine de SBOM’ların giderek daha fazla işlevsel hale geleceğini söylüyor. Şirketin anketleri, şirketlerin yaklaşık yarısının (%49) mevcut yazılım satın alma süreçlerinin bir parçası olarak SBOM’lara ihtiyaç duyduğunu ortaya çıkardı.
“Yazılım alıcılarının yazılım tedarik zincirleri boyunca görünürlüğü artırmak için SBOM’lardan yararlanabilmesi gibi, yazılım geliştiriciler de ürünlerini geliştirmek için kullanılan bileşenleri daha iyi izleyebilir” diyor. “Hala erken aşamalardayız, ancak sonunda, yeni keşfedilen bir güvenlik açığı hakkında bilgi edinecek ve SBOM’lar sayesinde şirketinizin yazılım yığınında bir yerde gizlenip gizlenmediğini anında belirleyebileceksiniz.”
Mevcut değişiklikler daha çok SBOM’ler kullanılarak belgelenenlerin kapsamını genişletmekle ilgilidir, ancak sonunda çeşitli risk önlemleri – ve potansiyel güvenlik kontrolleri – SBOM’lara kilitlenebilir ve muhtemelen bir yazılım sorumluluğu rejimine yol açar.
Makine Öğrenimi, Otomasyon Odak Noktası
Saldırganlar, Log4Shell kavram kanıtını kullanarak Log4j güvenlik açıklarından yararlanmaya başladığında, şirketler, yaygın açık kaynak bileşeninin kendi ortamlarında olup olmadığını belirlemek için uğraştı.
Bir güvenlik testi firması olan ForAllSecure’da geliştirici savunuculuğu başkanı Josh Thorngren, güvenlik uzmanları “Log4Shell’i tekrar düşündüklerinde, birçok kuruluş için zorluğun bir kısmı Log4j kullanıp kullanmadıklarını ve savunmasız olup olmadıklarını yanıtlamaktı” diyor. “SBOM’lara sahip kuruluşlar, bu soruyu olmayanlara göre daha hızlı cevaplayabilecekler, [and] zamanla bu farklılığı görmeye ve vahşi doğada güvenlik uygulayıcılarından bu tepkileri duymaya başlayacağız.”
Ek olarak, yazılım sistemleri muhtemelen bilinen güvenlik açıklarına yanıt vermeyi otomatikleştirecektir. NetRise’dan Pace, şirketlerin ürünlerindeki güvenlik açıklarını, özellikle dolaylı bağımlılıklardan kaynaklananları anlayacak ve – yeni bir güvenlik açığı duyurulduktan sonra – kontrolleri uygulayabileceklerini söylüyor.
Pace, “Artık, temelde tüm güvenlik duvarlarının ve izinsiz giriş algılama sistemlerinin bugün yapabildiği mevcut istismarlar etrafında o cihazı hedefleyen trafiği algılayan bir telafi edici kontrol uygulayabilirsiniz” diyor. “SBOM olmadan, bu risklere karşı tamamen körsünüz ve sadece cihaz üreticilerinin tamamen güvenli bir cihaz geliştirdiklerini umuyorsunuz ki bu elbette imkansız.”