SBOM Formatları: SPDX vs CycloneDX ve Pratik Uygulama 2026

SBOM format seçimi tedarik zinciri güvenlik programınızın temelini belirler: yanlış format, ileride milyonlarca satır JSON’u yeniden üretmek anlamına gelir. 2026 itibarıyla iki format domine ediyor — Linux Foundation tarafından yönetilen SPDX 3.0 ve OWASP çatısı altındaki CycloneDX 1.6. ABD Executive Order 14028 ve EU Cyber Resilience Act (CRA) sonrası SBOM, opsiyonel uyum belgesi olmaktan çıkıp zorunlu artefakt haline geldi. Pratik soru şu: hangi sbom format hangi pipeline için optimal, signing/attestation katmanı SLSA Level 3’e nasıl bağlanır?

Kısa cevap: lisans compliance ağırlıklı supply chain envanteri için SPDX 3.0; vulnerability management ve VEX entegrasyonu senaryoları için CycloneDX 1.6 tercih edilir. Çoğu olgun program ikisini de üretir — Syft ve Trivy tek geçişte iki formatı da çıkarır. Bu rehberde iki spesifikasyonu nesne modeline kadar açar, somut farkları tablolarla gösterir, Syft/Trivy/cdxgen/Dependency-Track ile gerçek bir tedarik zinciri pipeline’ı kurarız.

SBOM Nedir, Neden 2026’da Zorunlu Hale Geldi

Software Bill of Materials (SBOM), bir yazılım artefaktının (binary, container image, firmware) içerdiği tüm bileşenleri — direct ve transitive bağımlılıklar dahil — makine-okunur formatta listeleyen envanterdir. SolarWinds (Aralık 2020), Log4Shell (Aralık 2021) ve XZ Utils backdoor (Mart 2024) olaylarından sonra düzenleyici baskı kritik kütleye ulaştı. ENISA 2023 Threat Landscape raporuna göre supply chain saldırıları 2020-2023 arasında %431 arttı, IBM Cost of a Data Breach 2024 raporunda ortalama olay maliyeti 4.88 milyon USD.

SBOM’un üç katmanı vardır: build-time (kaynak koddan üretilen, en doğru), analyzed (binary üzerinden tersine mühendislik, transitive eksik), deployed (runtime’daki container’ın gerçek durumu). NTIA “Minimum Elements” her bileşen için 7 zorunlu alan tanımlar: supplier, component, version, unique identifier (PURL/CPE), dependency relationship, author, timestamp. CycloneDX ve SPDX 3.0 bu yedi alanı superset olarak içerir.

Regülasyon	Coğrafya	Yürürlük	SBOM Gereksinimi
EO 14028 / OMB M-22-18	ABD federal	Eylül 2022	Federal alımlar için zorunlu, self-attestation
EU CRA (Cyber Resilience Act)	AB	Aralık 2024 (uygulama 2027)	“Important/Critical” ürünlerde SBOM şart
FDA Premarket Guidance	ABD medikal cihaz	Eylül 2023	510(k) başvurularında SBOM zorunlu
NIS2 Directive	AB kritik altyapı	Ekim 2024	Tedarik zinciri risk yönetiminde SBOM önerilir
UK Telecoms Security Act	Birleşik Krallık	Ekim 2022	Tier 1 operatörler için tedarikçi envanteri
Japan METI Guidelines v2	Japonya	Mayıs 2024	Kritik altyapı için pilot zorunluluk

Bu çerçeveler içinde format seçimi neutral değildir: ABD federal alımları SPDX 2.3’ü referans alır (NTIA tarafından profile yayımlanmıştır), EU CRA implementing acts CycloneDX’i benzer ağırlıkta listeler. Pratik tavsiye: ikisini de üretin, depolayın, request-on-demand sunun. Bu strateji SBOM SLSA tedarik zinciri mimarisinde detaylı işlenir.

SPDX 3.0 Spesifikasyonu: Yapı ve Veri Modeli

