YORUM
SBOM geliyor ve geri dönüş yok. Başlangıçta Ulusal Telekomünikasyon ve Bilgi İdaresi (NTIA) tarafından oluşturulan yazılım malzeme listesi (SBOM), göz açıp kapayıncaya kadar niş olmaktan zorunlu hale geldi. Federal ajanslar ve güvenlik ekipleri artık denetim ve onay süreçlerinin bir parçası olarak üçüncü taraf satıcılardan SBOM talep ediyor. Giderek daha fazla işletme, yazılım hizmeti olarak (SaaS) sağlayıcılar için bile dahil edilen tüm bileşenler için güvenlik kontrol listelerine SBOM oluşturmayı ekliyor. Bu mantıklı. Log4j ve xz gibi kötü tedarik zinciri saldırılarının artışı, SBOM’ların gerekliliğini vurguluyor.
Ancak bugüne kadar SBOM, çok çeşitli araçlarda rekabet eden standartlar ve çeşitli uygulama yöntemleri nedeniyle vaadini yerine getirmede büyük ölçüde başarısız oldu. Bu sorunlar, şeffaflığın altın standardı olması amaçlanan şeyi ETL ve veri şeması yönetiminde kafa karıştırıcı bir uygulamaya dönüştürdü. Bu iyi değil. SBOM’lar siber güvenliğin geleceği açısından kritik öneme sahiptirTeknoloji dünyası SBOM’un kritik önemini kabul etmeli ve birleşik, kapsamlı bir format benimsemelidir. Bunu nasıl başarabileceğimizi burada bulabilirsiniz.
Birleşik Bir SBOM Standardı İçin Bir Durum
SBOM kavramı, 2000’lerin başında üretim endüstrisinden esinlenerek yazılım için bir “parça kataloğu” olarak ortaya çıktı. Vizyon, yalnızca bir listeden öteye geçerek yazılım bileşenlerinin, sürümlerinin ve güvenlik durumlarının otomatik olarak doğrulanması için programlı bir mekanizmayı içeriyordu. Bu sistem, typosquatting saldırıları gibi sorunlargeliştiricilerin yanlışlıkla kötü amaçlı paketleri indirdiği ve saldırganların güvenilir depolara erişip ince değişiklikler yaptığı xz olayı gibi daha karmaşık saldırılar. Bir SBOM, açığa çıkmayı hızla tespit edip izleyebilir, bu da kritik bir yetenektir. Log4j saldırısıEkiplerin sistemlerindeki güvenlik açığı bulunan kütüphaneyi bulmakta zorlandığı bir durum yaşandı.
Geçtiğimiz on yılın eğilimleri SBOM’ları daha acil hale getirdi. Yazılım geliştirme, tek parça tescilli kod tabanlarından kütüphaneler ve modüller de dahil olmak üzere açık kaynaklara yoğun bir şekilde bağımlı olmaya doğru kaydı. Yazılım yığınının her katmanı artık belirgin bir şekilde açık kaynaklı bileşenler içeriyor. Mikro hizmetler ve “sola kaydırma” hareketi, yazılım tedarik zincirine daha fazla bileşen ekleyerek uygulamaları daha küçük parçalara böldü ve ekiplerin bileşenlerini seçmelerine olanak tanıdı. Sonuç olarak, modern uygulamaların önemli bir kısmı, güvenilirliği ve itibarı değişebilen üçüncü taraflar tarafından oluşturuluyor ve kontrol ediliyor.
Rekabet Eden Standartları Uzlaştırmak Maliyetli ve Zaman Alıcıdır
Etkili endüstri grupları tarafından desteklenen iki büyük SBOM standardı ortaya çıktı. 2010 yılında Linux Foundation tarafından tanıtılan SPDX (Yazılım Paketi Veri Değişimi), bileşenler, lisanslar, telif hakları ve güvenlik referansları dahil olmak üzere ayrıntılı SBOM bilgilerini iletir. 2017 yılında OWASP tarafından geliştirilen CycloneDX, mevcut geliştirme araçlarına ve süreçlerine kolayca entegre edilmek üzere tasarlanmış başka bir SBOM standardıdır. Teoride, bu standartlar uyumludur ve aynı kurumsal güvenlik yığınında bir arada bulunabilir. Pratikte, bu nadiren böyledir.
Kuruluşlar, farklı yapıları, odak alanları ve ayrıntı düzeyleri nedeniyle SPDX ve CycloneDX biçimleri arasında veri birleştirme veya alışverişi yaparken sıklıkla önemli zorluklarla karşılaşırlar. Açık kaynak lisans uyumluluğuna dayanan SPDX, dosya düzeyindeki ayrıntılara ve kod parçacıklarına kadar kapsamlı bileşen verileri sağlar. Buna karşılık, güvenlik topluluğundan kaynaklanan CycloneDX, dijital imzalar ve güvenlik açığı istismar verileri gibi sağlam öğeler içeren güvenlik açığı tanımlama ve analizi için optimize edilmiştir. Alanları eşlemek ve bu biçimler arasında bilgileri çevirmek, özellikle büyük ve karmaşık SBOM’ler için karmaşık olabilir. Veri şemalarını değiştirmek, entegrasyon çabalarını aksatabilir veya uyumluluk platformları, SIEM veya SOAR sistemleri gibi alt akış araçlarını karıştırabilir.
Ek olarak, araç sınırlamaları, biçim sürümlemesi, bilgi tutarsızlıklarının derinliği ve belirli biçimler için organizasyonel tercihler birlikte çalışabilirlik çabalarını daha da karmaşık hale getirir. NTIA sürümü SBOM standartları arasında tutarlılığı desteklese de, SPDX ve CycloneDX arasındaki içsel farklılıkların uzlaştırılması zor olmaya devam ediyor. SBOM gereksinimlerinin minimalist yapısı, yorumlama için bolca alan bırakarak, aynı yazılım bileşenlerini izleseler bile sektörler arasında farklı uygulamalara neden olur.
Standartlar Kurumu Oluşturun ve Terazinin Dengesini Sağlayın
5G’den HTML’e ve kapsayıcılara kadar tek standartlar, temel yetenekler için uyumluluk ve uygunluğu garanti eder. SBOM’lar için bunu başarmanın ilk adımı, bunların kritik önemini kabul etmektir. Sonra, standartları birleştirmek için tek bir endüstri veya iş birliği yapan kuruluş belirlenmelidir. Bu süreç, söz konusu çeşitli çıkarlar nedeniyle muhtemelen yavaş ve karmaşık olacaktır. İyi bir benzetme, World Wide Web Konsorsiyumu’nun (W3C) Web standartları etrafındaki devam eden çalışmasıdır. Başlangıçta, bu çaba, büyük SBOM’ların rekabet eden kökenlerini daha net bir vizyon ve bir SBOM’un neyi başarması gerektiğine dair belirgin bir beyanla uzlaştırmalıdır.
Geniş endüstri katılımı hayati önem taşır, ancak büyük yerleşiklerin dahil olması esastır. Bulut hiper ölçekleyicileri, büyük siber güvenlik firmaları ve geliştirici araç devleri (GitHub, GitLab, Atlassian, Microsoft ve Google gibi) katılmalıdır, çünkü geliştiriciler, güvenlik operasyonları, DevOps ve platform ekipleri herhangi bir birleşik SBOM formatının birincil tüketicileri ve kullanıcılarıdır. Nihai test, yeni SBOM formatının mevcut SBOM’lara kıyasla zahmeti azaltıp azaltmadığı ve güvenliği ve şeffaflığı artırıp artırmadığıdır. Yeni bir birleşik standardı teşvik eden SOC2 veya ISO gibi ağ etkileri ve uyumluluk standartları, benimsenmeyi güçlü bir şekilde etkileyecek ve potansiyel olarak terazinin kefelerini birleşik bir yaklaşıma doğru eğecektir.
SBOM’lerin yazılım tedarik zinciri güvenliğini geliştirmedeki tam potansiyelini gerçekleştirmek için birleşik bir SBOM standardı esastır. Tek bir standarda odaklanarak, araç üreticileri ve geliştirme ekipleri önemli ölçüde emek ve kaynak tasarrufu sağlayabilir. Birden fazla standardın ve parçalanmanın getirdiği zorlukların üstesinden gelmek, netlik, tutarlılık, birlikte çalışabilirlik ve nihayetinde daha güvenli bir yazılım ekosistemini teşvik edecektir.