SBOM nedir? Firmware ekipleri için yazılım malzeme listesi

01Kısa cevap

SBOM (Software Bill of Materials, yazılım malzeme listesi), bir yazılımın ya da firmware'in içindeki bileşenlerin makinece okunabilir listesidir: hangi açık kaynak kütüphaneler var, sürümleri ne, kimden geliyorlar ve birbirlerine nasıl bağlılar. Yeni bir zafiyet duyurulduğunda "bu kütüphane hangi ürünümüzde, hangi sürümde var?" sorusunu dakikalar içinde cevaplamanızı sağlar. CRA, AB pazarına sunulan dijital unsurlu ürünler için SBOM hazırlamayı zorunlu tutuyor.

Fabrikadaki malzeme listesinin yazılımdaki karşılığı gibi düşünebilirsiniz. Tek fark, yazılım bileşenlerinin her sürümde değişmesi. Bu yüzden SBOM bir kere yazılıp dosyalanan bir belge değil, her firmware derlemesiyle yeniden üretilen bir çıktıdır.

02SBOM'da neler olur?

Biçim ne olursa olsun, işe yarar bir SBOM her bileşen için aşağı yukarı aynı bilgileri taşır:

• Ad ve sürüm: openssl ve 3.0.13 gibi. Sürümü olmayan bir kayıt zafiyet eşleştirmesinde ya hiç sonuç vermez ya da kütüphanenin bütün geçmişini getirir.
• Tedarikçi: bileşeni geliştiren ya da size veren taraf. Açık kaynakta çoğunlukla proje, kapalı kodda SDK'yı veren firma.
• Tekil tanımlayıcılar: PURL (pkg:generic/openssl@3.0.13) ve CPE. Zafiyet veritabanları bileşeni isimden değil bu anahtarlardan tanır.
• Özet (hash): dosyanın SHA-256 ya da SHA-512 özeti. Listedeki kaydın imajdaki dosyayla aynı olduğunu kanıtlar.
• Bağımlılık ilişkisi: hangi bileşenin hangisini kullandığı. Bir zafiyetin ürüne nereden girdiğini buradan izlersiniz.

Bir router firmware'i için kısaltılmış bir CycloneDX örneği. Gerçek dosyada yüzlerce bileşen olur; özet değeri burada kısaltıldı:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "component": { "bom-ref": "fw", "type": "firmware",
                   "name": "router-fw", "version": "2.4.1" }
  },
  "components": [
    { "bom-ref": "busybox", "type": "application",
      "name": "busybox", "version": "1.36.1",
      "purl": "pkg:generic/busybox@1.36.1" },
    { "bom-ref": "openssl", "type": "library",
      "name": "openssl", "version": "3.0.13",
      "cpe": "cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*",
      "hashes": [{ "alg": "SHA-256", "content": "…" }] }
  ],
  "dependencies": [{ "ref": "fw", "dependsOn": ["busybox", "openssl"] }]
}

metadata.component ürünün kendisi, yani firmware. dependencies bölümü firmware'in busybox ve openssl'e dayandığını söylüyor. openssl için CPE, busybox için PURL yazdık; pratikte ikisini birden yazmak eşleştirme oranını artırır.

03SPDX ve CycloneDX

İki biçim de olgun ve ikisi de CRA'nın "yaygın kullanılan, makinece okunabilir biçim" şartını karşılıyor. Hangisini seçeceğinizi çoğu zaman müşterinizin ya da kullandığınız araçların beklentisi belirler; birinden diğerine dönüştüren araçlar da var.