SPDX (Software Package Data Exchange), Linux Foundation bünyesinde 2011’den beri sürdürülüyor; ISO/IEC 5962:2021 olarak standartlaştırıldı (resmi ISO statüsüne sahip tek SBOM formatı). SPDX 3.0 (Nisan 2024 GA) önceki 2.3’ten radikal şekilde yeniden tasarlandı: monolitik JSON yapısı yerine profile-based modular sisteme geçildi. Çekirdek profil her zaman zorunlu, Software/Licensing/Security/AI/Dataset/Build profilleri opsiyonel. Bu modülerlik AI modellerini ve veri setlerini de envantere dahil etmeyi mümkün kılar.

SPDX RDF/IRI tabanlı veri modeli kullanır; her element global benzersiz tanımlayıcıya (SPDX-ID) sahiptir. Serialization: JSON-LD (önerilen), JSON, YAML, RDF/XML, tag-value (legacy). Lisans ifadeleri SPDX License List‘ten gelir — 700+ standartlaştırılmış tanımlayıcı (MIT, Apache-2.0, GPL-3.0-only) ve kompozit ifadeler için Boolean operatörler (AND, OR, WITH). Hukuk ekipleri için bu, FOSSology ile otomatik clearance’ın ön şartıdır.

SPDX 3.0 Profili	Element Sayısı (yaklaşık)	Tipik Kullanım	Zorunluluk
Core	11	Element identity, relationships	Her zaman zorunlu
Software	9	Package, File, Snippet	Klasik SBOM için zorunlu
Licensing	5	License expression, concluded license	Compliance için önerilir
Security	7	Vulnerability, VEX, CVE referansları	VulnDB entegrasyonu için
Build	4	Build instructions, reproducibility	SLSA L3+ için önerilir
AI	10	Model, dataset, training metadata	AI/ML envanteri için
Dataset	8	Dataset lineage, sensitivity	Veri yönetişimi

SPDX 3.0 paket tanımlamada Package URL (purl) ve CPE referanslarını externalReferences olarak taşır; hash algoritmaları SHA-256/384/512, SHA3-256, BLAKE2b-256, BLAKE3 destekler. Orta büyüklükteki bir Node.js uygulaması (1500 transitive deps) için SPDX 3.0 JSON-LD dosyası sıkıştırılmamış 8-15 MB, gzip sonrası 600-1200 KB seviyesindedir.

CycloneDX 1.6 Spesifikasyonu: Güvenlik Odaklı Tasarım

CycloneDX, OWASP projesi olarak 2017’de Steve Springett tarafından başlatıldı; bugün ECMA-424 standardı olarak yayımlanıyor. Tasarım felsefesi farklıdır: SPDX “her şeyi tanımla, sonra security ekle” yaklaşımıyla başlarken, CycloneDX “security ve operational risk önce” diye yola çıktı. CycloneDX, VEX (Vulnerability Exploitability eXchange), VDR (Vulnerability Disclosure Report), CBOM (Cryptography BOM), ML-BOM, SaaSBOM, OBOM gibi ek tipleri tek spesifikasyonda taşır.

CycloneDX 1.6 (Nisan 2024) yenilikleri: Lifecycles (design, pre-build, build, post-build, operations), Cryptographic Properties (post-quantum migration için kritik), Tags ve Standards, Formulation (build instructions, SLSA provenance için). Serialization: JSON (önerilen), XML ve Protocol Buffers — binary serialization yüksek hacimli ML pipeline’larda 3-5x daha kompakt SBOM üretir.

Özellik	SPDX 3.0	CycloneDX 1.6
Kuruluş	Linux Foundation	OWASP / ECMA
İlk yayın	2011	2017
ISO/ECMA standart	ISO/IEC 5962:2021	ECMA-424:2024
Veri modeli	RDF / IRI tabanlı	Tree / nested JSON
Önerilen serialization	JSON-LD	JSON
Ek format desteği	YAML, RDF/XML, tag-value	XML, Protocol Buffers
VEX entegrasyonu	Security profile (3.0+)	Native (1.4+)
VDR	Yok	Native (1.5+)
CBOM / crypto envanter	Yok (3.0 limited)	Native (1.6)
ML-BOM	AI profile (3.0)	Native (1.5+)
SaaSBOM	Yok	Native (1.4+)
Lisans ifadeleri	SPDX License List 700+	SPDX License List ref + free-text
Tipik tool desteği	FOSSology, ScanCode, Syft	Dependency-Track, cdxgen, Syft, Trivy

