SBOM Nedir? Yazılım Tedarik Zinciri Güvenliği İçin 8 Kritik Adım

SBOM nedir sorusu, yazılım ürünlerinde kullanılan açık kaynak kütüphaneleri, ticari bileşenleri ve dolaylı bağımlılıkları görünür hâle getirmek isteyen şirketler için giderek daha önemli hâle geliyor. Software Bill of Materials ifadesinin kısaltması olan SBOM, Türkçede genellikle Yazılım Malzeme Listesi olarak adlandırılır.

Bir SBOM, uygulamanın hangi yazılım bileşenlerinden oluştuğunu, bu bileşenlerin sürümlerini, sağlayıcılarını, lisanslarını ve birbirleriyle olan bağımlılık ilişkilerini makine tarafından işlenebilir biçimde kaydeder. Bu yönüyle gıda ambalajındaki içerik listesine benzetilebilir. Ancak yalnızca bileşen adlarını sıralamak yeterli değildir; doğru sürüm, benzersiz tanımlayıcı, bağımlılık grafiği, üretim zamanı ve bütünlük bilgileri de güvenilir bir SBOM’un önemli parçalarıdır.

SBOM özellikle yeni bir güvenlik açığı açıklandığında değer kazanır. Güvenlik ekibi bütün projeleri elle incelemek yerine, etkilenen bileşenin hangi uygulamalarda, konteynerlerde ve sürümlerde bulunduğunu SBOM deposu üzerinden arayabilir. Böylece güvenlik açığının etkisi daha hızlı belirlenebilir ve düzeltme önceliği oluşturulabilir.

Bununla birlikte SBOM tek başına güvenlik açığı tarayıcısı, yama yönetim sistemi veya güvenli yazılım geliştirme programı değildir. Eksik, güncel olmayan veya yanlış bileşenlerle hazırlanmış bir liste sahte bir güven duygusu oluşturabilir. SBOM’un CI/CD süreçleri, güvenlik açığı istihbaratı, varlık yönetimi, VEX belgeleri ve olay müdahale planlarıyla birlikte kullanılması gerekir.

Bu rehberde SBOM nedir, hangi bilgileri içerir, SPDX ve CycloneDX arasındaki farklar nelerdir, SBOM nasıl oluşturulur, CI/CD sürecine nasıl eklenir ve yazılım tedarik zinciri güvenliği için hangi sekiz kritik adımın uygulanması gerekir sorularını ayrıntılı olarak ele alacağız.

SBOM Nedir?

SBOM, bir yazılım ürününün oluşturulmasında veya çalıştırılmasında kullanılan bileşenlerin ve bu bileşenler arasındaki tedarik zinciri ilişkilerinin yapılandırılmış kaydıdır.

Bir uygulama yalnızca geliştirici ekibin yazdığı kaynak koddan oluşmaz. Modern bir yazılım ürünü aşağıdaki unsurların birleşiminden meydana gelebilir:

• Doğrudan eklenen açık kaynak kütüphaneleri
• Bu kütüphanelerin dolaylı bağımlılıkları
• Ticari yazılım geliştirme kitleri
• İşletim sistemi paketleri
• Konteyner taban imajları
• Çalışma zamanı bileşenleri
• Web sunucuları ve uygulama sunucuları
• Mobil uygulama SDK’ları
• Derleme araçları ve eklentileri
• Dış API ve hizmet bağımlılıkları
• Birinci taraf kurum içi paketler

SBOM bu bileşenleri görünür hâle getirerek yazılımın hangi parçalardan oluştuğuna dair sorgulanabilir bir envanter sağlar.

SBOM’un Basit Tanımı

SBOM’u şu şekilde özetleyebiliriz:

Bir yazılım ürününde bulunan bileşenleri, sürümleri, kimlikleri ve bağımlılık ilişkilerini makine tarafından işlenebilir biçimde gösteren yazılım içerik listesi.

SBOM Yalnızca Açık Kaynak İçin midir?

Hayır. SBOM içerisinde aşağıdaki bileşen türleri birlikte gösterilebilir:

• Açık kaynak yazılımlar
• Ticari lisanslı bileşenler
• Şirket içinde geliştirilen paketler
• İşletim sistemi bileşenleri
• Donanım yazılımları
• Konteyner katmanları
• Yapay zekâ modelleri ve veri varlıkları
• Uygulamanın kullandığı dış hizmetler

Hangi bileşenlerin dahil edileceği SBOM’un kapsamına, üretim aşamasına ve kullanılan formata bağlıdır.

SBOM Neden Gereklidir?

Yazılım geliştirme ekipleri binlerce açık kaynak ve üçüncü taraf bileşen kullanabilir. Bu bağımlılıkların yalnızca proje dosyalarında bulunması, şirket çapında görünür oldukları anlamına gelmez.

Güvenlik Açıklarını Daha Hızlı Bulmak

Yeni bir CVE açıklandığında güvenlik ekibi aşağıdaki sorulara hızlıca cevap vermek ister:

• Etkilenen paket ürünlerimizde bulunuyor mu?
• Hangi sürümü kullanıyoruz?
• Bağımlılık doğrudan mı, dolaylı mı?
• Hangi ürün sürümleri etkileniyor?
• Üretim ortamında çalışıyor mu?
• Dışarıdan erişilebilir mi?
• Düzeltme yapılabilecek daha güvenli sürüm var mı?

Güncel bir SBOM deposu bu araştırmanın başlangıç süresini önemli ölçüde azaltabilir.

Yazılım Tedarik Zincirini Görmek

Geliştirici yalnızca bir paketi doğrudan eklemiş olabilir. Ancak o paket onlarca başka kütüphaneyi beraberinde getirebilir. SBOM, doğrudan ve geçişli bağımlılıkların grafiğini göstererek görünmeyen tedarik zinciri katmanlarını ortaya çıkarır.

Tedarikçi Riskini Değerlendirmek

Bir yazılım satın alan şirket, tedarikçiden SBOM isteyerek ürünün hangi üçüncü taraf bileşenleri içerdiğini inceleyebilir. Ancak yalnızca belgeyi almak yeterli değildir. Kuruluşun SBOM’u okuyabilecek, analiz edebilecek ve bulgulara göre işlem yapabilecek sürece de sahip olması gerekir.