Dosya adına bakarak hangisi olduğunu çoğu zaman anlayabilirsiniz: SPDX JSON dosyaları genellikle *.spdx.json ile biter (Microsoft'un sbom-tool aracının ürettiği manifest.spdx.json gibi), CycloneDX dosyaları ise bom.json, bom.xml ya da *.cdx.json adını taşır.

04Gömülü cihazlarda SBOM neden zor?

Bir web uygulamasında SBOM'u kilit dosyasından (package-lock.json, poetry.lock) çıkarmak kolaydır, çünkü bağımlılıklar zaten bir dosyada yazılıdır. Firmware'de bu dosya ya yoktur ya da gerçeğin yalnız bir kısmını anlatır.

• Önemli olan kaynak değil, çıktı. Sahaya giden şey derlenmiş imajdır. Derleme sırasında bir yama uygulanmış, bir özellik kapatılmış ya da bir paket imaja hiç girmemiş olabilir. Kaynak ağacından çıkan liste ile imajdaki gerçek bu yüzden ayrışır. Yocto'nun imaj manifest'i ya da Buildroot'un make legal-info çıktısı iyi bir başlangıçtır, çünkü imaja giren paketleri listeler.
• Statik bağlanmış kütüphaneler. Bir servise statik bağlanmış mbedTLS ya da zlib, dosya sisteminde ayrı bir dosya olarak durmaz ve paket listesinde de görünmez. Ama zafiyeti ürünle birlikte sahaya çıkar. Bulmak için ikili analizi gerekir: sürüm dizgileri, bilinen fonksiyonların imzaları.
• RTOS ve SDK bileşenleri. Mikrodenetleyici firmware'inde paket yöneticisi yoktur. RTOS çekirdeği, TCP/IP yığını, TLS kütüphanesi ve üreticinin HAL'i kaynak olarak projeye kopyalanır ve tek bir ikiliye derlenir. Sürüm bilgisi çoğu zaman bir başlık dosyasında ya da birinin commit mesajında kalır.
• Tedarikçiden gelen kapalı kod. Wi-Fi sürücüsü, Bluetooth yığını ya da modem firmware'i size ikili olarak gelir. İçinde ne olduğunu yalnız tedarikçi bilir. Tedarikçiden makinece okunabilir bir SBOM istemek bu yüzden satın alma sözleşmesine yazılması gereken bir madde haline geliyor.

Pratikte en sağlam sonuç iki kaynağı birleştirince çıkıyor: derleme sisteminin bildiği paketler ve imajın ikili analiziyle bulunanlar. Biri, diğerinin kaçırdığını yakalar.

05CRA ne istiyor?

Yönetmelik SBOM'u Madde 3(39)'da, dijital unsurlu ürünün yazılım unsurlarındaki bileşenlerin ayrıntılarını ve tedarik zinciri ilişkilerini içeren resmî kayıt olarak tanımlıyor. Asıl yükümlülük Ek I Bölüm II(1)'de: üretici ürünündeki zafiyetleri ve bileşenleri tanımlayıp belgeler, bunun için de en azından üst düzey bağımlılıkları kapsayan, yaygın kullanılan ve makinece okunabilir bir biçimde SBOM hazırlar.

• SBOM teknik dokümantasyonun bir parçasıdır (Ek VII, 2(b)).
• Piyasa gözetim otoritesi, Ek I'e uygunluğu kontrol etmek için gerekliyse gerekçeli bir taleple SBOM'u isteyebilir (Ek VII, 8).
• Kamuya açıklama zorunluluğu yoktur; Gerekçe 77 bunu açıkça söyler. Kullanıcılara açmayı seçerseniz, kullanıcı bilgilerinde nereden erişilebileceğini belirtirsiniz (Ek II, 9).
• Yönetmelik belirli bir biçimin adını vermez. Madde 13(24), Komisyon'a SBOM'un biçimini ve unsurlarını uygulama tüzüğüyle belirleme yetkisi tanır.
• Bu yükümlülük, Yönetmeliğin tamamıyla birlikte 11 Aralık 2027'den itibaren uygulanır.

BSI TR-03183-2 daha fazlasını bekliyor

Almanya'nın federal bilgi güvenliği kurumu BSI'nin teknik kılavuzu TR-03183-2, CRA'daki "en azından üst düzey" ifadesinin çok ötesine geçiyor. Ağustos 2025 tarihli 2.1.0 sürümüne göre:

• Yeni üretilen SBOM, JSON ya da XML olarak CycloneDX 1.6 veya üstü, ya da SPDX 3.0.1 veya üstü olmalı.
• Bağımlılıklar, teslim kapsamındaki her yol boyunca özyinelemeli olarak çözülmeli; en az teslim kapsamı dışındaki ilk bileşene kadar.
• SBOM'un kendisi için oluşturan ve zaman damgası; her bileşen için oluşturan, ad, sürüm, dosya adı, bağımlılıklar, dağıtım lisansları ve dağıtılan dosyanın SHA-512 özeti zorunlu alanlar arasında.

TR-03183 bir CRA uyumlaştırılmış standardı değil. Yine de SBOM içeriğini bu kadar ayrıntılı tarif eden kamuya açık birkaç belgeden biri; SBOM üretim hattınızı tasarlarken kontrol listesi olarak işe yarar.

06ABD'nin 2026 SBOM asgari unsurları (CISA)

ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA) 29 Temmuz 2026'da "2026 Minimum Elements for a Software Bill of Materials (SBOM)" belgesini yayımladı. Belge, NTIA'nın 2021'de yayımladığı asgari unsurların yerini alıyor ve NSA ile FBI'ın yanı sıra Almanya'nın BSI'si, Fransa'nın ANSSI'si ve Hollanda'nın NCSC-NL'si dahil 17 kuruluşla birlikte hazırlandı. Belgeye göre asgari unsurlar yeni bir yükümlülük getirmiyor; SBOM'un nasıl üretilip isteneceğini netleştiriyor.

