Yazılım malzeme listeleri 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 hem doğrudan hem de dolaylı olarak kullanılan bileşenleri ve bağımlılıkları özetleyen yazılım manifestoları artık ABD hükümeti tarafından tüm federal yüklenicilerden isteniyor. Üretim için düşük çıta göz önüne alındığında A Syazılım malzeme listesi (SBOM) — geliştirme sırasında kullanılan artan çeşitlilikteki araçlar da bir tane üretebilir — uygulama bileşenlerinin listeleri çoğalıyor. Sonuç olarak, tüm şirketlerin neredeyse yarısı artık herhangi bir yazılım için SBOM’lara da ihtiyaç duyuyor. 2022’de %5’in altında olan bu sayının 2025’te %60’a ulaşması bekleniyor. Pazar araştırma şirketi Gartner’dan veriler.
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) duyuruldu. SBOM standardı CycloneDX’in 1.5 sürümüArtık belirli bir uygulamada kullanılan makine öğrenimi (ML) modelleri hakkında bilgilerin yanı sıra SBOM’nin kalitesinin bir ölçüsünü de içeriyor.
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ı
Birleşik Devletler hükümet üç SBOM standardını tanır minimum gereksinimlerini karşılıyor olarak: 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 kurulu yazılımları izlemelerinin bir yolu olarak SWID etiketlerini 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 SPDX’i yarattı. 2017’de 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. Aralarında nüanslar da 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’lerin 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 devralacağınız bağımlılıkları daha kolay izlemek için SBOM’ları kullanabilirsiniz. Bu, güvenlik konusunda daha iyi kararlar vermenize 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.”
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, bilinçli risk yönetimi kararları verebilmek için yazılımlarını ve envanterlerini anlamak istiyor ve bunu SCA ile oldukça iyi bir şekilde yapabiliyorlar. [software composition analysis] oluşturdukları yazılım için” diyor. “Ama tedarik ettikleri yazılım için bu görünürlükten yoksunlar. Dolayısıyla SBOM’lar, eksiksiz bir yazılım envanterine sahip olmanız için birinci ve üçüncü taraf uygulamalarınıza ilişkin görünürlük elde etmekle 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ıtlarını otomatik hale getirecektir. 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.”