Lisans Uyumluluğunu Desteklemek

Açık kaynak bileşenlerin lisans şartları birbirinden farklı olabilir. Bazı lisanslar atıf, kaynak kod paylaşımı veya bildirim dosyası bulundurma gibi yükümlülükler doğurabilir.

SBOM; lisans ekiplerinin hangi bileşenin hangi lisansla kullanıldığını tespit etmesine yardımcı olur. Hukuki değerlendirme yine lisans uzmanları tarafından yapılmalıdır.

Müşteri ve İhale Gereksinimlerini Karşılamak

Kurumsal müşteriler, kritik altyapı işletmeleri ve kamu kurumları satın aldıkları yazılımlar için makine tarafından işlenebilir SBOM talep edebilir. Ürününüzü uluslararası pazarlara sunuyorsanız SBOM hazırlama kabiliyeti tedarikçi değerlendirmelerinde avantaj sağlayabilir.

Yazılım ürünlerini yurt dışına sunan şirketlerin operasyonel planlaması için Yazılım İhracatı Nasıl Yapılır? rehberimizi inceleyebilirsiniz.

SBOM Hangi Bilgileri İçerir?

SBOM alanları kullanılan standart, üretim aracı ve kurum politikasına göre değişebilir. Güvenilir bir SBOM için aşağıdaki bilgiler pratik bir başlangıç noktasıdır.

Belge Bilgileri

• SBOM belge kimliği
• SBOM sürümü
• Belgeyi oluşturan kişi, kuruluş veya araç
• Oluşturulma zamanı
• Kullanılan SBOM standardı ve sürümü
• Üretim bağlamı
• SBOM’un kapsadığı ürün veya yazılım sürümü

Bileşen Bilgileri

• Bileşen adı
• Bileşen sürümü
• Tedarikçi veya üretici
• Bileşen türü
• Paket yöneticisi ekosistemi
• Benzersiz paket tanımlayıcıları
• Dosya veya paket özet değerleri
• Lisans bilgileri
• İndirme veya kaynak konumu

Bağımlılık Bilgileri

• Uygulamanın doğrudan bağımlılıkları
• Geçişli veya dolaylı bağımlılıklar
• Hangi bileşenin hangi bileşene bağlı olduğu
• Derleme zamanı ve çalışma zamanı ilişkileri
• Bağımlılık grafiğinin tamamlanma durumu

Yaygın Benzersiz Tanımlayıcılar

Bileşen adları tek başına yeterli olmayabilir. Aynı ada sahip farklı paketler bulunabileceği için benzersiz tanımlayıcıların kullanılması gerekir.

• PURL: Package URL
• CPE: Common Platform Enumeration
• SPDXID: SPDX belgesi içindeki benzersiz kimlik
• bom-ref: CycloneDX bağımlılık referansı
• Dosya özeti: SHA-256 gibi kriptografik özet

Örnek PURL

Bir npm paketinin Package URL değeri şu yapıda olabilir:

pkg:npm/lodash@4.17.21

Bir Maven bileşeni ise grup ve paket bilgisiyle tanımlanabilir:

pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2

Standartlaştırılmış tanımlayıcılar, SBOM bileşenlerinin güvenlik açığı veri tabanları ve envanter sistemleriyle eşleştirilmesini kolaylaştırır.

SBOM Ne Değildir?

SBOM’un doğru kullanılabilmesi için neleri yapmadığının anlaşılması gerekir.

SBOM Bir Güvenlik Açığı Tarayıcısı Değildir

SBOM bileşenleri listeler. Güvenlik açığı tarayıcısı ise bu bileşenleri CVE, güvenlik duyurusu ve tehdit istihbaratı kaynaklarıyla karşılaştırır.

SBOM Güvenli Kod Garantisi Vermez

Bir yazılımın eksiksiz SBOM’a sahip olması, kendi kaynak kodunda güvenlik açığı bulunmadığını göstermez. Yetkilendirme hataları, iş mantığı açıkları, yanlış yapılandırmalar ve gizli anahtar sızıntıları ayrı kontroller gerektirir.

SBOM Yama Yönetiminin Yerini Tutmaz

Etkilenen bileşeni tespit etmek ilk adımdır. Sonrasında güvenli sürüme yükseltme, test, dağıtım ve doğrulama işlemleri yapılmalıdır.

SBOM Çalışma Zamanı Envanteriyle Aynı Değildir

Bir bileşenin derleme sırasında bulunması onun üretimde aktif biçimde kullanıldığını göstermeyebilir. Aynı şekilde çalışma ortamında sonradan yüklenen bir eklenti, derleme SBOM’unda bulunmayabilir.

SBOM Tek Başına Risk Puanı Değildir

Risk değerlendirmesinde şu bilgiler birlikte kullanılmalıdır:

• Güvenlik açığının şiddeti
• Bilinen istismar durumu
• Bileşenin çalışma ortamındaki erişilebilirliği
• Uygulamanın kritikliği
• Veri hassasiyeti
• Ağın dışarıya açıklığı
• Mevcut güvenlik kontrolleri

Kaynak, Derleme ve Dağıtım SBOM’u Arasındaki Fark

SBOM’un hangi aşamada üretildiği, içerdiği bilgileri doğrudan etkiler.

Kaynak SBOM’u

Kaynak kod deposu ve paket yönetimi dosyaları incelenerek oluşturulur.

Kaynaklar

• package-lock.json
• pom.xml
• requirements.txt
• poetry.lock
• go.mod
• Gemfile.lock
• composer.lock

Avantajı

Geliştirme sürecinin erken aşamasında üretilebilir ve geliştiriciye hızlı geri bildirim sağlar.

Sınırlaması

Derleme sırasında indirilen, üretilen veya değiştirilerek paketlenen bütün bileşenleri göstermeyebilir.

Derleme SBOM’u

Yazılım derlenirken gerçek bağımlılık ve çıktı bilgileri üzerinden oluşturulur.

Avantajı