Pratikte CycloneDX modern dev/security toolchain’inde daha fazla yer tutar — OWASP Dependency-Track son üç yılda GitHub star sayısını 1800’den 3000+’a çıkardı. SPDX ise yasal/uyum süreçlerinde, özellikle açık kaynak lisans denetimlerinde, FOSSology ve Tern üzerinden otorite konumunda. DevSecOps shift-left stratejisinde format seçimi bu iki profilden hangisinin baskın olduğuna göre belirlenir.

İki Format Yan Yana: Somut Karşılaştırma

Yapısal farkları gerçek dosyalar üzerinden görmek en doğrusu. Aynı bağımlılık (lodash 4.17.21) SPDX 3.0 JSON-LD’de ortalama 38 satır, CycloneDX 1.6 JSON’da ortalama 24 satır kaplar. 5000 bileşenli bir monorepo için SPDX dosyası gzip öncesi 22 MB, CycloneDX 14 MB civarındadır; Protocol Buffers ile CycloneDX 3.8 MB’a iner.

Veri modeli açısından SPDX graph-based; ilişkiler ayrı element olarak typed kenarla taşınır (DEPENDS_ON, BUILD_TOOL_OF, CONTAINS, GENERATED_FROM gibi 40+ ilişki tipi). CycloneDX tree-based; bağımlılıklar nested `dependencies[]` dizilerinde ve `components[]` flat listesinde tutulur. SPDX karmaşık ilişkileri daha doğal ifade eder; CycloneDX hızlı parsing ve scanner ingestion için optimizedir.

Senaryo	SPDX 3.0 Uygunluğu	CycloneDX 1.6 Uygunluğu	Öneri
Open source lisans clearance	Yüksek (FOSSology native)	Orta	SPDX
Vulnerability ingestion (Dep-Track, Snyk, Mend)	Orta	Yüksek	CycloneDX
Federal alım (US EO 14028)	Yüksek	Yüksek	İkisini de üret
Medikal cihaz FDA başvurusu	Yüksek	Yüksek	SPDX (geleneksel)
ML model envanteri	Yüksek (AI profile)	Yüksek (ML-BOM)	CycloneDX (olgun)
Post-quantum crypto envanteri	Düşük	Yüksek (CBOM)	CycloneDX
SLSA L3 attestation	Yüksek (Build profile)	Yüksek (Formulation)	İkisi de
SaaS abonelik envanteri	Düşük	Yüksek (SaaSBOM)	CycloneDX
Air-gapped/defense kontekst	Yüksek	Orta	SPDX
Container/Kubernetes runtime SBOM	Orta	Yüksek	CycloneDX

Pratik şu: monolitik bir karar yerine çift format pipeline kurun. Syft tek komutla `syft scan dir:. -o spdx-json -o cyclonedx-json` ile iki dosya çıkarır; storage maliyeti S3 Standard’da yıllık 1000 build için tahmini 60-90 USD. Bu marjinal maliyet, denetimde “yanlış format” gerekçesiyle geri dönülmesinden ucuzdur.

Generation Araçları: Syft, Trivy, cdxgen Karşılaştırması

SBOM üretim kalitesi araca bağlıdır — aynı container imajı için farklı tool’lar %15-40 arasında farklı bileşen sayısı raporlayabilir. Fark çoğunlukla transitive dependency çözünürlüğünden ve OS package detection mantığından kaynaklanır. 2026 itibarıyla olgun üç açık kaynak generator: Anchore Syft, Aqua Trivy ve OWASP cdxgen.

• Syft (Anchore): Go ile yazılmış container ve filesystem catalog’er. Avantaj: 25+ ecosystem (npm, PyPI, Maven, Cargo, RPM, DEB, APK, Conan, Swift). Dezavantaj: Vulnerability scanning yok (Grype ile pair). Ne zaman seç: Saf SBOM ve maximum ecosystem coverage.
• Trivy (Aqua): Tek binary’de scanner + SBOM. Avantaj: SBOM + vulnerability + misconfiguration + secret tek geçişte. Dezavantaj: File-level granularity sınırlı. Ne zaman seç: CI’da hem SBOM hem CVE taraması.
• cdxgen (OWASP): CycloneDX reference generator. Avantaj: Native CycloneDX, deep evidence tracking. Dezavantaj: SPDX yok, container scanning sınırlı. Ne zaman seç: Pure CycloneDX evidence-rich pipeline.
• Microsoft SBOM Tool: SPDX 2.2/2.3 native. Ne zaman seç: Microsoft stack ve federal compliance.
• Tern (VMware): Container layer license inspection. Ne zaman seç: Legacy imajlar için detaylı license forensics.

