Sektörümüzdeki pek çok kişi, yazılım malzeme listelerinin (SBOM’ler) yazılım kalitesi ve güvenliğine getirebileceği faydaları tartıyor. Yazılımdaki riski anlamak ve değerlendirmek için SBOM’lara ihtiyaç olduğunu düşünüyorum çünkü belirli bir yazılım sistemi için yazılım oluşturma sürecine görünürlük sağlamaları gerekir. Bir düzeyde, belirli ürünler ve yazılım sistemleri için SBOM’lar zaten mevcuttur; ancak, kalite ve güvenliği değerlendirmek için başvuruları, Yürütme Emri 14028, Ülkenin Siber Güvenliğini Geliştirme ve ABD Yönetim ve Bütçe Ofisi, Ulusal Standartlar ve Teknoloji Enstitüsü ve Siber Güvenlik Altyapısı ve Güvenlik Dairesi’nin yakın tarihli federal rehberliği oldukça yenidir ve ölçeğinde kanıtlanmamıştır.
Asla Geçmeyen Royce Bill
2013 civarında, SBOM mevzuatı HR5793 – Siber Tedarik Zinciri Yönetimi ve Şeffaflık Yasası (Royce Bill olarak bilinir) tanıtıldı, ancak bir yetki, yasa tasarısı veya gereklilik olarak geçmek için ihtiyaç duyduğu ivmeyi asla kazanamadı. O zamanlar endüstri, yazılım tedarik zinciri riskini yönetmek için şeffaflık iştahına sahip değildi.
Bu yasanın ele alacağı konular ana hatlarıyla belirtilmiştir. Kongre Kaydı – Açıklamaların Uzantıları. Modern yazılım geliştirmedeki aşırı karmaşıklık ve artan boyut ve açık kaynak yazılımlara yönelik artan saldırı oranları göz önüne alındığında, bu sorunlar şimdi daha da kötüleşti. Modern yazılım geliştirmede açık kaynaklı yazılımın artan tüketim oranıyla birlikte, tüketiciler, yazılım riskini daha iyi yönetmek için açık kaynaklı yazılım projelerinde zaman içinde biriken teknik borcun farkında olmalıdır. Daha fazla yazılım karmaşıklığı, daha büyük yazılım sistemleri ve artan teknik borç fikri, federal hükümetin yazılım tedarik zinciri aracılığıyla yazılım bütünlüğü ve güvenilirliği arzusu için pek iyiye işaret değil.
Royce Bill’in geçmemiş olması, o dönemde yazılım güvenliğinde artan tehditleri ve riski ele almak için kaçırılmış bir fırsat olarak görülebilir. Neredeyse on yıl sonra, endüstri hala SBOM’ları nasıl uygulayacağını ve onları rakiplerin sömüreceği bir hedef değil yararlı hale getirmek için doğru dengeyi nasıl kuracağını bulmakta zorlanıyor. Bu, endüstride önemli bir endişe yaratmaktadır. SBOM’lar prime time için hazır federal kılavuzda belirtilen mevcut gerekliliklere ilişkin şüphecilik göz önüne alındığında.
SBOM Bilinmeyen Risk Hakkında Bilgi Vermelidir
SBOM’ların karşılaştığı zorluklardan biri, ilerlemek ve riskli yazılımların nasıl belirlendiğini anlamaktır. “Riskli” terimini kullanıyorum çünkü tüm yazılımların güvenlik açıkları vardır ve SBOM, ister tek başına ister tek başına uygulanmış ve bir yazılım sistemine entegre edilmiş olsun, bir yazılım bileşeniyle ilişkili risk düzeyini ayırt edebilmeli veya bu düzeye ilişkin bağlam sunabilmelidir. . Tüm yazılımların güvenlik açıkları olabileceğinden, kendisiyle ilişkili CVE’lere (yaygın güvenlik açıkları ve riskler) sahip olduğu için bu yazılım bileşenini kullanamayacağınızı basitçe söylemek tartışmalı hale gelir. SBOM’lar, yazılımın uygulanacağı ve kullanılacağı bağlam – bileşen işlevi (günlüğe kaydetme, şifreleme, erişim kontrolü, yetkilendirme), ortam ve sertleştirilip katılaştırılamayacağı – göz önüne alındığında hangi CVE’lerin en tehlikeli ve istismara açık olduğunu kısa ve öz bir şekilde nitelendirebilmelidir. Belirli bir saldırı yüzeyini azaltmak. Yazılım bileşenlerinin bir sisteme entegre edilme şekli önemlidir, çünkü yazılım bileşenleri zayıf veya yanlış bir şekilde uygulanarak yazılım sistemlerindeki güvenlik açıklarını açığa çıkarabilir.
Açık kaynak yazılım tüketimi için bir güvenlik temeli oluşturmak üzere CVE’leri kullanmak mantıklıdır; ancak, hangi yazılımın daha az riskli veya daha riskli olduğunu belirlemek için bir grup CVE’yi saymak yalnızca “bilinen bilinenlere” odaklanır (aşağıdaki şekilde gösterildiği gibi) ve kuruluşların güvenlik açıklarını ve etkilerini ortaya çıkarabilecek hangi zayıflıkların gizlendiğini anlamalarına yardımcı olmak için çok az şey yapar. söz konusu yazılım bileşeninin genel hijyeni (belirli bir süre boyunca). Ayrıca, SBOM’lerle ilgili mevcut uygulama durumu, yazılım tedarik zincirlerini kusuru anlamaya teşvik etmemektedir. yazılımla ilişkili eğilim veya saldırı eğilimi oranları. Bu önemlidir, çünkü bazı yazılım bileşenleri yüksek oranda hedeflenmiştir ve yapısal teknik borç, düşük kod kalitesi ve güvenlik açıklarını ortaya çıkaran güvenlik sorunları nedeniyle önemli miktarda yama gerektirir. Daha fazla yama, geliştiricilerin ve mühendislik ekiplerinin müşterilere yeni özellikler ve işlevler oluşturmak ve sunmak için daha az zaman harcaması anlamına gelir.
Kusur eğilimi, bir yazılım ürünü piyasaya sürüldükten sonra bir yazılım bileşeninin kusurlu olma olasılığını ifade eder. Düşük kod kalitesi ve tasarım kusurları gibi kusur eğilimine katkıda bulunan çeşitli sosyo-teknik faktörler vardır. Saldırı eğilimi, yazılım bileşenlerinden başarıyla yararlanma oranını veya yazılım bileşenlerinin kötüye kullanılabilir zayıflıklar (hata, kusur veya kusur) veya güvenlik açıkları içerme olasılığını ifade eder.
SBOM çözümleri, kuruluşlara yukarıdaki şekilde gösterildiği gibi belirli bir yazılım bileşeni için potansiyel risk konusunda görünürlük sağlamalı ve kuruluşların hangi yazılım bileşenlerinin kullanılacağı ve hangi yazılım bileşenlerinden kaçınılacağı konusunda bilinçli kararlar almasına yardımcı olmalıdır. Örneğin, tavsiye içinde Ulusal Güvenlik Ajansı (NSA) Siber Güvenlik Bilgi Formu geliştiricileri, C ve C++’da geliştirilen yazılımları kullanmaktan kaçınmaya teşvik eder, çünkü bu programlama dilleri iyi bellek yönetimi kontrollerini zorlamayı amaçlamamıştır. Bu tavsiyenin, özellikle gömülü güvenlik açısından kritik sistemler için yazılım tedarik zincirini nasıl etkileyeceğini ve tedarikçilerin Rust ve Go gibi bellek açısından güvenli programlama dillerine dönüp dönmeyeceğini görmek ilginç olacak.
SBOM’a Rehberlik Etmek İçin Daha Derine Gidin
SBOM’lar ortadan kalkmıyor, bu nedenle yazılım güvenliğini iyileştirmek için hepimizin işbirliği yapması ve ortak çalışması zorunludur. Bu, SBOM’leri zenginleştirebilecek ve yazılım riski hakkında bilgi vermeye yardımcı olan yazılımın özellikleri hakkında daha derin analiz ve içgörü sağlayabilecek araçlar ve standartlar geliştirmeyi gerektirebilir. Bu, kuruluşların yazılım bütünlüğünü ve diğer yazılım güvencesi özelliklerini etkili bir şekilde değerlendirmesine ve doğrulamasına yardımcı olacaktır. Son olarak, yazılım tedarik zincirlerinin yalnızca belirli bir yazılım bileşeniyle ilişkili riski değil, aynı zamanda yazılımdaki güvenlik açıklarını zamanında düzeltmeye yönelik endüstrideki zorluklar göz önüne alındığında, bu yazılım bileşeninin belirli bir süre boyunca kullanılmasıyla ilişkili potansiyel bakımı da anlaması önemlidir. . Kusur ve saldırı eğilimi oranlarının kullanılması, kötü hijyene sahip riskli yazılımların tüketimini azaltmaya yardımcı olan eyleme geçirilebilir istihbarat sağlayabilir. ve siber saldırılara karşı daha dayanıklı yazılım sistemleri oluşturmada yazılım tedarik zincircilerine rehberlik edin.
Teorik olarak, daha iyi hijyene sahip alternatiflerin kullanımını teşvik etmek ve teşvik etmek için yüksek hata ve saldırı eğilimi oranlarına sahip yazılım bileşenlerinden kaçınılmalıdır. Kanımca, SBOM’lar kod kalitesini ve güvenliğini doğrudan iyileştirmezler, ancak yazılım tedarik zinciri çalışanlarını yazılım oluşturma süreçlerinde risk konusunda daha bilinçli hale getirebilirler. Açık kaynaklı yazılımlar için kod kalitesini ve güvenliğini artırmak, bir kültür değişikliği gerektirir. çok göze sahip olmak tüm böcekleri sığ yapmaz.