Yazılım Malzeme Listesi (SBOM)

Bir Yazılım Malzeme Listesi (SBOM), bir yazılım parçasının içindeki tüm bileşenlerin (kütüphaneler, bunların sürümleri, lisansları ve sağlayıcı bilgileri) makine tarafından okunabilen resmî envanteridir.

Bir gıda etiketinin içerikleri listelemesi gibi, bir SBOM şu soruyu saniyeler içinde yanıtlamanızı sağlar: bu ürün X'in güvenlik açığı içeren sürümünü barındırıyor mu? Böyle bir liste olmadan bu soru, elle yürütülen araştırmalarla günler sürebilir.

Kritik bir güvenlik açığı ortaya çıktığında, operasyon açısından ilk soru maruziyettir: etkilenen bileşeni ürünlerimizin hangileri içeriyor?

Log4Shell olayı sırasında SBOM'leri olan kuruluşlar envanterlerini sorgulayıp birkaç saat içinde önceliklendirme yaptı. SBOM'si olmayanlar ise derleme klasörlerinde metin aramak için haftalar harcadı. Düzenleyici kurumlar ve büyük alıcılar, satın alma koşulu olarak SBOM'leri giderek daha fazla zorunlu kılıyor.

• Güvenlik açığının etkisini hızla analiz etme
• Lisans uyumluluğu ve yükümlülükleri izleme
• Müşteriler ve denetçiler için tedarik zinciri şeffaflığı

İki açık standart öne çıkar. Araçlar genellikle bu ikisi arasında dönüşüm yapabilir.

• SPDX — lisanslama konusunda güçlü ve düzenleyici kurumlar tarafından geniş ölçüde kabul edilen Linux Vakfı standardı
• CycloneDX — güvenliğe odaklanan, güvenlik açığı ve bağımlılık ilişkisi verilerini destekleyen bir OWASP standardı

Kendi biçiminizi icat etmekten kaçının; kullanıcılar ve tarayıcılar bu standartları bekler.

Her bileşen girdisi, güvenlik açığı akışlarıyla eşleştirilebilmesi için yeterli kimlik bilgisi taşımalıdır. Temel alanlar şunlardır:

• ad ve sürüm — aralık değil, kesin değer
• PURL (paket adresi) — pkg:npm/lodash@4.17.21 gibi evrensel bir tanımlayıcı
• karma — bütünlüğü doğrulamak için
• lisans — SPDX lisans tanımlayıcısı
• sağlayıcı — onu kimin ürettiği

SBOM'leri kaynak koddan veya derlenmiş bir çıktıdan otomatik olarak oluşturun. Syft, her iki standardı da üreten, ekosistemler arası yaygın bir oluşturucudur.

Farklı aşamalarda oluşturulan bir SBOM, farklı gerçekleri yansıtır.

• Kaynak SBOM'si — bildirim dosyasının beyan ettikleri; paketlenmiş veya depoya dahil edilmiş kodları gözden kaçırabilir
• Derleme SBOM'si — derlemenin gerçekte dahil ettiği her şey; sürüm için en doğru seçenektir
• Çalışma zamanı / dağıtılmış SBOM — OS paketleri de dahil olmak üzere çalışan görüntüde gerçekte bulunanlar

Tedarik zinciri güvencesi için gerçek çıktıyı temel alarak derleme zamanında oluşturun ve son kapsayıcıyı OS düzeyindeki paketler için de tarayın.

Bir SBOM, bileşenleri bilinen CVE'lerle eşleştiren bir eşleştiriciye aktarıldığında güçlü hâle gelir. Bu yaklaşım, oluşturmayı analizden ayırır: yeni bir CVE yayımlandığı gün eski bir SBOM'yi tarayabilirsiniz.

Bir SBOM, ürününüzde gerçekte istismar edilemeyen bir güvenlik açığına sahip bileşeni gösterebilir (güvenlik açığı içeren işlev hiç çağrılmıyordur). Bir VEX (Güvenlik Açığı İstismar Edilebilirliği eXchange) belgesi bu değerlendirmeyi kaydeder.

VEX gürültüyü azaltır: listelenen her CVE karşısında müşterilerin paniğe kapılmasını beklemek yerine, gerekçesiyle birlikte not_affected veya giderim bilgisiyle affected bildirimini yayımlarsınız. Böylece ham envanter, eyleme dönük bir önceliklendirmeye dönüşür.

Bir SBOM, ancak gerçekliği doğrulanmışsa ve açıkladığı kesin çıktıyla ilişkilendirilmişse güvenilirdir. SBOM'yi imzalayın ve tek başına bir dosya olarak değil, bir doğrulama beyanı olarak ekleyin.

Elle oluşturulan SBOM'ler anında güncelliğini yitirir. Üretimi işlem hattına bağlayın; böylece her sürüm bir tane üretip derleme çıktısı olarak saklasın ve ideal olarak aynı iş içinde imzalayıp tarasın.

• Yalnızca depodan değil, derlenmiş çıktıdan üretin
• SBOM'leri sürüme göre anahtarlanmış, sorgulanabilir bir kayıt deposunda saklayın
• Saklanan SBOM'leri güncel CVE akışlarına karşı belirli aralıklarla yeniden tarayın
• Sürümleri güvenlik açığı taraması sonucuna göre onaylayın veya engelleyin

SBOM'ler yalnızca bir kutucuğu işaretleme işi olarak görüldüğünde sessizce başarısız olur.

• Güncel olmayan — bir kez oluşturulmuş ve bir daha oluşturulmamış
• Eksik — OS paketlerini, statik olarak bağlanmış veya depoya dahil edilmiş kodları kaçırıyor
• Doğrulanmamış — onu dağıtılmış çıktıya bağlayan bir karma yok
• Kullanılmayan — üretilmiş, ancak hiç taranmamış veya sorgulanmamış

Amaç, bir kerelik JSON dosyası değil; doğru, yeniden oluşturulan, imzalanan ve sürekli taranan bir SBOM'dir.

Artık yazılımınızın neler içerdiğini envantere alabilir ve buna göre harekete geçebilirsiniz.

• Bir SBOM, SPDX veya CycloneDX biçimindeki her bileşenin makine tarafından okunabilen listesidir
• Bileşenleri PURL, sürüm, karma ve lisans ile tanımlayın
• SBOM'yi derleme zamanında oluşturun, ardından CVE'ler için bir eşleştiriciye (grype, osv-scanner) aktarın
• Gerçek istismar edilebilirliği belirtmek ve yanlış alarmları azaltmak için VEX kullanın
• Sürekli tümleştirme ortamında imzalama ve otomatikleştirme yapın; saklanan SBOM'leri yeni akışlara karşı yeniden tarayın

Sıradaki: derleme çıktılarının nereden geldiğini imzalama yoluyla kanıtlama.