Benchmark olarak ortalama bir Spring Boot Java uygulaması (Maven, 280 transitive deps, 350 MB Docker imajı) üzerinde:

Tool	Scan Süresi	Tespit Edilen Bileşen	SBOM Dosya Boyutu (CycloneDX JSON)	Memory Peak
Syft v1.x	~22 sn	312	1.8 MB	~340 MB
Trivy v0.5x	~18 sn	298	1.6 MB	~280 MB
cdxgen v10.x	~45 sn	335 (deep mode)	2.4 MB (evidence dahil)	~620 MB
sbom-tool	~38 sn	285	1.4 MB (SPDX 2.3)	~410 MB

Not: Ölçümler 4 vCPU / 8 GB RAM GitHub Actions runner üzerinde tahmini olarak verilmiştir; gerçek değerler kaynak proje yapısına göre değişir. Container güvenliği pipeline’ında genellikle Syft + Grype kombinasyonu ile Trivy paralel çalıştırılır; iki farklı bakış açısı (component-first vs vulnerability-first) blind spot riskini azaltır.

CI/CD Pipeline’a Entegrasyon: GitHub Actions ve GitLab

SBOM’un asıl değeri pipeline’a oturduğunda ortaya çıkar — bir kerelik generate edilip rafa kaldırılan dosya audit anında işe yaramaz. Doğru pattern: her build’de iki format SBOM üret, GitHub Actions Artifact veya OCI registry’ye yaz, Sigstore Cosign ile imzala, Dependency-Track gibi ingestion platformuna push’la. Canonical GitHub Actions workflow özeti:

1. Checkout (`actions/checkout@v4`) — fetch-depth 0 ile.
2. Setup language (Node, Python, Go vb.) ve dependency install (`npm ci`, `pip install -r`, `go mod download`).
3. Syft scan (`anchore/sbom-action@v0`) — `format: spdx-json,cyclonedx-json`.
4. Cosign attestation — `cosign attest –predicate sbom.cdx.json –type cyclonedx ` ve Rekor transparency log’una yaz.
5. Dependency-Track upload — REST API ile project SBOM’unu push’la.
6. Policy gate — Critical CVE bulunursa job fail; aksi halde deploy step’e geç.
7. Artifact retention — SBOM dosyalarını 90 gün GitHub Actions retention’da, kalıcı kopyayı S3/Azure Blob immutable bucket’ta.

GitLab tarafında benzer pattern `dependency_scanning` template’i ile çalışır; built-in CycloneDX desteği vardır, `gl-sbom-*.cdx.json` artifacts otomatik üretilir. Vulnerability merge request widget’ı Ultimate’a özeldir.

SBOM lifecycle’ı build’de bitmez. Deployed SBOM üretmek için Kubernetes admission controller olarak runtime SBOM scraper’lar (Snyk Runtime, Sysdig) çalışır. Bu, build-time SBOM ile gerçek pod’da çalışan kütüphaneler arasındaki farkı (drift) gösterir.

VEX, VDR ve Vulnerability Yönetimi

SBOM tek başına eksiktir: “bu sistem log4j içeriyor” bilgisi, “bu log4j sürümü Log4Shell’e açık mı?” sorusunu cevaplamaz. Burada VEX (Vulnerability Exploitability eXchange) devreye girer. VEX, bileşen-CVE çiftine “affected”, “not_affected”, “fixed”, “under_investigation” durumu ekleyen attestation katmanıdır. Sömürülebilirlik gerekçesi taşır: “vulnerable_code_not_in_execute_path”, “inline_mitigations_already_exist” gibi NTIA standart değerleri.

CycloneDX 1.6 VEX’i native taşır; aynı dosyada `vulnerabilities[]` ve `components[]` koexists eder. SPDX 2.3 native VEX desteklemez; bu sürümde VEX ayrı bir OpenVEX dosyası olarak tutulur. OpenVEX, CISA’nın desteklediği minimal, format-agnostic spesifikasyondur.