Asgari unsurlar iki grupta:

• Veri alanları (17): SBOM'un kendisi için yazar, yazar imzası, veri biçiminin adı ve sürümü, üretim bağlamı, zaman damgası, üreten aracın adı ve sürümü ve SBOM sürümü; her bileşen için ad, sürüm, üretici, tanımlayıcılar, özet değeri ve özet algoritması, lisans ve bağımlılık ilişkisi.
• Uygulamalar ve süreçler (6): SBOM verisindeki güncelleme ve düzeltmelerin kabul edilmesi, kapsam, dağıtım ve teslim, bilinmeyen bilginin açıkça belirtilmesi, sıklık (her sürüm için yeni SBOM) ve makinece işlenebilir veri (bugün yaygın biçimler SPDX ve CycloneDX).

CRA bu belgeye atıf yapmaz; CISA belgesi ise CRA'yı, SBOM'u teknik dokümantasyonun parçası olarak isteyen bir AB düzenlemesi olarak anar. İki yaklaşım çelişmiyor ama aynı derinlikte de değil. CRA en azından üst düzey bağımlılıkları kapsayan, yaygın kullanılan ve makinece okunabilir bir SBOM istiyor. CISA belgesi ise geçişli bağımlılıklar dahil bütün bileşenleri istiyor, asgari bir derinlik tanımlamıyor ve özet değerini, lisansı ve yazar imzasını asgari alanlar arasında sayıyor. Bu belgeye göre hazırlanmış bir SBOM, kapsam ve biçim bakımından CRA'nın asgari şartının ötesine geçer; tersi her zaman doğru değildir. AB pazarında esas alınacak metin yine CRA ve Komisyon'un Madde 13(24) uyarınca ileride çıkarabileceği uygulama tüzüğüdür.

07SBOM ve VEX

SBOM "içinde ne var?" sorusunu cevaplar. Bunu bir zafiyet veritabanıyla (OSV, NVD) eşleştirdiğinizde ham bir liste çıkar: openssl 3.0.13 var ve şu CVE'ler bu sürümü etkiliyor. Bu listedeki her kayıt ürününüzü gerçekten etkilemez; ilgili kod derlemeye hiç girmemiş ya da hiç çağrılmıyor olabilir.

VEX (Vulnerability Exploitability eXchange) ikinci soruyu cevaplar: bu zafiyet bizi etkiliyor mu? Her zafiyet için bir durum yazılır: etkileniyor, etkilenmiyor (gerekçesiyle), düzeltildi ya da inceleniyor. CSAF 2.0 ve OpenVEX bu bilgiyi taşıyan yaygın biçimler; CycloneDX de VEX'i kendi belgesinde taşıyabilir.

İkisi birlikte çalışır. SBOM her sürümde yeniden üretilir, VEX ise yeni zafiyetler duyuruldukça güncellenir. SBOM'u olmayan ekip VEX yazamaz; VEX yazmayan ekip de müşterisinin tarayıcısında çıkan her alarma tek tek cevap vermek zorunda kalır.

08Sık yapılan hatalar

• SBOM'u bir kere üretip dosyalamak. Her firmware sürümünün kendi SBOM'u olmalı.
• Kaynak ağacından çıkan listeyi imajın gerçeği saymak.
• Sürümü boş bileşen bırakmak.
• PURL ya da CPE yazmamak; isim benzerliğiyle yapılan eşleştirme yanlış alarm üretir.
• Statik bağlanmış kütüphaneleri ve tedarikçi ikililerini atlamak.
• SBOM'u üretip izlemeyi bırakmak. Bileşenler destek süresi boyunca yeni zafiyetlere karşı izlenmeli.
• Ham zafiyet listesini olduğu gibi müşteriye göndermek. VEX olmadan o liste çoğunlukla gürültüdür.

09Nereden başlamalı?

Kilit dosyalarınız, bir Yocto manifest'iniz ya da Buildroot manifest.csv dosyanız varsa ücretsiz SBOM tarayıcımız bunlardan CycloneDX ya da SPDX dosyası üretir ve bileşenleri OSV.dev'de kontrol eder. Dosyalar tarayıcınızda okunur, bilgisayarınızdan çıkmaz. Firmware imajının kendisinden SBOM çıkarmayı, VEX'i ve sürekli izlemeyi kendi imajınızla denemek isterseniz pilot programımıza bakın.

SBOM'un CRA'daki yerini diğer yükümlülüklerle birlikte görmek için CRA rehberi; router, modem ve ağ cihazlarına özgü noktalar için ağ ve telekom cihazları.

10Sık sorulanlar