Dağıtılacak artefakta daha yakın bir bileşen görünümü sağlar.

Sınırlaması

Çalışma ortamında sonradan eklenen bileşenleri içermeyebilir.

Artefakt veya İkili SBOM

Konteyner imajı, kurulum paketi, mobil uygulama veya derlenmiş ikili dosya taranarak oluşturulur.

Avantajı

Dağıtılan paketin içinde gerçekten bulunan bileşenleri ortaya çıkarabilir.

Sınırlaması

Derleme sürecindeki kaynak ve köken bilgilerini tam olarak belirlemek zor olabilir.

Çalışma Zamanı SBOM’u

Üretim ortamında gerçekten yüklenen veya çalışan bileşenlerin izlenmesine odaklanır.

Avantajı

Dinamik eklentileri, dış hizmetleri ve çalışma zamanında yüklenen modülleri daha iyi gösterebilir.

Sınırlaması

Gözlem süresince çalıştırılmayan bir bileşen görünmeyebilir.

En güçlü yaklaşım, kaynak kodu, derleme sistemi, dağıtılan artefakt ve çalışma ortamından elde edilen verileri ilişkilendirmektir.

SPDX ve CycloneDX Arasındaki Farklar

SPDX ve CycloneDX, SBOM verilerinin makine tarafından işlenebilir ve farklı araçlar arasında taşınabilir biçimde sunulmasını sağlayan iki önemli açık standarttır.

SPDX Nedir?

SPDX, yazılım ve sistem bileşenleriyle ilgili BOM bilgilerinin ortak bir standart üzerinden paylaşılmasını sağlar. Lisans tanımlayıcıları, paketler, dosyalar, bileşen ilişkileri, güvenlik bilgileri, yapay zekâ modelleri ve derleme kökeni gibi farklı veri alanlarını destekleyebilir.

Güncel resmî sürüm bilgileri için SPDX Specifications sayfasını inceleyebilirsiniz.

CycloneDX Nedir?

CycloneDX, yazılım tedarik zinciri şeffaflığı için geliştirilmiş modüler bir BOM standardıdır. Bileşenlerin yanında dış hizmetler, bağımlılık grafikleri, güvenlik açıkları, VEX bilgileri, kriptografik varlıklar ve üretim süreçleri gibi verileri de temsil edebilir.

Güncel sürüm ve veri modeli için CycloneDX Specification Overview sayfasını kullanabilirsiniz.

Hangisi Seçilmelidir?

Tek bir standart her şirket için otomatik olarak en iyi seçim değildir. Aşağıdaki ölçütler değerlendirilmelidir:

• Müşterinin istediği format
• Kullandığınız SBOM üretim araçları
• Güvenlik platformunun desteklediği format
• Lisans analizi gereksinimi
• VEX ve güvenlik açığı iş akışı
• İç ve dış sistemlerle entegrasyon
• Kurumsal satın alma şartları

Mümkünse oluşturulan SBOM’un farklı sistemler tarafından doğrulanabildiğini test edin. Yalnızca dosya uzantısının doğru olması standart uyumluluğu garanti etmez.

SBOM ve SCA Arasındaki Fark Nedir?

Software Composition Analysis veya SCA, yazılım bileşimi analizi anlamına gelir. SCA araçları kaynak kodu, kilit dosyalarını, ikili paketleri veya konteyner imajlarını tarayarak üçüncü taraf bileşenleri tespit etmeye çalışır.

SCA aracı bir SBOM oluşturabilir. Ancak her SBOM yalnızca tek bir SCA aracına bağlı olmak zorunda değildir.

VEX Nedir ve SBOM ile Nasıl Kullanılır?

Vulnerability Exploitability eXchange veya VEX, belirli bir ürünün bilinen bir güvenlik açığından etkilenip etkilenmediğini açıklayan makine tarafından işlenebilir güvenlik beyanıdır.

Neden VEX Gereklidir?

SBOM içerisinde bir bileşenin bulunması, bu bileşendeki her güvenlik açığının üründe sömürülebilir olduğu anlamına gelmez.

Örneğin:

• Etkilenen fonksiyon hiç çağrılmıyor olabilir.
• Güvenlik açığı oluşturan özellik derleme sırasında kapatılmış olabilir.
• Bileşen yalnızca test aşamasında kullanılmış olabilir.
• Ürünün çalışma ortamı saldırı yolunu engelliyor olabilir.
• Üretici açığı özel bir yama ile gidermiş olabilir.

Yaygın VEX Durumları

• Etkileniyor
• Etkilenmiyor
• Düzeltildi
• İnceleniyor

VEX beyanı, “etkilenmiyor” sonucunu gerekçesiyle beraber açıklamalıdır. Doğrulanmamış bir VEX kaydı güvenlik uyarısını görmezden gelmek için kullanılmamalıdır.

Yazılım Tedarik Zinciri Güvenliği İçin 8 Kritik SBOM Adımı

1. SBOM Kapsamını ve Sorumlusunu Belirleyin

İlk olarak hangi ürün, hizmet ve artefaktlar için SBOM oluşturulacağını belirleyin.

Kapsama Alınabilecek Varlıklar

• Web uygulamaları
• Mobil uygulamalar
• Masaüstü yazılımları
• API hizmetleri
• Konteyner imajları
• Firmware paketleri
• Dağıtım dosyaları
• Yapay zekâ uygulamaları
• Müşteriye teslim edilen özel yazılımlar

Her SBOM’un bir sahibi olmalıdır. Ürün ekibi, güvenlik ekibi ve DevOps ekibi arasındaki sorumluluklar yazılı hâle getirilmelidir.

Belirlenmesi Gerekenler

• SBOM’u hangi ekip üretecek?
• Hangi aşamada üretilecek?
• Hangi format kullanılacak?
• Kim doğrulayacak?
• Ne kadar süre saklanacak?
• Kimlerle paylaşılacak?
• Hatalı kayıtlar nasıl düzeltilecek?

2. SBOM’u CI/CD İçinde Otomatik Üretin

SBOM’un geliştirici tarafından elle hazırlanması ölçeklenebilir değildir. Üretim işlemi CI/CD hattına eklenmeli ve her sürüm için tekrarlanmalıdır.