• VDR (Vulnerability Disclosure Report): CycloneDX 1.5+ ile gelen, bilinen CVE’lerin yaşam döngüsünü taşıyan dokümantasyon. Avantaj: Customer-facing disclosure için tek dosya. Ne zaman: ISO/IEC 30111 ve 29147 compliance.
• CSAF 2.0 (Common Security Advisory Framework): OASIS standardı, machine-readable security advisories. Avantaj: Vendor-grade advisory distribution. Ne zaman: Büyük vendor (ürün ailesi 10+).
• OpenVEX: Minimalist, JSON-LD tabanlı, format-agnostic. Avantaj: SBOM formatından bağımsız. Ne zaman: SPDX 2.3 + ayrı VEX akışı.
• NTIA VEX Profile: JSON profili. Dezavantaj: Ağır benimsenmedi, yerini OpenVEX aldı.

Pratik VEX kullanımı: günde 50-200 yeni CVE yayımlanır (NVD 2024 ortalaması 110/gün, 2025 tahmini 130/gün). Bunlardan %15-20’si SBOM’unuzdaki bileşene match edebilir. VEX olmadan her match için manuel “exploitable mi?” araştırması gerekir; VEX ile çifte bir defa karar verip otomasyona dökersiniz. Olgun programlarda VEX, gürültüyü %60-80 azaltır.

Signing, Attestation ve SLSA Entegrasyonu

SBOM güvenilir değilse değersizdir — saldırgan build pipeline’a sızıp SBOM’u manipüle ederse envanteriniz size yalan söyler. Bu nedenle SBOM’lar imzalanır ve provenance attestation ile bağlanır. SLSA framework’ü build sürecinin doğrulanabilirliği için Level 1-4 olgunluk seviyesi tanımlar; Level 3+ için build provenance signing zorunludur, SBOM bu attestation içine predicate olarak embed edilir.

2024’te Sigstore (Cosign + Rekor + Fulcio) fiili standart oldu; GitHub, GitLab, Google Cloud Build native destekliyor. Cosign keyless mode OIDC identity ile kısa ömürlü sertifika çeker — kalıcı private key yönetiminin riskini ortadan kaldırır. Rekor transparency log immutable kayıt sağlar.

Attestation Tipi	Predicate Type	Tipik İçerik	Tool
SLSA Provenance v1	https://slsa.dev/provenance/v1	Build inputs, builder identity	slsa-github-generator, GoReleaser
SBOM Attestation (CycloneDX)	https://cyclonedx.org/bom	Tüm CycloneDX JSON	Cosign
SBOM Attestation (SPDX)	https://spdx.dev/Document	Tüm SPDX JSON-LD	Cosign
VEX Attestation	https://openvex.dev/ns/v0.2.0	OpenVEX dokümanı	vexctl, Cosign
Vulnerability Scan	https://cosign.sigstore.dev/attestation/vuln/v1	Trivy/Grype output	Cosign
SCAI (Source Code Attestation)	https://in-toto.io/attestation/scai/v0.2	Source state, evidence	in-toto

Verification tarafında policy engine olarak Open Policy Agent veya Cosign’ın built-in CUE policy engine kullanılır. Tipik Kubernetes admission policy: “image’in imzalı SLSA L3 provenance’ı yoksa veya SBOM attestation’ı CycloneDX 1.5+ değilse deploy etme”. Bu, Zero Trust mimari‘nin tedarik zinciri katmanındaki uygulamasıdır.

Ömer Önal’ın saha deneyiminden bir not: SBOM signing’i ilk kez kuran ekiplerin yaklaşık üçte ikisi Rekor’a public log yazmaktan endişe duyar. Pratikte image digest’i ve component listesi zaten public registry’de görünür; Rekor’a yazılan bilgi marjinal ifşa değil, audit immutability garantisidir. Air-gapped ortamlar için private Rekor instance kurulabilir, danışmanlık tarafında en sık karşılaşılan dirençlerdendir.

Storage, Dağıtım ve Tüketim Platformları

SBOM’lar üretildikten sonra nerede yaşar? Üç pattern: OCI registry’de image’in yanında attestation olarak, dedicated SBOM platform’da (Dependency-Track, GUAC), veya artifact repository’de ayrı dosya. Çoğu olgun program kombine eder.

