Modern bir yazılım yalnızca ekibinizin yazdığı kaynak koddan oluşmaz. Paket yöneticisinden indirilen kütüphaneler, framework bileşenleri, container taban imajları, üçüncü taraf SDK'lar ve bunların transit bağımlılıkları çalıştırılan ürünün parçasıdır. Bir güvenlik açığı veya lisans sorunu duyurulduğunda ilk ihtiyaç, “Bu bileşen bizde var mı ve hangi sürümde kullanılıyor?” sorusuna güvenilir biçimde cevap verebilmektir.
SBOM, bu soruya cevap verebilmek için yazılımın bileşenlerini ve aralarındaki tedarik zinciri ilişkilerini yapılandırılmış biçimde kaydeder. Kısaltma, Software Bill of Materials ifadesinden gelir. Türkçede yazılım malzeme listesi veya yazılım bileşen envanteri olarak açıklanabilir. Ancak SBOM'u yalnızca paket adlarının bulunduğu statik bir Excel tablosu gibi düşünmek eksik olur; iyi bir SBOM belirli bir ürünün belirli bir sürümüne bağlanır, makine tarafından işlenebilir ve bağımlılık ilişkilerini gösterir.
SBOM tam olarak hangi problemi çözer?
Yazılım ekipleri çoğu zaman doğrudan kullandıkları paketleri bilir. Buna karşılık bir paketin kendi içinde getirdiği ikinci, üçüncü veya daha derin seviyedeki bağımlılıklar kolayca gözden kaçabilir. Ürün birkaç yıl boyunca güncellendiğinde hangi sürümün hangi bileşenlerle derlendiğini yalnızca güncel kaynak kod deposuna bakarak anlamak da mümkün olmayabilir.
NTIA, SBOM'u yazılımı oluşturmakta kullanılan bileşenlerin ayrıntılarını ve tedarik zinciri ilişkilerini içeren resmi bir kayıt olarak tanımlar NTIA SBOM Minimum Elements. Bu kayıt üç temel görünürlük sağlar:
- Ürün görünürlüğü: Teslim edilen yazılımın içinde hangi bileşenlerin bulunduğu anlaşılır.
- Sürüm görünürlüğü: Aynı bileşenin hangi sürümünün hangi ürün sürümünde kullanıldığı görülebilir.
- İlişki görünürlüğü: Bir bileşenin doğrudan mı yoksa başka bir paketin transit bağımlılığı olarak mı geldiği belirlenebilir.
- Kaynak görünürlüğü: Bileşenin tedarikçisi, paket ekosistemi ve benzersiz tanımlayıcıları kaydedilebilir.
- Operasyon görünürlüğü: Yeni bir güvenlik veya lisans olayı çıktığında etkilenen ürün sürümleri daha hızlı sorgulanabilir.
SBOM'un en önemli değeri “bütün yazılımlarımız güvenli” demesi değil, bir olay ortaya çıktığında neyin incelenmesi gerektiğini gösterecek güvenilir bir envanter sunmasıdır.
Bu görünürlük özellikle müşteriye özel platformlar, uzun süre yaşayan kurumsal uygulamalar ve birden fazla entegrasyon içeren sistemler için önemlidir. Özel web yazılımı geliştirilirken bileşen envanteri sürüm teslim sürecinin parçası yapılırsa, bakım döneminde yalnızca hatırlanan bağımlılıklara güvenilmez.
Bir SBOM içinde hangi bilgiler bulunmalıdır?
SBOM standardı ve kullanım amacı ayrıntı seviyesini değiştirebilir. Bununla birlikte bir bileşenin yalnızca adını yazmak çoğu güvenlik ve uyumluluk senaryosu için yeterli değildir. Aynı ada sahip farklı paketler bulunabilir; sürüm bilgisi olmadan güvenlik duyurusuyla eşleştirme yapılamaz; bağımlılık ilişkisi bilinmezse bileşenin ürüne nasıl girdiği anlaşılamaz.
NTIA'nın 2021 tarihli minimum öğeleri; veri alanları, otomasyon desteği ve uygulama süreçleri olmak üzere üç ana gruba ayrılır. CISA'nın SBOM çalışmaları da yazılım tedarik zinciri şeffaflığını geliştirmek için bu temel üzerinde ilerler CISA SBOM Kaynakları.
| Bilgi alanı | Neyi açıklar? | Sade örnek |
|---|---|---|
| Bileşen tedarikçisi | Paketi veya bileşeni sağlayan kuruluşu belirtir. | Bir açık kaynak topluluğu ya da yazılım üreticisi |
| Bileşen adı | Envanterdeki parçanın tanınmasını sağlar. | Bir HTTP istemci kütüphanesi |
| Sürüm | Güvenlik ve uyumluluk kontrollerinin doğru sürüme uygulanmasını sağlar. | 4.2.1 |
| Benzersiz tanımlayıcı | Aynı isimli paketleri ve farklı ekosistemleri ayırmaya yardım eder. | Package URL veya standardın kullandığı kimlik |
| Bağımlılık ilişkisi | Hangi bileşenin hangisine bağlı olduğunu gösterir. | Uygulama → SDK → yardımcı kütüphane |
| SBOM üreticisi | Envanteri oluşturan kişi, kuruluş veya aracı açıklar. | CI/CD içindeki SBOM üretim aracı |
| Zaman damgası | SBOM'un ne zaman ve hangi sürüm bağlamında üretildiğini gösterir. | Yayın derlemesinin tarihi |
| Hash ve lisans gibi ek alanlar | Bileşen bütünlüğü ve kullanım koşulları için daha güçlü bağlam sağlar. | SHA-256 değeri ve SPDX lisans ifadesi |
CISA'nın 2025 tarihli minimum öğeler güncelleme taslağı; component hash, lisans, kullanılan araç ve üretim bağlamı gibi alanları daha görünür hale getirmiştir CISA 2025 SBOM Minimum Elements. Bu dokümanın düzenleyici zorunluluk gibi yorumlanmaması gerekir; kuruluşun tabi olduğu sözleşme ve sektör gereksinimleri ayrıca incelenmelidir.
SBOM güvenlik açığı raporu mudur?
Hayır. SBOM, bileşen envanteridir; güvenlik açığı tarayıcısı veya risk kararı değildir. Bir SBOM'da belirli bir paket sürümünün bulunduğunu görmek, o ürünün otomatik olarak istismar edilebilir olduğu anlamına gelmez. Güvenlik duyurusu ilgili kod yolunu, yapılandırmayı, platformu veya derleme seçeneğini etkilemiyor olabilir. Tersi de mümkündür: eksik veya eski SBOM, gerçekten kullanılan savunmasız bileşeni göstermeyebilir.
| Artefakt | Temel sorusu | Tek başına cevaplayamadığı soru |
|---|---|---|
| SBOM | Yazılımın içinde hangi bileşenler var? | Bu bileşen mevcut üründe gerçekten istismar edilebilir mi? |
| Güvenlik açığı taraması | Envanterdeki bileşenler bilinen açıklarla eşleşiyor mu? | Eşleşmenin gerçek kullanım bağlamındaki etkisi nedir? |
| VEX | Belirli bir açık ürün için etkileniyor, etkilenmiyor veya inceleniyor mu? | Üründeki tüm bileşenlerin eksiksiz envanteri nedir? |
| Lisans analizi | Bileşenlerin lisansları ve yükümlülükleri nelerdir? | Ürünün teknik saldırı yüzeyi nedir? |
Bu nedenle olgun süreç, SBOM'u güvenlik açığı veri kaynakları, VEX bilgisi, ürünün çalışma bağlamı ve insan değerlendirmesiyle birlikte kullanır. NIST, tedarikçilerden alınan SBOM'ların minimum öğeleri karşılamasının ve verinin sürekli zenginleştirilmesinin değerlendirilmesini önerir NIST Software Supply Chain SBOM Guidance.
Somut örnek: Yeni bir güvenlik duyurusunda SBOM nasıl kullanılır?
Bir e-ticaret uygulamasının doğrudan bir ödeme SDK'sı, görsel işleme kütüphanesi ve web framework kullandığını düşünelim. Ödeme SDK'sı kendi içinde bir HTTP kütüphanesi; görsel işleme paketi ise ayrı bir dosya ayrıştırma bileşeni getiriyor. Ekip kaynak kodunda yalnızca doğrudan üç bağımlılığı görürken SBOM transit bileşenleri de ilişki grafiğinde gösterir.
| Envanter kaydı | Bağımlılık türü | SBOM'daki ilişki | Olay anındaki kullanım |
|---|---|---|---|
| Web framework 8.4 | Doğrudan | E-ticaret uygulamasının bileşeni | Duyurudaki etkilenen sürüm aralığıyla karşılaştırılır. |
| Ödeme SDK 3.1 | Doğrudan | E-ticaret uygulamasının bileşeni | SDK'nın kendisi ve transit bağımlılıkları sorgulanır. |
| HTTP kütüphanesi 2.7 | Transit | Ödeme SDK tarafından kullanılıyor | Ürüne hangi yol üzerinden girdiği belirlenir. |
| Görsel işleme paketi 5.0 | Doğrudan | E-ticaret uygulamasının bileşeni | Yüklenen dosya türleri ve çalışan kod yolları incelenir. |
| Dosya ayrıştırıcı 1.9 | Transit | Görsel işleme paketi üzerinden geliyor | Açığın gerçek ürün yapılandırmasında tetiklenebilirliği araştırılır. |
- Güvenlik duyurusundaki paket kimliği ve etkilenen sürüm aralığı çıkarılır.
- Yayındaki her ürün sürümünün SBOM'u makine tarafından sorgulanır.
- Eşleşen bileşenin doğrudan mı transit mi olduğu ve hangi paket yoluyla geldiği belirlenir.
- Uygulamanın ilgili kodu veya özelliği kullanıp kullanmadığı incelenir.
- Etkileniyorsa üst paketin veya transit bağımlılığın güvenli sürümüne geçiş planlanır.
- Yeni derleme üretilir ve aynı yayın için yeni SBOM oluşturulur.
- Eski ve yeni SBOM karşılaştırılarak hedeflenen bileşenin gerçekten değiştiği doğrulanır.
- Gerekliyse müşteri, operasyon ve güvenlik ekipleriyle etki durumu paylaşılır.
SBOM bulunmadığında ekip her repository'yi, container'ı ve teslim edilen eski sürümü ayrı ayrı incelemek zorunda kalabilir. Envanter güncelse ilk tarama otomatikleştirilebilir ve insan zamanı gerçekten eşleşen ürünlerin etki analizine ayrılır.
SPDX ve CycloneDX arasındaki fark nedir?
SPDX ve CycloneDX, SBOM bilgisini standartlaştırılmış ve makine tarafından okunabilir biçimde aktarmak için yaygın kullanılan iki açık standarttır. Seçim, “hangisi mutlak olarak daha iyi?” sorusundan çok mevcut araç zinciri, müşteri talebi, lisans ve güvenlik kullanım senaryoları ile uyumluluk üzerinden yapılmalıdır.
| Kriter | SPDX | CycloneDX |
|---|---|---|
| Konumlandırma | Yazılım, lisanslama, güvenlik ve farklı BOM alanlarını kapsayan açık standarttır. | Tedarik zinciri şeffaflığı ve siber risk kullanım alanlarına odaklanan modüler BOM standardıdır. |
| Standart durumu | ISO/IEC 5962:2021 olarak tanınır; SPDX sitesinde güncel ana sürüm 3.0 olarak listelenir. | OWASP ve Ecma International çatısı altında geliştirilir; güncel sürüm 1.7 olarak yayımlanmıştır. |
| Temsil kabiliyeti | Paketler, dosyalar, snippet'ler, lisans ve ilişki verileri gibi kapsamlı model sunar. | Bileşen, servis, dependency graph, vulnerability, composition ve formulation gibi nesneler sunar. |
| Format seçimi | Sürüm ve profile göre farklı serileştirme seçenekleri bulunur. | JSON, XML ve Protocol Buffers desteği sağlar. |
| Seçim yaklaşımı | Kuruluşun mevcut SPDX araçları, lisans süreçleri veya müşteri formatı varsa uygundur. | Uygulama güvenliği ve CycloneDX tabanlı araçlarla entegrasyon öncelikliyse uygundur. |
SPDX, uluslararası açık standart olarak ISO/IEC 5962:2021'e dayanır ve resmi sitesinde güncel ana belge sürümü 3.0 olarak gösterilir SPDX Specifications. CycloneDX'in resmi teknik görünümü ise 1.7 sürümünde bileşenleri, servisleri, doğrudan ve transit dependency ilişkilerini, composition bilgisini ve vulnerability/VEX kullanım alanlarını destekler CycloneDX Specification Overview.
Bir kuruluş iki formatı da tüketmek zorunda kalabilir. Bu durumda kurum içinde tek bir veri modeline dönüştürme, schema doğrulama ve kaynak formatı koruma yaklaşımı belirlenmelidir. Format dönüşümü yapıldığında her standardın bütün alanlarının birebir karşılığı olmayabileceği unutulmamalıdır.
SBOM hangi aşamada ve nasıl üretilmelidir?
En güvenilir SBOM, yazılımın yayınlanacak artefaktıyla aynı CI/CD çalışmasında oluşturulur. Kaynak kod deposunu aylar sonra taramak, teslim edilen binary veya container içinde gerçekten ne bulunduğunu kesin olarak göstermeyebilir. Derleme aşamasında kullanılan kilit dosyaları, paket metadata'sı, container katmanları ve ortaya çıkan artefakt birlikte incelenmelidir.
- Kaynak aşaması: Manifest ve lock dosyalarından planlanan bağımlılıklar çıkarılır.
- Build aşaması: Derleme sırasında çözümlenen gerçek bileşenler ve sürümler kaydedilir.
- Container aşaması: Uygulama paketlerine ek olarak işletim sistemi paketleri ve taban imaj bileşenleri taranır.
- Yayın aşaması: SBOM, ürün adı, sürüm ve artefakt hash'iyle ilişkilendirilir.
- Dağıtım aşaması: Müşteri veya iç sistemlere uygun erişim kontrolüyle sunulur.
- Operasyon aşaması: Yeni güvenlik duyuruları için SBOM deposu sürekli sorgulanır.
SBOM üretimi yazılım geliştirme hattına eklendiğinde her sürüm için tekrarlanabilir hale gelir. Manuel olarak yılda bir kez oluşturulan envanter, sık yayın yapan bir sistemde hızla geçerliliğini kaybeder. SBOM dosyası ürün artefaktından ayrı güncellenmemeli; yeni build yeni SBOM üretmelidir.
SBOM tüketimi üretmek kadar neden önemlidir?
Bir klasörde binlerce SBOM dosyası biriktirmek risk yönetimi değildir. Dosyaların doğrulanması, indekslenmesi, ürün ve sürümle ilişkilendirilmesi, güvenlik verileriyle eşleştirilmesi ve sorumlu ekiplere aksiyon üretmesi gerekir. CISA, NSA ve ODNI tarafından hazırlanan tüketim rehberi; standart veri formatlarının, otomatik değişimin, araç entegrasyonunun ve operasyonel süreçlerin birlikte kurulması gerektiğini vurgular CISA SBOM Consumption Guide.
Üretici ekip için kullanım
- Yeni güvenlik duyurusunun hangi ürün sürümlerini etkilediğini araştırmak.
- Sürüm yükseltmesinde eklenen ve kaldırılan bileşenleri karşılaştırmak.
- Destek süresi bitmiş bağımlılıkları belirlemek.
- Üçüncü taraf lisans yükümlülüklerini incelemek.
- Müşteriye teslim edilen sürümün bileşen kaydını korumak.
Yazılım satın alan kuruluş için kullanım
- Tedarikçinin sunduğu SBOM'un beklenen format ve minimum alanları taşıdığını doğrulamak.
- Kurum genelinde aynı kritik bileşeni kullanan farklı ürünleri bulmak.
- Desteklenmeyen veya kurum politikasına uymayan paketleri işaretlemek.
- Tedarikçiden güvenlik açığı değerlendirmesi ve güncelleme takvimi istemek.
- SBOM'un hangi ürün sürümüne ve hangi tarihteki build'e ait olduğunu kontrol etmek.
SBOM kullanımında en sık yapılan hatalar
- Yalnız doğrudan bağımlılıkları listelemek: Transit paketler görünmez kalır.
- SBOM'u ürün sürümüne bağlamamak: Envanterin hangi teslimatı temsil ettiği anlaşılamaz.
- Her yayında yeniden üretmemek: Dosya hızla güncelliğini kaybeder.
- Container taban imajını dışarıda bırakmak: İşletim sistemi paketleri görünmez olur.
- Schema doğrulaması yapmamak: Dosya standarda benzer görünse de araçlar tarafından işlenemeyebilir.
- Paket kimliğini yalnız isimle tutmak: Farklı ekosistemlerdeki aynı adlı bileşenler karışabilir.
- Her güvenlik eşleşmesini kesin etkilenme saymak: Gereksiz acil durum ve yanlış öncelik oluşturur.
- SBOM'u herkese sınırsız açmak: Şeffaflık ihtiyacı ile ticari ve güvenlik hassasiyeti dengelenmelidir.
- Dosya üretip tüketim süreci kurmamak: Yeni açık duyurusunda kimsenin SBOM'u sorgulamadığı bir arşiv oluşur.
SBOM programı başlatmak için kontrol listesi
- Hangi ürünlerin, container'ların ve dağıtım paketlerinin kapsamda olduğunu belirleyin.
- Her ürün için kimlik, sürüm ve artefakt adlandırma standardı oluşturun.
- Müşteri, sektör veya iç araç gereksinimine göre SPDX ya da CycloneDX formatını seçin.
- Kullandığınız dil, package manager ve container sistemini destekleyen üretim aracını değerlendirin.
- SBOM'u CI/CD içinde yayın artefaktıyla aynı build'de üretin.
- Doğrudan ve transit bağımlılıkların kapsandığını test edin.
- Çıktıyı standardın resmi schema veya doğrulama araçlarıyla kontrol edin.
- SBOM dosyasını ürün sürümü, build zamanı ve artefakt hash'iyle ilişkilendirin.
- Dosyaları erişim kontrollü ve sorgulanabilir merkezi depoda saklayın.
- Güvenlik açığı ve lisans verileriyle otomatik eşleştirme süreci kurun.
- Yeni eşleşmeler için sahip, öncelik ve yanıt süresi tanımlayın.
- Yanlış pozitif ve etkilenmeme kararlarını kayıt altına alın.
- Tedarikçilerden alınan SBOM'lar için kalite ve güncellik kontrolleri belirleyin.
- Her yayın sonrası SBOM farklarını gözden geçirerek beklenmeyen bileşenleri araştırın.
Sonuç: Bilmediğiniz bileşeni yönetemezsiniz
SBOM, yazılımın içindeki birinci taraf ve üçüncü taraf bileşenleri görünür hale getiren yapılandırılmış envanterdir. En güçlü kullanım alanı, yeni bir güvenlik veya lisans olayı çıktığında ürün sürümlerini hızlı biçimde sorgulamak, etkilenen bağımlılık yolunu bulmak ve güncellemenin gerçekten uygulandığını doğrulamaktır.
Değerli bir SBOM; otomatik üretilir, standarda uygun doğrulanır, yayın artefaktına bağlanır, transit bağımlılıkları kapsar ve operasyon ekipleri tarafından aktif olarak tüketilir. Dosya üretmek başlangıçtır; yazılım envanterini güvenlik, bakım ve tedarikçi yönetimi süreçlerine bağlamak ise gerçek sonuçtur.
Sıkça Sorulan Sorular
SBOM sadece açık kaynak bileşenleri mi listeler?
Hayır. SBOM birinci taraf, açık kaynak ve ticari üçüncü taraf bileşenleri temsil edebilir. Kapsam; kullanılan standarda, üretim aracına ve kuruluşun paylaşım politikasına göre değişir. Önemli olan yalnızca açık kaynak paketlerini saymak değil, teslim edilen ürünün içindeki bileşenleri ve ilişkileri doğru biçimde göstermektir. Ticari bileşenlerde lisans ve gizlilik kısıtları bulunuyorsa SBOM'un kimlerle ve hangi ayrıntı düzeyinde paylaşılacağı ayrıca yönetilmelidir.
SBOM oluşturmak yazılımı güvenli hale getirir mi?
Tek başına hayır. SBOM, yazılım güvenliği kontrolü değil bileşen görünürlüğü sağlar. Güncel olmayan bağımlılıkların yükseltilmesi, güvenlik testleri, kod incelemesi, güvenli build, artefakt imzalama, erişim kontrolü ve olay müdahalesi ayrıca yürütülmelidir. SBOM'un katkısı, yeni bir güvenlik duyurusunda hangi ürün ve sürümlerin inceleneceğini hızla belirlemek ve düzeltme sonrası bileşen değişikliğini doğrulamaktır.
SBOM ile güvenlik açığı taraması arasındaki fark nedir?
SBOM, üründeki bileşenlerin adı, sürümü, tanımlayıcısı ve bağımlılık ilişkisini kaydeder. Güvenlik açığı taraması ise bu envanteri veya doğrudan artefaktı bilinen güvenlik verileriyle eşleştirir. Eşleşme bulunması ürünün kesin olarak istismar edilebilir olduğunu göstermez; çalışma bağlamı ve ilgili kod yolunun kullanımı incelenmelidir. Eksik SBOM da kullanılan savunmasız bileşenin bulunamamasına neden olabilir.
SPDX mi CycloneDX mi kullanılmalı?
Seçim mevcut araç zinciri, müşteri beklentisi, sektör gereksinimleri ve kullanım senaryosuna göre yapılmalıdır. SPDX; yazılım, lisans ve farklı tedarik zinciri artefaktları için geniş bir model ve uluslararası standart konumu sunar. CycloneDX ise uygulama güvenliği, dependency graph, servisler, vulnerability ve VEX gibi alanlarda güçlü bir ekosisteme sahiptir. Kuruluşlar farklı tedarikçilerden iki formatı da tüketmek zorunda kalabilir.
SBOM ne zaman yeniden oluşturulmalıdır?
Ürünün bileşenlerini değiştirebilecek her yeni build veya sürümde SBOM yeniden oluşturulmalıdır. Paket güncellemesi, lock dosyası değişikliği, container taban imajı yenilemesi veya build ortamındaki çözümleme sonucu farklı bileşenler ortaya çıkabilir. En doğru yaklaşım, SBOM üretimini CI/CD hattına eklemek ve dosyayı aynı build'in ürün sürümü ve artefakt hash'iyle ilişkilendirmektir. Manuel ve seyrek üretim hızla eski envanter oluşturur.
SBOM müşterilerle açık biçimde paylaşılmalı mı?
Her durumda herkese açık paylaşım zorunlu değildir. Paylaşım modeli sözleşme, sektör gereksinimi, müşteri riski, ticari hassasiyet ve erişim ihtiyacına göre belirlenmelidir. Bazı kuruluşlar SBOM'u müşteri portalı veya kimliği doğrulanmış API üzerinden sunabilir; bazıları talep üzerine paylaşabilir. Dosyanın hangi ürün sürümüne ait olduğu, ne kadar güncel olduğu ve değişikliklerin nasıl bildirileceği açıkça tanımlanmalıdır.