Uygun Üretim Noktaları

• Bağımlılıkların çözümlenmesinden sonra
• Uygulama derlendikten sonra
• Konteyner imajı oluşturulduğunda
• İmzalı sürüm yayımlanmadan önce
• Uygulama mağazasına gönderilmeden önce

SBOM’un hangi kaynak üzerinden oluşturulduğu belgeye eklenmelidir. Kaynak kod taramasıyla üretilen liste ile dağıtılan konteynerin taranması aynı sonucu vermeyebilir.

3. Bileşenleri Benzersiz Tanımlayıcılarla Zenginleştirin

Yalnızca paket adı ve sürümü kullanmak eşleştirme hatalarına yol açabilir. Mümkün olduğunda PURL, CPE, dosya özeti ve ekosistem bilgisi ekleyin.

Kontrol Edilmesi Gerekenler

• Paket adı doğru mu?
• Sürüm tam olarak biliniyor mu?
• PURL geçerli mi?
• Dosya özeti dağıtılan artefaktla eşleşiyor mu?
• Tedarikçi bilgisi mevcut mu?
• Bileşenin kaynağı belli mi?
• Bağımlılık ilişkisi doğru mu?

“Unknown” veya bilinmiyor alanlarını sessizce kaldırmak yerine görünür şekilde kaydedin. Bilinmeyen bileşen, riskin olmadığı değil görünürlüğün eksik olduğu anlamına gelir.

4. SPDX veya CycloneDX Formatını Doğrulayın

SBOM dosyasının standart şemaya uygunluğunu otomatik olarak kontrol edin.

Doğrulama Aşamaları

• JSON veya XML sözdizimi kontrolü
• Standart şema doğrulaması
• Zorunlu alanların kontrolü
• Benzersiz referansların kontrolü
• Bağımlılık grafiğinin doğrulanması
• PURL ve lisans ifadelerinin kontrolü
• Desteklenmeyen sürüm kullanımının tespiti

SPDX 3.1-RC1 gibi sürüm adaylarını üretim standardı olarak kullanmadan önce alıcı ve analiz araçlarının desteklediğini doğrulayın.

5. SBOM’u Artefaktla İlişkilendirin ve İmzalayın

SBOM’un hangi yazılım sürümüne ait olduğu açık biçimde belirlenmelidir.

İlişkilendirilebilecek Veriler

• Git commit kimliği
• Sürüm etiketi
• Konteyner imaj özeti
• Kurulum paketi SHA-256 değeri
• Derleme numarası
• Yayımlanma zamanı
• Artefakt deposu konumu

SBOM’un dijital olarak imzalanması veya doğrulanabilir bir attestation içerisinde sunulması, belge ile yazılım artefaktı arasındaki güveni güçlendirir.

SBOM dosyasını yazılım paketinin yanına koymak tek başına bütünlüğü kanıtlamaz. Dosya sonradan değiştirilebiliyorsa imza ve erişim kayıtları gerekir.

6. Güvenlik Açığı ve VEX Verileriyle Eşleştirin

SBOM bileşenlerini güncel güvenlik açığı kaynaklarıyla düzenli olarak karşılaştırın.

Analizde Kullanılabilecek Bilgiler

• CVE kayıtları
• Üretici güvenlik duyuruları
• Ulusal güvenlik açığı veri tabanları
• Bilinen istismar katalogları
• EPSS benzeri istismar olasılığı verileri
• VEX belgeleri
• İç tehdit istihbaratı

Güvenlik açığı tespit edildiğinde yalnızca CVSS puanına bakmayın. Ürünün internete açıklığı, veri hassasiyeti ve aktif istismar durumu gibi unsurları da değerlendirin.

7. CI/CD Güvenlik Kapıları Oluşturun

SBOM analizi yalnızca rapor üretmemeli; belirlenen kurallar ihlal edildiğinde dağıtımı durdurabilmelidir.

Örnek Politika Kuralları

• Kritik güvenlik açığı bulunan sürüm dağıtılamaz.
• Lisansı bilinmeyen bileşen yayımlanamaz.
• Onaylanmamış paket deposundan bağımlılık indirilemez.
• SBOM üretilmeden sürüm etiketi oluşturulamaz.
• Bileşen özeti doğrulanmıyorsa dağıtım durdurulur.
• İzin verilmeyen lisans kullanan paket reddedilir.
• SBOM şema doğrulamasından geçmiyorsa sürüm yayımlanmaz.

Politikalar kuruluşun risk düzeyine göre hazırlanmalıdır. Bütün uyarıları aynı anda engellemek geliştiricilerin sistemi devre dışı bırakmaya çalışmasına neden olabilir.

8. SBOM’u Sürekli Güncelleyin ve Olay Müdahalede Kullanın

SBOM bir kez hazırlanıp unutulacak statik belge değildir. Her ürün sürümü ve önemli bağımlılık değişikliği için güncellenmelidir.

Yaşam Döngüsü İşlemleri

• Yeni sürümde yeniden SBOM oluşturmak
• Eski ürün sürümlerinin SBOM’larını saklamak
• Destek süresi biten ürünleri işaretlemek
• Yeni CVE kayıtlarında bütün SBOM deposunu taramak
• Müşterilere etki bildirimleri hazırlamak
• Yama sonrası yeni SBOM yayımlamak
• Yanlış bileşen kayıtlarını sürümlü biçimde düzeltmek

Olay müdahale ekibi, etkilenen paket adını veya PURL değerini kullanarak hangi ürün ve müşterilerin risk altında olduğunu sorgulayabilmelidir.

SBOM CI/CD Sürecine Nasıl Eklenir?

SBOM üretimi, yazılım teslim sürecinin otomatik bir parçası olmalıdır.

Örnek CI/CD Akışı

