Sıradan Kullanıcılar İçin SBOM: Bir Uygulamayı Kurmadan Önce İçeriği Nasıl Kontrol Edilir?

Bir uygulamayı kurmak, yalnızca indirme sayfasında adı görünen şirkete güvenmek anlamına gelmez. Modern yazılımlar genellikle onlarca, hatta yüzlerce harici kütüphane, çalışma çerçevesi, sistem paketi ve hazır bileşen içerir. Bu bileşenlerden herhangi birindeki güvenlik açığı, sorunlu kod uygulamanın ana geliştiricisi tarafından yazılmamış olsa bile nihai ürünü etkileyebilir. Genellikle SBOM olarak kısaltılan Yazılım Malzeme Listesi, bu bileşenlerin düzenli bir kaydını sunar. SBOM sayesinde sıradan bir kullanıcı, yazılımın içinde neler bulunduğunu kontrol edebilir, güncelliğini yitirmiş bağımlılıkları belirleyebilir ve uygulamaya kişisel dosyalara, parolalara ya da iş verilerine erişim izni vermeden önce bilinen güvenlik açıklarını araştırabilir. SBOM tam güvenlik garantisi sağlamaz, ancak yalnızca itibara, kullanıcı yorumlarına ve antivirüs sonuçlarına dayanan bir karar sürecine doğrulanabilir bilgiler ekler.

SBOM Bir Uygulama Hakkında Neleri Gösterir?

SBOM çoğu zaman yazılımlar için hazırlanmış bir içerik listesi olarak tanımlanır. Un, şeker veya koruyucu maddeler yerine uygulamada kullanılan kütüphaneleri, paketleri, modülleri ve diğer bileşenleri kaydeder. Yararlı bir SBOM normalde ana ürünü, bileşenlerin adlarını ve sürümlerini, tedarikçilerini, aralarındaki ilişkileri ve kaydın oluşturulduğu tarihi belirtir. Ayrıca lisans bilgileri, dosya karmaları, paket tanımlayıcıları ve belgeyi oluşturan araç hakkında ayrıntılar da içerebilir. Bu bilgiler, kullanıcı açısından birbirine çok benzeyen ancak farklı dahili bileşenler içeren iki sürümün ayırt edilmesini sağlar.

Bileşen sürümü en önemli alanlardan biridir. Bir güvenlik açığı nadiren bir kütüphanenin tüm sürümlerini etkiler. Sorun yalnızca belirli bir güncellemeden önceki sürümlerde, belirli bir geliştirme dalında veya yalnızca belirli bir işletim sisteminde bulunabilir. Örneğin bir uygulamanın OpenSSL içerdiğini belirten rapor, riski değerlendirmek için tek başına yeterli değildir. Kullanılan kodun güvenlik duyurusunda belirtilen etkilenen sürüm aralığına girip girmediğini belirlemek için kesin sürüm numarası gerekir. Sürüm bilgisi eksik olduğunda tarama aracı gerçek bir sorunu tespit edemeyebilir veya bileşeni yanlışlıkla ilgisiz bir güvenlik açığıyla eşleştirebilir.

SBOM, bağımlılıklar arasındaki ilişkileri de göstermelidir. Bazı bileşenler uygulama geliştiricisi tarafından doğrudan eklenirken, bazıları başka bir kütüphane aracılığıyla dolaylı olarak sisteme dahil edilir. Bu dolaylı bağımlılıklar birkaç katman derinliğinde olabilir ve normal uygulama arayüzünde görünmeyebilir. Bir geliştirici belge işlemek için tek bir kütüphane ekleyebilir; bu kütüphane ise görüntü işleme, sıkıştırma ve karakter kodlama için başka paketlere ihtiyaç duyabilir. Alt seviyedeki bu paketlerden birinde güvenlik açığı bulunması, tamamlanmış uygulamanın da etkilenmesine yol açabilir. Bağımlılık haritası, belirli bir bileşenin neden mevcut olduğunu ve yazılımın hangi bölümünün ona ihtiyaç duyduğunu açıklar.

Yararlı ve İlgili Bir SBOM Nasıl Anlaşılır?

İlk olarak SBOM’un kurulması düşünülen dosyanın tam sürümünü tanımlayıp tanımlamadığı kontrol edilmelidir. Ürün adını, sürüm numarasını, işletim sistemini, işlemci mimarisini ve yayın tarihini indirme sayfasındaki bilgilerle karşılaştırın. Windows sürümüne ait bir bileşen listesi macOS sürümünü açıklamayabilir; aynı şekilde 5.1 sürümüne ait kayıt otomatik olarak 5.2 sürümü için kullanılamaz. Küçük bir uygulama güncellemesi bile birkaç kütüphaneyi değiştirebilir veya güvenlik açığı bulunan bir paketi kaldırabilir. Bu nedenle doğru bir SBOM, ürünün tüm sürümleri için kalıcı bir liste olarak değil, belirli bir yayımla bağlantılı olarak sunulmalıdır.