1. OCI Registry + Cosign: SBOM, image’in OCI Reference’ı ile bağlı attestation. Avantaj: Tek registry. Dezavantaj: Querying zayıf.
2. OWASP Dependency-Track: Self-hosted, CycloneDX-native. Avantaj: REST API, vulnerability correlation. Dezavantaj: SPDX desteği sınırlı.
3. GUAC: Google + Kusari knowledge graph. Avantaj: Çoklu SBOM’u tek graph’ta birleştirir, GraphQL query. Dezavantaj: Erken olgunluk.
4. Anchore / Sysdig / Snyk / Mend: Ticari platformlar, dashboard ve compliance reporting; lisans maliyeti yıllık 10K-100K USD aralığı.
5. NTIA SBOM Sharing Profiles: Vendor-customer dağıtımı için access patterns (manual, OCI, well-known URL).

Dağıtım modelinde “SBOM-on-demand” trendi öne çıkıyor; NTIA 2024 raporuna göre incelenen 50 vendor’un yaklaşık %62’si SBOM’u “request üzerine” sunarken sadece %23’ü proaktif (well-known URL veya OCI attestation) sunar. EU CRA sonrası 2027’ye kadar %80+ proaktif paya kayması bekleniyor.

Yaygın Hatalar ve Anti-Patterns

Saha gözlemleri net: aşağıdaki anti-pattern’leri görürseniz, format kavgasından çok daha büyük problem var demektir.

• Tek-seferlik SBOM: Bir kere üretip arşivlemek; üç ay sonra yazılım değişti, SBOM yalan söylüyor. Çözüm: Her CI build’de regenerate, immutable storage, regulated sektörde 7 yıl retention.
• Manuel SBOM editing: Excel’de SBOM oluşturmak veya elle düzenlemek. Çözüm: SBOM artefakt’tır; pipeline’da düzelt.
• Sadece direct dependency: package.json’daki bölümü SBOM sanmak. Çözüm: Lockfile-aware tool (package-lock.json, go.sum, Cargo.lock).
• VEX olmadan SBOM: “Log4j var” deyip “etkilenmiyor” diyememek. Çözüm: Her release ile VEX dokümanı.
• Signing’siz SBOM: Audit anında “kim üretti?” sorusuna cevap vermez. Çözüm: Cosign attestation zorunlu.
• SBOM = CMDB karışıklığı: SBOM artefakt envanteri, CMDB runtime envanteri; korrele edilir, biri diğerini ezmez.

İlgili güvenlik disiplinlerinde benzer fail-mode’lar var: penetration testing‘de “yıllık tek bir test yeter” yaklaşımı ne kadar yetersizse, SBOM’da “compliance için tek bir kere üretirim” tutumu da o kadar tehlikelidir.

Sıkça Sorulan Sorular

Sonuç

SBOM format seçimi 2026’da artık ikili bir karar değil — olgun bir tedarik zinciri güvenlik programı hem SPDX 3.0 hem CycloneDX 1.6 üretir, ikisini de imzalar ve müşteri/auditor talebine göre ilgili olanı sunar. Karar çerçevesi şu üç eksende oluşur: regülasyon (federal/medikal alım SPDX’i zorlar, EU CRA esnek), kullanım akışı (lisans clearance SPDX, vulnerability ingestion CycloneDX), ekip yetkinliği (mevcut tool’ların hangisini destekledikleri ve mevcut DevSecOps maturity).

Pratik başlangıç planı: ilk iki sprint’te Syft veya Trivy ile CI’a SBOM generation ekleyin, çift format çıkarın, GitHub Actions Artifact retention’ı 90 güne uzatın. Sonraki iki sprint’te Cosign attestation ve OpenVEX akışı kurun. Ondan sonra Dependency-Track veya GUAC self-hosted instance üzerinde dashboard’u açın; bu noktaya geldiğinizde program SLSA L2 olgunluk eşiğindedir. SLSA L3’e geçiş için hermetic build ve isolated runner gerekir, bu ayrı bir mühendislik yatırımıdır.

SBOM, tedarik zinciri güvenliğinin temel taşıdır; pipeline durumunuzu iletişim sayfası üzerinden paylaşırsanız format ve attestation stratejisi için netleşmiş öneri alabilirsiniz. Yatırım büyük değil; format kavgasında kaybedilen aylar pahalı.