1. Geliştirici kod değişikliğini gönderir.
2. Bağımlılıklar güvenilir depolardan indirilir.
3. Kod ve bağımlılık güvenlik taraması çalıştırılır.
4. Uygulama derlenir.
5. Konteyner veya dağıtım paketi oluşturulur.
6. Kaynak ve artefakt tabanlı SBOM üretilir.
7. SBOM şeması doğrulanır.
8. Bileşenler güvenlik açığı ve lisans politikalarıyla karşılaştırılır.
9. Artefakt ve SBOM imzalanır.
10. Artefakt deposuna birlikte yüklenir.
11. Dağıtım ortamında özet değerleri doğrulanır.
12. SBOM merkezi envanter sistemine aktarılır.

Hangi Durumda Pipeline Durdurulmalıdır?

• SBOM üretilemediğinde
• SBOM dosyası standart doğrulamasından geçmediğinde
• Kritik bir bileşen kimliği belirlenemediğinde
• Yasaklı lisans bulunduğunda
• Aktif istismar edilen kritik bir güvenlik açığı bulunduğunda
• Artefakt ile SBOM özeti eşleşmediğinde
• İmza doğrulaması başarısız olduğunda

Geliştirici Deneyimini Korumak

Pipeline güvenlik kontrolü geliştiriciye yalnızca “başarısız” mesajı vermemelidir. Raporda aşağıdaki bilgiler bulunmalıdır:

• Hangi bileşen sorunlu?
• Hangi sürüm kullanılıyor?
• Bağımlılık doğrudan mı, geçişli mi?
• Hangi üst paket üzerinden geliyor?
• Güvenli sürüm var mı?
• Politika istisnası nasıl talep edilir?

Proje için kullanılacak teknoloji ve bağımlılıkların başlangıçta doğru seçilmesi için Doğru Teknoloji Yığını Nasıl Seçilir? içeriğimizi inceleyebilirsiniz.

Basitleştirilmiş CycloneDX SBOM Örneği

Aşağıdaki örnek öğretici amaçlı basitleştirilmiştir. Üretim ortamında güncel CycloneDX şeması ve kullanılan araç çıktısı doğrulanmalıdır.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:00000000-0000-4000-8000-000000000001",
  "version": 1,
  "metadata": {
    "timestamp": "2026-08-01T12:00:00Z",
    "component": {
      "type": "application",
      "name": "ornek-api",
      "version": "2.4.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "ornek-kutuphane",
      "version": "1.5.2",
      "purl": "pkg:npm/ornek-kutuphane@1.5.2",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "ORNEK_OZET_DEGERI"
        }
      ],
      "licenses": [
        {
          "license": {
            "id": "MIT"
          }
        }
      ],
      "bom-ref": "pkg:npm/ornek-kutuphane@1.5.2"
    }
  ],
  "dependencies": [
    {
      "ref": "ornek-api@2.4.0",
      "dependsOn": [
        "pkg:npm/ornek-kutuphane@1.5.2"
      ]
    }
  ]
}

Örnekteki Alanlar

• bomFormat: Kullanılan BOM standardı
• specVersion: CycloneDX sürümü
• serialNumber: SBOM belgesinin benzersiz kimliği
• metadata: Belge ve ana uygulama bilgileri
• components: Yazılım bileşenleri
• purl: Paket için standart tanımlayıcı
• hashes: Bileşen bütünlük değerleri
• licenses: Lisans bilgileri
• dependencies: Bileşenler arasındaki ilişkiler

Açık Kaynak Bağımlılıkları SBOM ile Nasıl Yönetilir?

SBOM’un önemli kullanım alanlarından biri açık kaynak bileşen yönetimidir.

Doğrudan ve Dolaylı Bağımlılıkları Ayırın

Doğrudan bağımlılık geliştiricinin proje dosyasına eklediği pakettir. Dolaylı bağımlılık ise bu paketin çalışmak için ihtiyaç duyduğu başka bileşendir.

Bir güvenlik açığını gidermek için bazen sorunlu paketi doğrudan yükseltmek mümkün olmaz. Açığı getiren üst bağımlılığın yeni sürümüne geçmek gerekebilir.

Kilit Dosyalarını Koruyun

Kilit dosyaları, derleme sırasında kullanılan kesin sürümlerin belirlenmesine yardımcı olur. Bu dosyaların sürüm kontrol sistemine dahil edilmesi ve izinsiz değişikliklerin incelenmesi gerekir.

Bağımlılık Sürümünü Sabitleyin

Aşırı geniş sürüm aralıkları, farklı derlemelerde farklı bağımlılıkların kullanılmasına neden olabilir. Tekrarlanabilir derleme için sürümler ve özet değerleri kontrol edilmelidir.

Kullanılmayan Bağımlılıkları Kaldırın

Her ek bileşen yeni bir güvenlik, lisans ve bakım yükü oluşturur. Kullanılmayan paketlerin düzenli olarak kaldırılması SBOM’u ve saldırı yüzeyini küçültür.

Paket Kaynağını Doğrulayın

• Resmî paket deposu kullanılıyor mu?
• Paket sahibi doğrulandı mı?
• Benzer isimli zararlı paket riski var mı?
• Paket özeti kontrol ediliyor mu?
• Kurumsal proxy veya paket deposu kullanılıyor mu?

Konteyner ve Kubernetes Ortamlarında SBOM

Konteyner imajları uygulama bağımlılıklarının yanında işletim sistemi paketlerini, çalışma zamanlarını ve araçları da içerebilir.

Konteyner SBOM’unda Bulunabilecekler

• Taban imaj ve özeti
• İşletim sistemi paketleri
• Uygulama kütüphaneleri
• Dil çalışma zamanı
• Web sunucusu
• Sertifika paketleri
• Komut satırı araçları
• İmaj katmanları

Yalnızca Etikete Güvenmeyin

latest gibi değişken imaj etiketleri belirli bir artefaktı güvenilir biçimde tanımlamaz. Konteyner imajı digest değeriyle SBOM’a bağlanmalıdır.

Her İmaj İçin Ayrı SBOM

Aynı uygulamanın geliştirme, test ve üretim imajları farklı paketler içerebilir. Üretimde kullanılan gerçek imaj için ayrı SBOM oluşturulmalıdır.

Çalışma Ortamında Doğrulama

Kubernetes admission politikaları, dağıtılan imajın imzasını ve SBOM veya attestation varlığını kontrol edecek şekilde yapılandırılabilir.