SPDX ve CycloneDX, sıradan kullanıcıların en sık karşılaşacağı iki formattır. Bu formatlar bileşen bilgilerini güvenlik araçlarının işleyebileceği tutarlı ve makine tarafından okunabilir bir yapıda saklar. Temmuz 2026 itibarıyla SPDX 3.0 güncel kararlı sürümdür; SPDX 3.1 RC1 ise genel kullanım yerine test amacıyla sunulmaktadır. CycloneDX’in güncel yayımlanmış sürümü 1.7’dir. Yaygın dosya adları arasında bom.json, bom.xml, product.cdx.json ve product.spdx.json bulunur. Kullanıcının bu dosyaların tüm yapısını anlaması gerekmez; uygun bir tarama aracı içerikleri okunabilir bir güvenlik açığı raporuna dönüştürebilir.

Belgenin eksiksiz olması, kullanılan format kadar önemlidir. Sürüm numarası bulunmayan bileşenler, sürekli tekrarlanan “bilinmiyor” değerleri, eksik tedarikçi bilgileri ve uygulama için gerçekçi görünmeyecek kadar kısa bir bileşen listesi uyarı işaretidir. Modern bir tarayıcının, video düzenleyicinin veya iletişim uygulamasının yalnızca birkaç harici paketten oluşması pek olası değildir. Bununla birlikte, uzun bir bileşen listesi de zayıf güvenliğin kanıtı değildir. Büyük uygulamalar doğal olarak çok sayıda ayrı projeye bağımlıdır. Asıl önemli olan, SBOM’un bu bileşenleri güvenilir güvenlik açığı kayıtlarıyla eşleştirilebilecek kadar ayrıntılı biçimde tanımlayıp tanımlamadığıdır.

Yazılım Kurulmadan Önce Nasıl Doğrulanır ve Taranır?

İlk olarak kurulum dosyasını ve ona ait SBOM’u yazılım yayıncısının kontrol ettiği bir kaynaktan edinin. Belge, uygulamayla birlikte sürüm deposunda, güvenlik merkezinde veya indirme bölümünde sunulabilir. Dosya adlarında “SBOM”, “SPDX”, “CycloneDX” veya “BOM” ifadelerini arayın. Bazı tedarikçiler, özellikle belge özel mülkiyete ait bileşenler hakkında ayrıntılar içeriyorsa, bu kaydı yalnızca müşterilerine veya talep üzerine sağlar. İlgisiz bir indirme sitesine kopyalanmış SBOM’a güvenmeyin. Bileşen listesi ancak belge, tedarikçi ve uygulamanın belirli sürümü arasında güvenilir bir bağlantı kurulabildiğinde değerlidir.

Bileşenleri analiz etmeden önce kurulum dosyasını doğrulayın. Kriptografik karma değeri, bir dosyanın dijital parmak izi gibi çalışır. Yayıncı SHA-256 değeri sunuyorsa indirilen dosyanın karmasını hesaplayın ve resmî değerle tüm karakterleri karşılaştırın. Windows kullanıcıları PowerShell’de Get-FileHash .\setup.exe -Algorithm SHA256 komutunu çalıştırabilir. macOS’ta shasum -a 256 filename.dmg, birçok Linux sisteminde ise sha256sum filename komutu kullanılabilir. Değerlerin eşleşmesi, indirilen dosyanın yayıncı tarafından ölçülen dosyayla aynı olduğunu doğrular. Bu sonuç özgün yazılımın güvenli olduğunu kanıtlamaz, ancak bozulmayı veya izinsiz değişiklikleri ortaya çıkarabilir.

Dijital imza ek bir doğrulama katmanı sağlar. Windows’ta kurulum dosyasına sağ tıklayın, Özellikler bölümünü açın ve Dijital İmzalar sekmesini kontrol edin. İmza geçerli olmalı ve imzalayan taraf uygulama yayıncısıyla ya da açıkça bağlantılı bir şirketle eşleşmelidir. Microsoft Sigcheck, dosyayı çalıştırmadan sürüm, zaman damgası, sertifika zinciri, karma değerleri ve imza bilgilerini gösterebilir. macOS’ta imzalama ve noter onayı kontrolleri, uygulamanın Apple’ın güvenlik sürecinden geçirilip geçirilmediğinin anlaşılmasına yardımcı olur. İmzasız bir dosya, özellikle küçük bir açık kaynak projesinden geliyorsa, otomatik olarak zararlı kabul edilmemelidir; ancak imzanın bulunmaması, dosyanın kökenine ilişkin kanıtları azaltır.

