Bir uygulamanın kodunu kendi ekibiniz yazmış olabilir. Ancak uygulama, dışarıdan gelen kütüphaneler ve bu kütüphanelerin başka bağımlılıklarıyla birlikte çalışabilir. Güvenlik açığı duyurulduğunda sorulan ilk soru çoğu zaman çok basittir: Bu bileşen bizde var mı?
Sorunun cevabı tek bir depoda aranarak bulunamayabilir. Aynı kütüphanenin farklı sürümleri farklı ürünlerde kullanılabilir. Uygulamanın kaynak kodu, oluşturulan paket ve gerçekten dağıtılan sürüm arasında da fark olabilir. Yazılım tedarik zincirini konuşurken bu ayrıntılar görünür hâle gelir.
SBOM bir bileşen envanteridir
CISA’nın yazılım bileşeni şeffaflığı belgesi, Software Bill of Materials, yani SBOM’u bileşen ve bağımlılıkların makine tarafından okunabilir envanteri olarak tanımlar. Hangi parçaların bulunduğunu bilmek, etkilenen ürünleri araştırmaya yardım eder. Envanterin sürümle ilişkilendirilmesi ve güncel tutulması bu yüzden gerekir. CISA’nın açıklayıcı çerçevesi.
Bir SBOM, uygulamanın güvenli olduğuna dair sertifika değildir. Listede bir bileşenin bulunması, belirli bir açığın gerçekten sömürülebilir olduğunu da otomatik olarak göstermez. Bunun için açığın koşulları ve uygulamada bileşenin nasıl kullanıldığı incelenmelidir. Envanter, araştırmayı başlatan ve kapsamı daraltan bilgidir.
Paket aynı paket mi?
İkinci soru, indirilen yazılımın beklenen üretim sürecinden gelip gelmediğidir. Sigstore, yazılım imzalama ve doğrulama düzeninde kimlik, imza ve şeffaflık kaydı gibi parçaları birlikte kullanır. Amaç, yazılım çıktısının kökenini ve bütünlüğünü kontrol etmeye yardımcı olmaktır. Sigstore belgeleri.
Burada da imza ile içerik kalitesini karıştırmamak gerekir. Beklenen kişi veya süreç tarafından imzalanmış bir paket yine hata içerebilir. İmza, “bu kodda hiç sorun yok” sorusunun cevabı değildir. Daha çok “beklediğim çıktı mı ve hangi kimlikle ilişkilendiriliyor?” sorusuna katkı verir.
Küçük bir ürün ekibinin senaryosu
Üç hizmet çalıştıran bir ekip düşünelim. Bir kütüphaneyle ilgili güvenlik bildirimi geliyor. Ekip, yalnızca geliştiricilerin bilgisayarındaki bağımlılık dosyalarına bakarsa canlı sürümle ilgili eksik sonuç çıkarabilir. Dağıtılan her sürüm için envanter varsa hangi hizmetlerin araştırılacağı daha açık hâle gelir.
Bu örnekte çalışma sırası şu olabilir: Önce canlı sürümleri ve onların envanterlerini belirle; sonra bildirimin etkilediği sürümlerle karşılaştır; ardından uygulamanın kullanımı açısından etkiyi değerlendir. Güncelleme hazırlanırsa yeni paketin kaynağını ve dağıtılan sürümün gerçekten değiştiğini kontrol et. Bunların her biri ayrı bir kanıt üretir.
Envanterin bulunması işlemi otomatik bitirmez. Örneğin paketin içinde listelenen sürüm ile gerçek dağıtım uyuşmuyorsa, önce bu farkın nedeni çözülmelidir. “SBOM var” kutusunun işaretlenmesi, envanterin güvenilir kullanıldığı anlamına gelmez.
Tedarikçiye sorulabilecek somut sorular
Bir yazılım alırken yalnızca güvenlik özelliklerinin listesini istemek yerine sürümle bağlı bileşen bilgisi sunulup sunulmadığını sorabilirsiniz. Güncellemenin kaynağı nasıl doğrulanıyor? Bir güvenlik bildirimi geldiğinde etkilenen sürümler nasıl açıklanıyor? Envanter ne zaman üretiliyor?
Bu soruların değeri, tek başına bir terimin kullanılmasından gelmez. Gerçek bir sürüm için cevap verilebilmesinden gelir. SBOM ve imza birlikte kullanıldığında, uygulamanın içinde ne bulunduğunu ve elinizdeki çıktının nereden geldiğini araştırmak için iki farklı dayanak sağlar. Yazılım güvenliğini yönetmek bu dayanakları gerçek dağıtımla ilişkilendirmeyi gerektirir.
Bu yazı 1–15 Ekim arşiv serisi kapsamında 16 Ekim 2026’da hazırlanıp eklenmiştir. Metin ve kavramsal kapak görseli yapay zekâ desteğiyle hazırlanmıştır. Kaynak bağlantıları 16 Ekim 2026’da kontrol edilmiştir.