Dağıtım ve altyapı değişikliklerinin Git üzerinden yönetilmesini anlatan ilgili yaklaşım için Tekno Türkiye’deki GitOps içerikleriyle SBOM süreçleri birlikte değerlendirilebilir.

SaaS Ürünlerinde SBOM Kullanımı

SaaS ürünlerinde müşteriye doğrudan kurulum paketi verilmez. Ancak hizmetin arka planında kullanılan bileşenler yine tedarik zinciri riski taşır.

SaaS Ortamında İzlenebilecek Unsurlar

• Uygulama bileşenleri
• Konteyner imajları
• Çalışma zamanı paketleri
• Yönetilen veri tabanı sürümleri
• Dış API hizmetleri
• Kimlik doğrulama sağlayıcıları
• Mesajlaşma ve depolama hizmetleri
• İstemci tarafı JavaScript paketleri

SaaSBOM Kavramı

SaaSBOM, yalnızca yazılım paketlerini değil hizmet bağımlılıklarını ve hizmetler arasındaki veri akışlarını da görünür hâle getirmeyi amaçlar.

Müşteriye sunulacak SBOM kapsamı; güvenlik şeffaflığı ile mimari ve ticari gizlilik arasında dengelenmelidir.

Tedarikçilerden SBOM Nasıl İstenir?

Satın alma sözleşmesinde yalnızca “SBOM sağlanacaktır” ifadesinin bulunması yeterli olmayabilir.

Sözleşmede Belirlenebilecek Şartlar

• Kabul edilen format: SPDX veya CycloneDX
• Desteklenen standart sürümü
• Her ürün sürümünde güncelleme
• Doğrudan ve geçişli bağımlılıkların dahil edilmesi
• PURL ve özet değerlerinin bulunması
• SBOM’un imzalı veya doğrulanabilir olması
• Güvenli teslim yöntemi
• Hatalı kayıtların düzeltme süresi
• Kritik güvenlik açığı bildirim süresi
• VEX desteği
• Ürün desteği sona erdiğinde saklama süresi

Tedarikçiye Sorulabilecek Sorular

• SBOM hangi aşamada oluşturuluyor?
• Kaynak koddan mı, artefakttan mı üretiliyor?
• Dolaylı bağımlılıklar dahil mi?
• Bilinmeyen bileşenler nasıl gösteriliyor?
• SBOM ne sıklıkla güncelleniyor?
• Güvenlik açığı bulunduğunda VEX yayımlanıyor mu?
• Belge dijital olarak imzalanıyor mu?
• Ürün sürümüyle nasıl eşleştiriliyor?

Tedarikçi değerlendirmesinde SBOM’un bulunması olumlu bir işarettir, ancak şirketin güvenli geliştirme uygulamalarını tek başına kanıtlamaz.

Yeni Bir Güvenlik Açığında SBOM Nasıl Kullanılır?

Kritik bir kütüphanede yeni güvenlik açığı açıklandığında aşağıdaki olay müdahale süreci uygulanabilir.

1. CVE kaydı ve etkilenen sürüm aralığı doğrulanır.
2. Paket adı, PURL, CPE ve dosya özetleri belirlenir.
3. Merkezi SBOM deposunda bileşen aranır.
4. Etkilenen ürün ve sürümler listelenir.
5. Bağımlılığın doğrudan veya geçişli olduğu belirlenir.
6. Üretimde çalışan sistemler varlık envanteriyle eşleştirilir.
7. VEX ve üretici duyuruları incelenir.
8. Gerçek sömürülebilirlik değerlendirilir.
9. Yama, yükseltme veya geçici önlem planlanır.
10. Müşteri bildirimleri hazırlanır.
11. Düzeltme sonrasında yeni SBOM oluşturulur.
12. Eski ve yeni SBOM arasındaki fark doğrulanır.

Önceliklendirme Kriterleri

• Aktif istismar bulunması
• İnternete açık sistem
• Kimlik doğrulama gerektirmeyen saldırı
• Uzaktan kod çalıştırma riski
• Yüksek değerli veri veya sistem
• Kolay uygulanabilir güvenli sürüm bulunması
• Telafi edici kontrol bulunmaması

Lisans Uyumluluğu ve SBOM

SBOM, yazılım güvenliğinin yanında lisans uyumluluğu için de kullanılabilir.

İncelenebilecek Lisans Bilgileri

• Bileşenin beyan edilen lisansı
• Dosya seviyesinde tespit edilen lisans
• Birden fazla lisans seçeneği
• Lisans istisnaları
• Atıf ve bildirim yükümlülükleri
• Kaynak kod paylaşımı şartları
• Ticari kullanıma ilişkin sınırlamalar

Lisans Bilgisi Bilinmiyorsa

“NOASSERTION” veya bilinmeyen lisans kaydı otomatik olarak güvenli kabul edilmemelidir. Hukuk veya açık kaynak program ofisi tarafından inceleme yapılmalıdır.

SBOM, hukuki görüş yerine geçmez. Lisansın ürün dağıtım biçimine ve kullanım şekline etkisi uzmanlar tarafından değerlendirilmelidir.

SBOM Nasıl Saklanmalı ve Paylaşılmalı?

SBOM dosyaları herkesin erişebildiği rastgele bir klasörde tutulmamalıdır. Paylaşım seviyesi ürün ve risk sınıfına göre belirlenmelidir.

Saklama Gereksinimleri

• Sürümlü merkezi depo
• Değiştirilemez kayıt veya denetim izi
• Dijital imza doğrulaması
• Artefakt sürümüyle ilişkilendirme
• Rol tabanlı erişim kontrolü
• Yedekleme ve saklama politikası
• Aranabilir bileşen indeksi

Paylaşım Modelleri

• Ürün paketiyle beraber yayımlama
• Müşteri portalından indirme
• Kimlik doğrulamalı API üzerinden sunma
• Talep üzerine güvenli paylaşım
• Herkese açık proje deposunda yayımlama

SBOM İçine Gizli Bilgi Eklemeyin

SBOM aşağıdaki bilgileri içermemelidir:

• API anahtarları
• Parolalar
• Özel sertifika anahtarları
• Veri tabanı bağlantı bilgileri
• İç erişim belirteçleri
• Kişisel veriler

SBOM paylaşım süreçlerinin kişisel veri ve erişim kontrolü boyutu için Startuplar İçin KVKK Rehberi içeriğimizi inceleyebilirsiniz.

SBOM’un Sınırlamaları ve Riskleri

Eksik Bileşenler

Kullanılan araç belirli bir paket ekosistemini veya ikili dosyayı tanımayabilir. Eksik SBOM, saldırı yüzeyinin olduğundan küçük görünmesine neden olur.

Yanlış Pozitif Eşleştirmeler

Paket adı veya CPE eşleştirmesi hatalıysa ürün ilgisiz güvenlik açıklarıyla ilişkilendirilebilir.

Güncel Olmayan Belgeler

Eski sürüme ait SBOM’un yeni ürün için kullanılması yanlış güvenlik kararlarına yol açabilir.

Derleme ve Dağıtım Farkı

Kaynak kod tabanlı SBOM, son konteyner veya kurulum paketinde bulunan bütün dosyaları göstermeyebilir.

Hassas Mimari Bilgiler

Ayrıntılı SBOM, saldırgana kullanılan teknolojiler hakkında bilgi sağlayabilir. Bu durum SBOM’un hiç paylaşılmaması gerektiği anlamına gelmez; erişim modeli risk esaslı tasarlanmalıdır.

Araç Bağımlılığı

Tek üreticiye ait SBOM aracı, belirli bileşenleri yanlış veya eksik tespit edebilir. Kritik ürünlerde farklı yöntemlerle karşılaştırmalı doğrulama yapılabilir.

Yanlış Güven Duygusu

SBOM oluşturmak güvenli yazılım geliştirme çalışmalarının tamamlandığı anlamına gelmez. Kod incelemesi, güvenlik testi, sır taraması, erişim kontrolü ve güvenli yapılandırma yine gereklidir.

SBOM Kullanımında Sık Yapılan Hatalar

• SBOM’u elle hazırlamak
• Yalnızca doğrudan bağımlılıkları dahil etmek
• Geçişli bağımlılıkları görmezden gelmek
• Her sürüm için yeni SBOM oluşturmamak
• Kaynak SBOM’unu dağıtım SBOM’u sanmak
• Paket sürümlerini kesin biçimde belirtmemek
• PURL ve özet değerlerini eklememek
• Bilinmeyen bileşenleri listeden çıkarmak
• SBOM şemasını doğrulamamak
• Standart sürümünü belirtmemek
• SBOM’u artefaktla ilişkilendirmemek
• İmza veya bütünlük kontrolü kullanmamak
• SBOM’u güvenlik açığı kaynaklarıyla eşleştirmemek
• VEX olmadan bütün CVE kayıtlarını aynı önemde görmek
• Lisans bilgilerini kontrol etmemek
• SBOM içinde gizli bilgi bulundurmak
• Müşteriden alınan SBOM’u analiz etmeden arşivlemek
• Eski ürün sürümlerinin SBOM’larını silmek
• SBOM hatalarını düzeltecek süreç oluşturmamak
• SBOM’u tek başına güvenlik programı olarak görmek

SBOM Güvenlik Kontrol Listesi

SBOM Hakkında Güvenilir Teknik Kaynaklar

• CISA 2026 Minimum Elements for an SBOM
• NIST Software Supply Chain SBOM Guidance
• SPDX Specifications
• CycloneDX Specification Overview

SBOM Nedir? Sık Sorulan Sorular

SBOM nedir?

SBOM, bir yazılım ürününde kullanılan bileşenleri, sürümleri, tedarikçileri, lisansları ve bağımlılık ilişkilerini makine tarafından işlenebilir biçimde gösteren Yazılım Malzeme Listesidir.

SBOM açılımı nedir?

SBOM, Software Bill of Materials ifadesinin kısaltmasıdır.

SBOM Türkçesi nedir?

Türkçede genellikle Yazılım Malzeme Listesi veya Yazılım Bileşen Listesi ifadeleri kullanılır.

SBOM neden önemlidir?

Şirketlerin yazılımlarında hangi üçüncü taraf bileşenlerin bulunduğunu bilmesini, yeni güvenlik açıklarının etkisini daha hızlı araştırmasını ve lisans uyumluluğunu yönetmesini sağlar.

SBOM güvenlik açığı taraması yapar mı?

SBOM tek başına tarama yapmaz. Bileşen envanterini güvenlik açığı veri kaynaklarıyla karşılaştıran bir analiz aracı gerekir.

SBOM güvenli yazılım garantisi verir mi?

Hayır. SBOM bileşen şeffaflığı sağlar ancak uygulamanın kendi kodundaki, yapılandırmasındaki veya erişim kontrolündeki açıkları ortadan kaldırmaz.

SBOM hangi bilgileri içerir?

Bileşen adı, sürüm, tedarikçi, PURL, dosya özeti, lisans, bağımlılık ilişkisi, SBOM oluşturucusu ve zaman damgası gibi bilgiler içerebilir.

SPDX nedir?

SPDX, yazılım ve sistem bileşenleriyle ilgili BOM, lisans, güvenlik ve köken bilgilerinin ortak biçimde paylaşılmasını sağlayan açık standarttır.

CycloneDX nedir?

CycloneDX; bileşenler, hizmetler, bağımlılıklar, güvenlik açıkları ve VEX bilgileri için kullanılan modüler bir BOM standardıdır.

SPDX mi CycloneDX mi kullanılmalı?

Seçim müşteri gereksinimine, kullanılan araçlara, lisans ve güvenlik iş akışlarına bağlıdır. Kuruluşun tüketebildiği ve doğrulayabildiği format tercih edilmelidir.

SPDX ve CycloneDX aynı şey mi?

Hayır. İkisi de SBOM için kullanılabilen farklı veri modelleri ve standartlardır.

SBOM ve SCA aynı şey mi?

Hayır. SCA bileşenleri ve güvenlik açıklarını analiz eden süreç veya araçtır. SBOM ise bileşen envanterini taşıyan standartlaştırılmış çıktıdır.