Ücretsiz Tarama Araçlarıyla Uygulanabilecek Bir Kontrol Süreci

Geçerli bir SBOM mevcutsa Grype, bileşenleri bilinen güvenlik açığı kayıtlarıyla karşılaştırmak için doğrudan kullanılabilir. Grype resmî yayın kaynağından kurulduktan sonra grype sbom:./application-sbom.json gibi bir komut, uygulamayı çalıştırmadan belgeyi tarar. Rapor; etkilenen bileşeni, yüklü sürümü, güvenlik açığı tanımlayıcısını, önem derecesini ve mevcutsa sorunun giderildiği sürümü gösterir. Grype yaygın SBOM formatlarını destekler ve bulguları önceliklendirmeye yardımcı olmak için CISA’nın Bilinen İstismar Edilen Güvenlik Açıkları verileri ile Exploit Prediction Scoring System değerleri gibi ek risk bilgilerini kullanabilir.

OSV-Scanner da özellikle indirilen pakette tanınan SBOM dosyaları, bağımlılık kayıtları veya kaynak kodu kilit dosyaları bulunuyorsa uygun bir seçenektir. Güncel V2 belgelerinde iki aşamalı bir süreç açıklanır: araç önce paket bilgilerini çıkarır, ardından bu paketleri bilinen güvenlik açığı kayıtlarıyla eşleştirir. Çıktıda paket adı, sürüm, güvenlik duyurusu tanımlayıcısı, önem puanı ve düzeltilmiş sürüm bulunabilir. SBOM belgeleri taranırken standart dosya adları önemlidir. SPDX dosyası normalde .spdx.json ile biten bir ad taşımalı, CycloneDX dosyasında ise tanınan CycloneDX adlandırması kullanılmalıdır. Tüm belgeleri genel bir dosya adıyla yeniden adlandırmak, doğru biçimde algılanmalarını engelleyebilir.

Yayıncı SBOM sağlamıyorsa Syft; çıkarılmış bir klasörden, arşivden, dosya sisteminden veya desteklenen bir kapsayıcı görüntüsünden tahmini bileşen listesi oluşturabilir. Örneğin syft dir:./unpacked-app -o cyclonedx-json=app-sbom.cdx.json komutu, açılmış klasörü analiz eder ve sonucu CycloneDX belgesi olarak kaydeder. Bu dosya daha sonra Grype ile kontrol edilebilir. Dosyalara ulaşmak amacıyla güvenilmeyen bir kurulum programını çalıştırmayın. ZIP arşivleri ve bazı kurulum paketleri kod çalıştırılmadan açılabilir, ancak diğer formatlar özel araçlar gerektirebilir. Oluşturulan SBOM, statik olarak derlenmiş, şifrelenmiş veya alışılmadık biçimde paketlenmiş bileşenleri gözden kaçırabilir. Bu nedenle böyle bir belge, yayıncının kendi derleme sürecinde oluşturduğu eksiksiz kayıttan daha güvenilir kabul edilmemelidir.

SBOM’da Bulunan Güvenlik Açıkları Nasıl Değerlendirilir?

Tarama sonucunda CVE, GHSA veya belirli bir yazılım ekosistemine ait güvenlik duyurusu tanımlayıcıları görülebilir. CVE numarası, kamuya açıklanmış bir güvenlik açığı için kullanılan ortak referanstır; uygulamanın o anda saldırı altında olduğunun kanıtı değildir. İlgili güvenlik duyurusunu açın ve etkilenen bileşeni, sürüm aralığını ve gerekli çalışma koşullarını doğrulayın. Birbirine benzeyen paket adları tamamen farklı projelere ait olabilir. SBOM eksik tanımlayıcılar içeriyorsa tarama aracı zaman zaman hatalı eşleştirme yapabilir. Paket adı, tedarikçi, yazılım ekosistemi ve sürüm, duyurudaki bilgilerle eşleştiğinde bulgunun doğruluğu artar.

