Yazılım, 2023’te her işletmenin önemli bir parçasıdır. İster geliştiriyor ister dağıtıyor olun, yazılım tedarik zincirinizdeki zayıf halkalar hakkında potansiyel saldırganlardan daha fazlasını bilmeniz kesinlikle çok önemlidir.
Yazılım malzeme listelerinin (SBOM’ler) gelecekteki kullanışlılığı, standartlara uyma, tüm kod tabanını hesaba katma ve kurumsal ölçekte birlikte çalışabilirliğe izin verme becerilerine bağlıdır – sektörümüzün tek tip bir şekilde yapmakta zorlandığı bir şey.
Bir SBOM oluşturmak nispeten kolaydır. Ancak, standart spesifikasyonlara uyan ve kuruluşların onlarla geniş ölçekte birlikte çalışmasına olanak tanıyan kapsamlı ve doğru bir SBOM oluşturmak zor olabilir. Bu nedenle, “tam Monty SBOM” terimini, güvenlik, yasal ve operasyonel amaçlarla gelecekteki kullanımı için gereken içeriği ve birlikte çalışabilirliği sağlayan kapsamlı bir SBOM çözümünü tanımlamak için türettim. Bu kapsamlılıktan yoksun bir SBOM, geçersiz güvenlik veya operasyonel varsayımlara yol açabilir.
Standardizasyon
SBOM’ların evrensel olarak değiş tokuş edilebilmesi ve otomatik olarak okunabilmesi için değişim biçimlerinin standart bir spesifikasyona uygun olması gerekir.
Sektörün yakınsadığı iki standart SPDX ve CycloneDX’tir. Bu standartların amacı, aynı yazılımın bir SBOM’sini üretmek için iki farklı SBOM oluşturma aracı kullanıldığında, aynı sonuçları verecek şekilde çıktıda tekdüzelik oluşturmaktır. Bu biçimler, kullanım durumuna ve sektör dikeyine bağlı olarak lisanslar, telif hakları ve güvenlik açıkları gibi belirli bilgileri içerecek, hariç tutacak veya bunlara bağlantı verecek şekilde uyarlanabilir.
SPDX ve CycloneDX’in yalnızca bir SBOM dosyasının yapısını açıklayan standartlar olduğunu not etmek önemlidir. Doğruluğu veya kapsamlılığı ele almazlar. SBOM oluşturma işleminiz veya aracınız dosyaya çöp beslerse, (güzel bir şekilde biçimlendirilmiş) çöp üretecektir.
Kapsamlılık
Hemen hemen her yazılım uygulamasında en büyük saldırı yüzeyi açık kaynaklı bileşenlerden oluşur. Bunlar, bir yazılım uygulamasının ortalama %76’sını oluşturur ve dünyanın dört bir yanından bireyler tarafından geliştirilir. Log4j, tek bir açık kaynak bileşenindeki tek bir güvenlik açığının nasıl büyük bir küresel etkiye sahip olabileceğinin bir örneğidir. Çoğu kuruluş için, yazılım tedarik zincirlerini güvenceye alma ve bilgi altyapılarını koruma konusundaki en yüksek önceliklerden biri, açık kaynaklı yazılım güvenlik açıklarının hızlı bir şekilde tanımlanması ve düzeltilmesidir.
Bir SBOM’nin sadece bir açık kaynak yazılım (OSS) envanteri olduğuna dair birçok kişi tarafından ani bir tepki var. Çoğu yazılım kompozisyon analizi (SCA) satıcısı, değişen düzeylerde geçişli bağımlılıklarla OSS bileşenlerini listeleyen bir tür SBOM üretecektir. Bununla birlikte, yalnızca OSS’ye özel bir SBOM, bir kuruluşu yazılım tedarik zincirini oluşturan diğer kod türleri içindeki güvenlik açıkları nedeniyle açıkta bırakabilir.
Ancak kapsamlı veya tam bir Monty SBOM, bir uygulamanın özel kod, açık kaynak bileşenleri ve üçüncü taraf OSS olmayan bileşenleri içeren tüm bileşenlerini ortaya çıkarır. Güvenlik açıkları, yalnızca açık kaynaktan değil, tüm kod türlerinden kaynaklanabileceğinden, bu çok önemlidir.
birlikte çalışabilirlik
SBOM’lar statik belgelerdir. Bu nedenle, incelemekten başka bir şey yapamıyorsanız, bir yazılım tedarikçisinden bir yazılıma sahip olmak sınırlı bir değere sahiptir. Gerçek değer, onunla bir şeyler yapma yeteneğinizde, yani birlikte çalışabilirliğinde ve onu, tümü kurumsal ölçekte yama yönetimi ve devreye alma risk değerlendirmeleri gibi diğer yaşam döngüsü risk yönetimi süreçlerine dahil etme becerinizde yatmaktadır.
Birlikte çalışabilir bir SBOM ile ekiplerin yapabileceği üç ortak şeye bakalım: birleştirme, sorgulama ve izleme.
- Birleştirmek: Otomobil üreticilerinin genellikle farklı standart formatlar kullanan birkaç farklı yazılım satıcısı tarafından üretilen birden çok SBOM’yi tek bir sistem SBOM’sinde toplaması gerekecektir.
- Sorgu: Yaygın olarak kullanılan bir yazılım bileşeninde yeni bir sıfır gün güvenlik açığı varsa, birçok yazılım uygulamanızdan hangisinin bu güvenlik açığı bulunan belirli yazılım bileşenini içerdiğini belirlemek için tüm SBOM’larınızı sorgulamak isteyeceksiniz. Günde yaklaşık 60 yeni CVE için incelenmesi gereken binlerce uygulamanız olduğunda bu teknik olarak göz korkutucu olabilir. Binlerce SBOM’u tek bir arayüzden sorgulayabilmek, birlikte çalışabilirliğin ve etkili yazılım risk yönetiminin temel bir unsurudur.
- Monitör: Birlikte çalışabilir şekilde tasarlanan SBOM’lar ile ekipler bunları tehdit istihbaratı ve güvenlik açığı yönetim sistemleriyle entegre edebilir, böylece yeni bir sıfır gün güvenlik açığı ortaya çıktığında, mevcut tüm SBOM’larını söz konusu güvenlik açığı için otomatik olarak inceleyebilir ve ürün ömrünü bildirebilir. – risk döngüsü yönetim sistemi.
Gümüş Kurşun değil
Eksiksiz bir Monty SBOM, inanılmaz derecede önemli olsa da, yazılım tedarik zinciri risk yönetiminin (SSCRM) yalnızca küçük bir parçasıdır. Diğer faktörler arasında, özel kodun ve OSS’nin güvenlik zayıflıkları ve bilinen güvenlik açıkları içermemesi, yazılımın düzenlemelerle uyumlu olması ve geliştirme hattının güvenli ve kurcalamaya karşı dayanıklı olması yer alır. Gıda tedarik zincirinizin sağlığınızı tehlikeye atmamasını bekliyorsunuz; örneğin, çapraz kontaminasyona açık bir fabrikada, sağlık kurallarına aykırı koşullarda üretilen, içeriği bilinmeyen kurabiyeleri yemezsiniz. Aynı şekilde, yazılım tedarik zincirinizin kuruluşunuz için güvenli olduğuna dair güvenceye ihtiyacınız var.
Tanımlama bilgileri veya yazılımla ilgili olsun, ürünün güvenli bir şekilde tüketilmesinin sağlanması, yalnızca bir SBOM’ye sahip olmanın değil, üretim sırasında gerçekleştirilen birçok güvenlik ve güvenlik sürecinin ve periyodik testlerin sonucudur.