- Konu sahibi
- #1
Yazılım bileşen envanteri, bir uygulamanın hangi açık kaynak paketleri, kütüphaneleri, işletim sistemi bileşenleri ve sürümlerinden oluştuğunu gösteren listedir. Güvenlik açısından temel amacı, kullanılan bir bileşende açık bulunduğunda bu açığın sizin sitenizi veya sunucunuzu etkileyip etkilemediğini hızlıca belirlemektir. Envanter yoksa ekip, uygulamanın içinde hangi paketlerin bulunduğunu tahmin ederek inceleme yapar.
Bu envanter yalnızca doğrudan eklenen paketleri değil, onların ihtiyaç duyduğu alt bağımlılıkları da kapsamalıdır. Örneğin bir PHP uygulamasında uygulama yöneticisi tarafından eklenen paket, başka bir HTTP istemci kütüphanesine bağlı olabilir. Açık doğrudan eklediğiniz pakette değil, bu alt bağımlılıkta bulunabilir. Bu nedenle yalnızca proje dosyasındaki üst seviye paket adlarını listelemek eksik sonuç verir.
Bu kayıt, makine tarafından işlenebilir SBOM (Software Bill of Materials) biçiminde üretilebilir. SPDX veya CycloneDX gibi formatlar bileşen kimliği ve bağımlılık ilişkilerini taşımaya yardımcı olur; yalnız düz bir paket listesi her SBOM gereksinimini karşılamaz. Tedarikçi/bileşen adı, sürüm, benzersiz tanımlayıcı, bağımlılık ilişkisi, envanteri oluşturan taraf ve üretim zamanı gibi bilgiler izlenebilirlik sağlar.
Envanter, her bileşen için mümkün olduğunca bileşen adı, sürüm, paket yöneticisi, doğrudan veya dolaylı bağımlılık durumu ve kullanılan uygulama ya da sunucu bilgisini tutar. Güvenlik duyurusu yayımlandığında bu kayıtlar duyurudaki etkilenen bileşen ve sürüm aralığıyla karşılaştırılır. Eşleşme bulunması, tek başına sistemin kesin olarak istismar edildiğini göstermez; yalnızca hangi varlığın incelenmesi gerektiğini gösterir.
Somut bir örnekte, bir web uygulaması
Envanterin değerini, güncel tutulması ve bir işlemle ilişkilendirilmesi belirler. Aşağıdaki ayrım, bulgunun önceliğini yorumlamayı kolaylaştırır:
Tablo, güvenlik duyurusunu doğrudan “saldırı var” sonucuna çevirmemek için kullanılır. Eşleşen bileşenin dışarıdan erişilebilir olup olmadığı, ilgili özelliğin etkinliği, uygulamanın yapılandırması ve loglarda şüpheli hareket bulunup bulunmadığı ayrıca değerlendirilmelidir.
Envanteri ilgili release/commit veya konteyner digest’iyle eşleştirin; kaynak ağacı, build çıktısı ve çalışan dağıtım farklı kapsamlar olabilir. Dev bağımlılığı da CI/build zincirini etkileyebildiği için “üretimde yok” otomatik risksiz demek değildir. İşletim sistemi dağıtıcısı güvenlik düzeltmesini eski sürüm numarasına backport etmiş olabilir; yalnız upstream sürüm karşılaştırmasıyla kesin açık ilan etmeyin, dağıtıcının duyurusunu kontrol edin. VEX gibi değerlendirme bilgisi, belirli ürün bağlamında etkilenme durumunu envanterden ayrı açıklayabilir.
En yaygın hata, envanteri bir kez oluşturup güncelleme sürecinden koparmaktır. Paket eklendiğinde, silindiğinde veya dağıtım yöntemi değiştiğinde kayıt da yenilenmelidir. İkinci hata, yalnızca doğrudan bağımlılıkları listelemektir; güvenlik riski çoğu zaman alt bağımlılıkta ortaya çıkabilir.
Bir diğer hata, sürüm adını yanlış yorumlamaktır. Aynı bileşen farklı paket yöneticilerinde farklı biçimde adlandırılabilir ve işletim sistemi paketi ile uygulamanın kendi paketi birbirine karıştırılabilir. Son olarak, envanterde eşleşen bir açık bulunduğunda etkilenen bileşenin gerçekten çalıştığı yolu ve ilgili özelliğin kullanılıp kullanılmadığı incelenmeden kesin ihlal kararı verilmemelidir.
Hayır. Uygulama bağımlılıklarının yanında işletim sistemi paketleri, konteyner imajları, eklentiler ve dağıtıma dahil edilen diğer üçüncü taraf bileşenler de kapsamda değerlendirilebilir. Kapsam, güvenlik açısından takip etmek istediğiniz teslimat birimine göre belirlenmelidir.
Bu sonuç, etkilenen bileşen veya sürümün ortamda bulunabileceğini gösterir. İhlalin gerçekleştiğini kanıtlamaz. Üretim kullanımı, erişilebilir özellik, yapılandırma ve log incelemesiyle risk doğrulanmalı; ardından güncelleme veya uygun azaltma kararı verilmelidir.
Bu envanter yalnızca doğrudan eklenen paketleri değil, onların ihtiyaç duyduğu alt bağımlılıkları da kapsamalıdır. Örneğin bir PHP uygulamasında uygulama yöneticisi tarafından eklenen paket, başka bir HTTP istemci kütüphanesine bağlı olabilir. Açık doğrudan eklediğiniz pakette değil, bu alt bağımlılıkta bulunabilir. Bu nedenle yalnızca proje dosyasındaki üst seviye paket adlarını listelemek eksik sonuç verir.
Bu kayıt, makine tarafından işlenebilir SBOM (Software Bill of Materials) biçiminde üretilebilir. SPDX veya CycloneDX gibi formatlar bileşen kimliği ve bağımlılık ilişkilerini taşımaya yardımcı olur; yalnız düz bir paket listesi her SBOM gereksinimini karşılamaz. Tedarikçi/bileşen adı, sürüm, benzersiz tanımlayıcı, bağımlılık ilişkisi, envanteri oluşturan taraf ve üretim zamanı gibi bilgiler izlenebilirlik sağlar.
Nasıl çalışır?
Envanter, her bileşen için mümkün olduğunca bileşen adı, sürüm, paket yöneticisi, doğrudan veya dolaylı bağımlılık durumu ve kullanılan uygulama ya da sunucu bilgisini tutar. Güvenlik duyurusu yayımlandığında bu kayıtlar duyurudaki etkilenen bileşen ve sürüm aralığıyla karşılaştırılır. Eşleşme bulunması, tek başına sistemin kesin olarak istismar edildiğini göstermez; yalnızca hangi varlığın incelenmesi gerektiğini gösterir.
Somut bir örnekte, bir web uygulaması
framework-x paketini doğrudan kullanıyor ve bu paket parser-y kütüphanesini dolaylı olarak getiriyor olsun. parser-y için güvenlik duyurusu çıktığında envanter şu sorulara hızlı yanıt verir:-
parser-yuygulamada gerçekten kurulu mu? - Hangi sürüm veya sürümler kullanılıyor?
- Bu bileşen üretim sunucusunda mı, yalnızca geliştirme ortamında mı bulunuyor?
- Güncelleme yapılırsa hangi üst paketler etkilenebilir?
Envanterden hangi kararlar çıkarılır?
Envanterin değerini, güncel tutulması ve bir işlemle ilişkilendirilmesi belirler. Aşağıdaki ayrım, bulgunun önceliğini yorumlamayı kolaylaştırır:
| Bulgu | İlk karar | Sonraki kontrol |
|---|---|---|
| Etkilenen sürüm üretimde | Güncelleme veya geçici azaltma planla | Uygulama işlevlerini ve logları incele |
| Yalnız geliştirme bileşeni | Üretim etkisini ayır | Dağıtım paketlerine sızmadığını doğrula |
| Bileşen envanterde yok | Kayıt kapsamını sorgula | Kurulum ve dağıtım çıktısını yeniden tara |
| Sürüm belirsiz | Bulguya kesinlik atfetme | Kilit dosyası, paket yöneticisi ve sunucuyu karşılaştır |
Tablo, güvenlik duyurusunu doğrudan “saldırı var” sonucuna çevirmemek için kullanılır. Eşleşen bileşenin dışarıdan erişilebilir olup olmadığı, ilgili özelliğin etkinliği, uygulamanın yapılandırması ve loglarda şüpheli hareket bulunup bulunmadığı ayrıca değerlendirilmelidir.
Uygulanabilir en küçük süreç
- Uygulamanın ve sunucuya dağıtılan paketin bağımlılık listesini çıkarın. Kaynak kodundaki tanım dosyasıyla yetinmeyip kilit dosyasını ve gerçek dağıtım çıktısını da karşılaştırın.
- Her bileşenin adını ve sürümünü, doğrudan mı yoksa dolaylı mı geldiğini belirterek tek bir envanter kaydında toplayın.
- Envanteri üretim, test ve geliştirme ortamlarını ayıracak şekilde saklayın. Aynı paketin farklı ortamlarda farklı sürümleri bulunabilir.
- Güvenlik duyurusundaki etkilenen sürüm aralığını envanterle eşleştirin. Eşleşme yoksa kaydı kapatmadan önce taramanın gerçek dağıtım paketini kapsadığını doğrulayın.
- Etkilenen bileşen varsa önce yedekleme, test ve geri dönüş planını kontrol ederek güncelleyin. Güncelleme mümkün değilse ilgili özelliği sınırlamak gibi geçici azaltmaları değerlendirin.
- İşlemden sonra envanteri yeniden üretin ve çalışan sürümün değiştiğini doğrulayın. Eski sürüm yalnızca önbellekte veya kullanılmayan bir dizinde kalmışsa bunun üretim sürecine etkisini ayrıca kontrol edin.
Envanteri ilgili release/commit veya konteyner digest’iyle eşleştirin; kaynak ağacı, build çıktısı ve çalışan dağıtım farklı kapsamlar olabilir. Dev bağımlılığı da CI/build zincirini etkileyebildiği için “üretimde yok” otomatik risksiz demek değildir. İşletim sistemi dağıtıcısı güvenlik düzeltmesini eski sürüm numarasına backport etmiş olabilir; yalnız upstream sürüm karşılaştırmasıyla kesin açık ilan etmeyin, dağıtıcının duyurusunu kontrol edin. VEX gibi değerlendirme bilgisi, belirli ürün bağlamında etkilenme durumunu envanterden ayrı açıklayabilir.
Sık yapılan hatalar
En yaygın hata, envanteri bir kez oluşturup güncelleme sürecinden koparmaktır. Paket eklendiğinde, silindiğinde veya dağıtım yöntemi değiştiğinde kayıt da yenilenmelidir. İkinci hata, yalnızca doğrudan bağımlılıkları listelemektir; güvenlik riski çoğu zaman alt bağımlılıkta ortaya çıkabilir.
Bir diğer hata, sürüm adını yanlış yorumlamaktır. Aynı bileşen farklı paket yöneticilerinde farklı biçimde adlandırılabilir ve işletim sistemi paketi ile uygulamanın kendi paketi birbirine karıştırılabilir. Son olarak, envanterde eşleşen bir açık bulunduğunda etkilenen bileşenin gerçekten çalıştığı yolu ve ilgili özelliğin kullanılıp kullanılmadığı incelenmeden kesin ihlal kararı verilmemelidir.
Kaynaklar
- CISA ve uluslararası ortaklar: SBOM öğeleri
- CycloneDX: Software Bill of Materials
- CycloneDX: Vulnerability Exploitability eXchange
Sık sorulan sorular
Yazılım bileşen envanteri yalnızca uygulamalar için mi gereklidir?
Hayır. Uygulama bağımlılıklarının yanında işletim sistemi paketleri, konteyner imajları, eklentiler ve dağıtıma dahil edilen diğer üçüncü taraf bileşenler de kapsamda değerlendirilebilir. Kapsam, güvenlik açısından takip etmek istediğiniz teslimat birimine göre belirlenmelidir.
Envanterde bir açıkla eşleşme çıkması ne anlama gelir?
Bu sonuç, etkilenen bileşen veya sürümün ortamda bulunabileceğini gösterir. İhlalin gerçekleştiğini kanıtlamaz. Üretim kullanımı, erişilebilir özellik, yapılandırma ve log incelemesiyle risk doğrulanmalı; ardından güncelleme veya uygun azaltma kararı verilmelidir.