Önem derecesi genellikle CVSS puanı veya düşük, orta, yüksek ve kritik gibi etiketlerle gösterilir. Bu puan, güvenlik açığının belirli koşullar altındaki teknik ciddiyetini tahmin eder; ancak belirli bir kullanıcı açısından oluşacak riski tamamen açıklamaz. Devre dışı bırakılmış bir özellik gerektiren kritik bir açık, uygulamanın internetten dosya açtığı her durumda kullanılabilen yüksek önem dereceli bir açıktan daha az acil olabilir. İstismar için yerel erişim, kullanıcı etkileşimi, özel yetki veya ağ bağlantısı gerekip gerekmediğini kontrol edin. Uygulamanın erişeceği bilgileri de dikkate alın. Parola, gizli belge veya uzaktan bağlantı yöneten bir yazılımdaki güvenlik açığı, aynı açığın çevrimdışı ve yalıtılmış bir yardımcı programda bulunmasına kıyasla daha ciddi sonuçlar doğurabilir.

CISA’nın Bilinen İstismar Edilen Güvenlik Açıkları Kataloğu’nda bulunan sorunlara özellikle dikkat edin. Bir güvenlik açığının bu kataloğa eklenmesi, saldırganların onu gerçek olaylarda kullandığına dair kanıt bulunduğu anlamına gelir. Exploit Prediction Scoring System veya EPSS ise açığın kısa bir süre içinde istismar edilme ihtimalini olasılığa dayalı olarak tahmin eder. Bu göstergelerin hiçbiri ayrıntılı değerlendirme gereksinimini ortadan kaldırmaz, ancak acil bulguları pratikte sınırlı etkisi bulunan eski açıklardan ayırmaya yardımcı olabilir. Kritik puana sahip, aktif olarak istismar edilen ve düzeltmesi bulunmayan bir bileşen; fiziksel erişim ve önceden kilidi açılmış bir bilgisayar gerektiren düşük önem dereceli sorundan çok daha fazla dikkat gerektirir.

Bir Uygulama Ne Zaman Kurulmalı, Ertelenmeli veya Reddedilmelidir?

Kurulum dosyası doğrudan yayıncıdan alınmışsa, karma değeri eşleşiyorsa, dijital imzası geçerliyse ve SBOM tam olarak ilgili sürümü açıklıyorsa kurulum kararı daha sağlam temellere dayanır. Tarama sonucunda, uygulamanın kullanım biçimi üzerinden erişilebilecek çözümlenmemiş yüksek riskli güvenlik açıkları bulunmamalıdır. Bazı bulgular, yayıncının ürünün neden etkilenmediğini açıklayan net bir Vulnerability Exploitability eXchange veya VEX beyanı sunması hâlinde kabul edilebilir. Örneğin güvenlik açığı bulunan kütüphane dosyada yer alabilir, ancak ilgili işlev derleme sırasında devre dışı bırakılmış veya kaldırılmış olabilir. Yararlı bir VEX beyanı, yalnızca uygulamanın güvenli olduğunu söylemek yerine ürün sürümünü, güvenlik açığını ve teknik gerekçeyi açıkça belirtir.

SBOM eksikse, başka bir sürüme aitse veya düzeltmesi uzun süredir mevcut olan ciddi bir güvenlik açığını bildiriyorsa kurulumu erteleyin. Daha yeni bir uygulama sürümünün yayımlanıp yayımlanmadığını kontrol edin ve yayıncının güvenlik notlarını okuyun. Açıklama bulunmuyorsa ürün sürümünü, bileşen adını ve güvenlik açığı tanımlayıcısını belirterek tedarikçiyle iletişim kurun. Güvenilir bir yanıt, genel güvenlik vaatleri vermek yerine belirli paketi ve etkilenen kod yolunu ele almalıdır. İş ortamında kullanılacak yazılımlar için bilgileri BT veya güvenlikten sorumlu kişiye iletin. Bireysel bir kullanıcı, kurulum sıradan göründüğü için tüm kuruluşu etkileyebilecek riski tek başına kabul etmemelidir.

Dosyanın karma değeri resmî değerle eşleşmiyorsa, imzası geçersizse, iddia edilen yayıncı doğrulanamıyorsa veya indirme güvenilmeyen bir kaynaktan yapıldıysa dosyayı reddedin. Uzaktan kullanılabilen bir güvenlik açığı aktif saldırılarda istismar ediliyor ve düzeltilmiş sürüm ya da etkili bir önlem bulunmuyorsa da aynı karar uygundur. SBOM’un bulunmaması programın tehlikeli olduğunu kanıtlamaz, ancak şeffaflığı azaltır ve bağımsız kontrolü zorlaştırır. Böyle bir durumda tedarikçinin güncelleme geçmişine, güvenlik iletişim kanalına, kamuya açık duyurularına ve uygulamanın işleyeceği bilgilerin hassasiyetine daha fazla önem verin. SBOM; kaynak doğrulaması, sınırlı izinler, güncel yedekler, antivirüs koruması ve güvenlik güncellemelerinin zamanında kurulmasıyla birlikte kullanıldığında en etkili sonucu sağlar.