Çoğu durumda, bir üründe yüksek riskli bir güvenlik açığı tespit edildiğinde, daha büyük bir zorluk ortaya çıkar: etkilenen bileşen veya ürünün Ulusal Güvenlik Açığı Veritabanında (NVD) atanan adıyla nasıl tanımlanacağı. Bunun nedeni, yazılım ürünlerinin NVD’de bir ortak platform numaralandırma ABD Ticaret Bakanlığı’nın bir parçası olan Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) tarafından atanan (CPE) adı.
NVD, donanım ve yazılım bileşenlerini satıcı, ürün ve sürüm dizisine göre tanımlamak için bir CPE kullanır. Yazılım kullanıcıları, NVD aracılığıyla, kullandıkları bir ürünün bir bileşeninin ilgili güvenlik açıkları olup olmadığını belirlemek istediklerinde, bileşenin tam olarak atanan CPE adını bilmeleri gerekir. Ancak, ister açık kaynaklı ister tescilli olsun, belirli bir bileşen için bir CPE bulmak genellikle imkansızdır.
Çoğu durumda, bu sorun, bir yazılım malzeme listesi (SBOM) oluşturmak gibi, yazılım güvenliği için gereken süreçlerin birçoğunu güvenilir bir şekilde otomatikleştirmeyi imkansız hale getirir.
NVD’de Güvenlik Açıklarını Bulmak Neden Zor?
Sorunun kapsamını anlamak için, tek tanımlayıcı olarak CPE’lere dayanması nedeniyle NVD’de bileşen ve ürün güvenlik açıklarını aramayı imkansız değilse de son derece zorlaştıran aşağıdaki altı koşulu göz önünde bulundurun.
1. Güvenlik açıkları, “CVE-2022-12345” gibi ortak bir güvenlik açıkları ve maruz kalma (CVE) numarasıyla NVD’de tanımlanır ve her bir CVE’ye bir tehdit düzeyi atamak için Ortak Güvenlik Açığı Puanlama Sistemi (CVSS) kullanılır. Bir yazılım ürünü için bir CPE, kendisine bir CVE atanana kadar tipik olarak oluşturulmaz. Bununla birlikte, birçok yazılım tedarikçisi hiçbir zaman (bir CVE oluşturabilecek) bir güvenlik açığı bildirmemiştir, bu nedenle NVD’de ürün için hiçbir zaman bir CPE oluşturulmamıştır.
Bunun nedeni, ürünlerin hiçbir zaman güvenlik açıklarına sahip olmaması değil, geliştiricinin mevcut güvenlik açıklarını NVD’ye bildirmemiş olabileceğidir.
Sonuç olarak, bir NVD araması aşağıdaki senaryoların her ikisinde de “Eşleşen kayıt yok” yanıtı verecektir:
(i) belirli bir üründe güvenlik açığı yoktur
(ii) bir güvenlik açığı vardır, ancak geliştirici tarafından hiç bildirilmemiştir
2. NVD’ye yeni bir CPE adı girildiğinde herhangi bir hata denetimi yapılmadığından, tutarlı bir adlandırma kuralına uymayan bir ürün CPE’si oluşturmak mümkündür. Sonuç olarak, bir kullanıcı ürünü uygun şekilde belirtilen CPE’yi kullanarak aradığında “Eşleşen 0 kayıt var” hata iletisi alır. Bu, orijinal (özellik dışı) CPE adı kullanılmışsa ancak buna karşı herhangi bir CVE bildirilmemişse alacakları mesajın aynısıdır.
Bir kullanıcı bu mesajı aldığında, bu, aradıkları ürün için geçerli bir CPE olduğu, ancak o ürün için hiçbir zaman bir CVE raporlanmadığı anlamına gelebilir, ancak aynı zamanda, girdikleri CPE’nin içindeki CPE ile eşleşmediği anlamına da gelebilir. ve NVD’ye sunulan (şartname dışı) CPE adına eklenmiş CVE’ler olduğunu.
“Eşleşen 0 kayıt var” hata mesajı, bir kullanıcı arama çubuğunda CPE adını yanlış yazdığında da ortaya çıkabilir. Bu durumda, kullanıcının mesajın bir yazım hatası tarafından oluşturulduğunu bilmesinin hiçbir yolu yoktur ve bunun yerine üründe bildirilen hiçbir güvenlik açığı olmadığını varsayabilir.
3. Zaman içinde bir ürün veya tedarikçi adı, birleşme veya devralma nedeniyle değişebilir ve ürünün CPE adı da değişebilir. Bu durumda, bir kullanıcı yeni CPE’yi değil de orijinal CPE’yi ararsa yeni güvenlik açıklarını öğrenmez. Daha önce olduğu gibi, “Eşleşen 0 kayıt var” mesajını alacaklardı.
4. Bu, “Microsoft” ve “Microsoft Inc.” veya “Microsoft Word” ve “Microsoft Office Word” vb. gibi farklı tedarikçi veya ürün adları varyasyonları için de geçerlidir. Tam doğru tedarikçi veya ürün adı olmadan, bir NVD araması yanlış sonuçlar verecektir.
5. Aynı ürün, her biri farklı yineleme kullanan farklı kişiler tarafından girilirse, NVD’de birden çok CPE adına sahip olabilir. Bu, hangi ismin doğru olduğunu belirlemeyi neredeyse imkansız hale getirebilir. Daha da kötüsü, her bir CPE varyantı için CVE’ler girilmişse, bu onların “doğru” bir ad olmamasına neden olacaktır. Bir örnek OpenSSL’dir (ör. “OpenSSL” ve “OpenSSL Çerçevesi”). Tek bir CPE adı tüm OpenSSL güvenlik açıklarını içermediğinden, kullanıcıların ürün adının her varyasyonunu ayrı ayrı araması gerekir.
6. Çoğu durumda, bir güvenlik açığı kitaplığın yalnızca bir modülünü etkiler. Ancak CPE adları, içerdikleri tek tek modüllere göre değil, ürünlere göre atandığından, kullanıcıların hangi modülün savunmasız olduğunu belirlemek için CVE raporunun tamamını okuması gerekir. Aksi takdirde, bu durum, kullanılan bir yazılım ürününde güvenlik açığı bulunan bir modülün değil de kitaplığın diğer modüllerinin kurulu olması gibi gereksiz düzeltme eklerine veya hafifletmelere neden olabilir.
Neyse ki, sektörler arası bir grup SBOM Forumu OWASP üyeleri, The Linux Foundation, Oracle ve diğerleri sorun üzerinde çalışıyor ve modern, otomatikleştirilmiş kullanım durumlarına odaklanarak NVD’nin doğruluğunu artırmak için bir teklif geliştirdiler.
Yazılım için bir paket URL’sinin (purl) ve donanım için GS1 Standartlarının benimsenmesi de dahil olmak üzere grubun önerileri, NVD’yi güvenilir bir şekilde sorgulamak ve güvenlik açıkları hakkında doğru bilgi almak için standartlaştırılmış bir yol oluşturmak üzere tasarlanmıştır.