VEX nedir?

VEX, belirli bir ürünün bilinen bir güvenlik açığından etkilenip etkilenmediğini ve bunun gerekçesini açıklayan makine tarafından işlenebilir güvenlik beyanıdır.

SBOM otomatik oluşturulabilir mi?

Evet. Paket yöneticileri, kaynak kod depoları, derleme sistemleri, ikili dosyalar ve konteyner imajları analiz edilerek CI/CD içinde otomatik oluşturulabilir.

SBOM ne zaman oluşturulmalıdır?

Her sürüm için derleme veya paketleme aşamasında oluşturulmalıdır. Kaynak kod ve dağıtılan artefakt için birden fazla SBOM türü üretilebilir.

Her sürüm için ayrı SBOM gerekir mi?

Evet. Bağımlılıklar ve dosyalar ürün sürümleri arasında değişebileceği için SBOM belirli bir sürüm ve artefaktla ilişkilendirilmelidir.

SBOM doğrudan bağımlılıkları mı gösterir?

İyi bir SBOM hem doğrudan hem de geçişli bağımlılıkları göstermelidir.

SBOM içerisinde lisans bilgisi bulunur mu?

SPDX ve CycloneDX lisans bilgilerinin temsil edilmesini destekler. Ancak lisans uyumluluğu ayrıca hukuki ve teknik inceleme gerektirir.

SBOM müşterilerle paylaşılmalı mı?

Paylaşım modeli ürünün niteliğine, sözleşmeye ve risk değerlendirmesine bağlıdır. Açık paylaşım, müşteri portalı veya kimlik doğrulamalı API kullanılabilir.

SBOM herkese açık olmalı mı?

Zorunlu değildir. Bazı açık kaynak projeler SBOM’u herkese sunarken kurumsal ürünler yalnızca yetkili müşterilerle paylaşabilir.

SBOM hassas bilgi içerir mi?

Teknoloji ve bileşen bilgileri mimari hakkında ayrıntı verebilir. Ancak SBOM içerisinde parola, API anahtarı, erişim belirteci veya özel anahtar bulunmamalıdır.

SBOM dijital olarak imzalanmalı mı?

İmzalama, SBOM’un kaynağını ve bütünlüğünü doğrulamaya yardımcı olur. Kritik tedarik zincirlerinde önerilen güçlü bir uygulamadır.

Konteyner imajları için SBOM gerekir mi?

Evet. Konteynerler işletim sistemi paketleri, dil kütüphaneleri ve çalışma zamanı bileşenleri içerdiği için her üretim imajı için SBOM oluşturulmalıdır.

SaaS ürünleri SBOM oluşturmalı mı?

SaaS ürünlerinde müşteriye paket teslim edilmese bile hizmeti oluşturan yazılım ve servis bağımlılıklarının görünür hâle getirilmesi güvenlik ve tedarikçi yönetimi açısından faydalıdır.

SBOM güvenlik olayında nasıl kullanılır?

Etkilenen bileşen merkezi SBOM deposunda aranarak hangi ürünlerin, sürümlerin ve müşterilerin risk altında olduğu belirlenebilir.

Küçük şirketlerin SBOM’a ihtiyacı var mı?

Açık kaynak bileşen kullanan, kurumsal müşterilere yazılım satan veya güvenlik açığı yönetimini hızlandırmak isteyen küçük şirketler de SBOM’dan yararlanabilir.

SBOM Nedir? Sonuç

SBOM nedir sorusunun temel cevabı; yazılım ürününü oluşturan birinci taraf, açık kaynak ve ticari bileşenleri sürümleri ve bağımlılık ilişkileriyle kaydeden makine tarafından işlenebilir Yazılım Malzeme Listesidir.

Modern yazılımlar çok sayıda doğrudan ve geçişli bağımlılık içerir. Bu bileşenlerin görünür olmaması, yeni bir güvenlik açığı açıklandığında hangi ürünlerin etkilendiğini belirlemeyi zorlaştırır.

SBOM; güvenlik açığı araştırması, lisans uyumluluğu, tedarikçi değerlendirmesi, müşteri talepleri ve olay müdahalesi için güçlü bir veri katmanı sağlar. Ancak güvenlik açığı taraması, güvenli kod incelemesi ve yama yönetiminin yerini tutmaz.

Başarılı bir SBOM programında kapsam ve sorumluluk belirlenmeli, SBOM CI/CD içerisinde otomatik üretilmeli ve bileşenler PURL, sürüm ve özet değerleriyle doğru biçimde tanımlanmalıdır.

SPDX veya CycloneDX gibi standart formatlar kullanılmalı, çıktı şema doğrulamasından geçirilmeli ve yazılım artefaktıyla açık biçimde ilişkilendirilmelidir.

SBOM’un dijital imza veya doğrulanabilir attestation ile korunması, belge ile dağıtılan ürün arasındaki güveni artırır. Yeni güvenlik açıkları için SBOM deposu sürekli taranmalı ve VEX bilgileriyle gerçek sömürülebilirlik değerlendirilmelidir.

CI/CD güvenlik kapıları kritik güvenlik açıklarını, bilinmeyen lisansları, doğrulanamayan bileşenleri ve eksik SBOM dosyalarını dağıtımdan önce durdurabilir.

SBOM statik bir belge olarak görülmemelidir. Her ürün sürümünde yeniden oluşturulmalı, eski sürümlerin belgeleri saklanmalı ve olay müdahale süreçlerinde aranabilir bir envanter olarak kullanılmalıdır.

Doğru kapsam, güvenilir otomasyon ve sürekli analizle SBOM; şirketlerin yazılım tedarik zincirlerini anlamasına, açık kaynak risklerini daha hızlı yönetmesine ve müşterilerine daha şeffaf yazılım ürünleri sunmasına yardımcı olur.

Kimlik doğrulama güvenliğini geliştirmek için hazırladığımız Passkey Nedir? içeriğini ve genel güvenlik yaklaşımı için Siber Güvenlikte Endüstriyel Kontrollerin Önemi yazısını da inceleyebilirsiniz.