Yazılım tedarik zinciri saldırıları son 4 yılda %742 artmış ve Sonatype State of the Software Supply Chain 2024 raporuna göre 2024’te 245.000+ yeni malicious package tespit edilmiştir. CISA ve EU Cyber Resilience Act SBOM (Software Bill of Materials) üretimini regülatör zorunluluk haline getirmektedir. Doğru SBOM stratejisi ile tedarik zinciri zafiyet response süresi 78 saatten 3,5 saate düşer; yanlış kurgu ise SolarWinds, Log4Shell tipi olaylarla 4-50 milyon USD’lik kaybiyeye yol açar.
Bu rehberde SBOM ve yazılım tedarik zinciri güvenliği pratiklerini detaylı inceliyoruz:
- SBOM tanımı, içeriği ve düzenleyici gereksinimler
- SPDX ve CycloneDX formatları karşılaştırması
- SBOM üretimi: Syft, Trivy, GitHub, build pipeline entegrasyonu
- Vulnerability scanning ve VEX (Vulnerability Exploitability eXchange)
- Tedarik zinciri saldırı tipleri ve savunma stratejileri
- SLSA framework, sigstore ve build provenance
SBOM Nedir ve Neden Zorunlu Hale Geldi?
SBOM (Software Bill of Materials), bir yazılım ürününün tüm bileşenlerini, bağımlılıklarını ve bunların sürümlerini listeleyen makine-okunabilir manifestodur. Tıbbi cihazlardaki “etiket” gibi, yazılımın içinde ne olduğunu gösterir. CISA 2021 EO 14028 ile ABD federal yazılım tedarikçileri için zorunlu hale gelmiştir.
SBOM’un içermesi gereken minimum alanlar:
- Supplier name: Bileşeni sağlayan tedarikçi
- Component name: Bileşenin ismi (npm, maven, pypi, vb.)
- Component version: Tam sürüm numarası
- Unique identifier: PURL (Package URL) veya CPE
- Dependency relationships: Bileşenler arası bağımlılık ağacı
- Author of SBOM: SBOM’u oluşturan kişi/sistem
- Timestamp: Oluşturma zamanı
- Hash/checksum: Integrity için
- License: Lisans bilgisi
Düzenleyici Gereksinimler ve Compliance
SBOM artık çoklu yargı bölgesinde regülatör zorunluluktur:
| Düzenleme | Yargı Bölgesi | Etki | Yürürlük |
|---|---|---|---|
| EO 14028 | ABD Federal | Federal yazılım satıcıları SBOM sağlamalı | 2021+ |
| NTIA Minimum Elements | ABD | SBOM içerik standardı | 2021 |
| EU Cyber Resilience Act | AB | 2026 itibarıyla CE markalı ürünlerde SBOM | 2025-2027 |
| NIS2 Direktifi | AB | Kritik altyapı için tedarik zinciri risk yönetimi | Ekim 2024 |
| FDA Premarket Guidance | ABD tıbbi cihaz | Cyber Bill of Materials | 2023 |
| DORA (Digital Operational Resilience) | AB finansal | Üçüncü-taraf yazılım kontrolü | Ocak 2025 |
| BSI TR-03183 (Almanya) | Almanya | SBOM teknik gereksinimler | 2024 |
SBOM Formatları: SPDX vs CycloneDX
İki dominant SBOM formatı vardır ve her ikisi de ISO/IEC 5962 (SPDX) veya ECMA-424 (CycloneDX) standartlarına sahiptir.
| Kriter | SPDX | CycloneDX |
|---|---|---|
| Standart organizasyon | Linux Foundation | OWASP |
| İlk yayın | 2011 | 2017 |
| Birincil odak | Lisans compliance | Güvenlik |
| ISO standardı | ISO/IEC 5962:2021 | ECMA-424 (2024) |
| Formats | JSON, YAML, RDF, Tag-Value | JSON, XML, Protobuf |
| VEX desteği | SPDX 3.0 | Yerel |
| VDR (Vulnerability Disclosure Report) | Yok | Yerel |
| Build provenance | SPDX 3.0 Build profile | Yerel |
| Tool desteği | Yaygın (Syft, FOSSology) | Yaygın (Trivy, Snyk) |
| NTIA uyumu | Var | Var |
| Önerilen kullanım | Lisans-ağırlıklı senaryolar | Güvenlik-ağırlıklı senaryolar |
SBOM Üretim Araçları
SBOM üretimi build pipeline’ında otomatize edilir. Syft ve Trivy en yaygın açık kaynak araçlardır.
| Araç | Lisans | Format Desteği | Kaynak Tipleri | Vuln Scan |
|---|---|---|---|---|
| Syft (Anchore) | Apache 2.0 | SPDX, CycloneDX, Syft | Container, dir, archive | Hayır (Grype’a feed) |
| Trivy (Aqua) | Apache 2.0 | SPDX, CycloneDX | Container, fs, repo, IaC | Evet |
| Snyk SBOM | Proprietary | SPDX, CycloneDX | Repo, container, IaC | Evet |
| GitHub Dependency Graph | Free for public | SPDX | Repo | Dependabot |
| Microsoft SBOM Tool | MIT | SPDX | Build artifact | Hayır |
| FOSSA | Proprietary | SPDX, CycloneDX | Repo, container, mobile | Evet |
| JFrog Xray | Proprietary | SPDX, CycloneDX | Artifactory | Evet |
| BlackDuck | Proprietary | SPDX | Çoklu | Evet |
Yazılım Tedarik Zinciri Saldırı Tipleri
2020 sonrası dönemde tedarik zinciri saldırıları belirgin pattern’ler göstermiştir. Snyk State of Open Source Security 2024 raporuna göre malicious package sayısı yıllık %156 artmaktadır.
- Dependency confusion: Private package’ın public registry’de aynı isimle yayını
- Typosquatting: Popüler package adının yanlış yazılışıyla tuzak (express’in expres olarak)
- Compromised maintainer: Maintainer hesabı çalınarak malicious version yayını
- Build pipeline poisoning: CI/CD ortamına malicious script enjeksiyonu (SolarWinds)
- Source code manipulation: Direct repo commit, Codecov tipi saldırılar
- Container image tampering: Base image’a backdoor enjeksiyonu
- Update mechanism abuse: Auto-update kanalının hijack’i
- Transitive dependency exploitation: Indirect dependency’lerden saldırı (Log4Shell)
Önemli Tedarik Zinciri Olayları
| Olay | Yıl | Etki | Maliyet Tahmini |
|---|---|---|---|
| SolarWinds | 2020 | 18.000+ kurum, ABD hükümeti dahil | 100+ milyon USD |
| Codecov | 2021 | 29.000+ enterprise müşteri | 30+ milyon USD |
| Log4Shell (CVE-2021-44228) | 2021 | %93 enterprise Java app etkilendi | 50+ milyar USD global |
| ua-parser-js compromise | 2021 | 9 milyon haftalık download package | Tahmin edilemedi |
| xz-utils backdoor (CVE-2024-3094) | 2024 | Linux distros, SSH | Yakalandı, sınırlı |
| 3CX desktop app | 2023 | 600.000+ şirket | 200+ milyon USD |
| MOVEit Transfer | 2023 | 2.000+ kurum, 60 milyon kişi | 10+ milyar USD |
| PyPI typosquatting (2024) | 2024 | 500+ malicious package | Devam ediyor |
SLSA Framework: Build Provenance
SLSA (Supply-chain Levels for Software Artifacts), Google tarafından 2021’de tanıtılan ve build process integrity’sini garanti altına alan bir çerçevedir. 4 olgunluk seviyesi tanımlar.
| SLSA Seviye | Açıklama | Kontrol | Tipik Uygulama |
|---|---|---|---|
| SLSA 1 | Build process documentation | Build script, provenance generated | GitHub Actions basic |
| SLSA 2 | Tamper resistance of service | Authenticated, version-controlled source | Cloud Build hosted |
| SLSA 3 | Extra resistance to attacks | Non-falsifiable provenance, isolated build | Hardened build environment |
| SLSA 4 | Highest level of confidence | Two-party review, hermetic build, reproducible | Critical infrastructure |
Sigstore: Yazılım İmzalama ve Verification
Sigstore, Linux Foundation altındaki açık kaynak proje olup yazılım artifact’lerinin imzalanması ve doğrulanmasını sağlar. Cosign, Fulcio ve Rekor olmak üzere 3 ana bileşenden oluşur.
- Cosign: Container image, binary ve SBOM imzalama tool’u
- Fulcio: Short-lived signing certificate üreten CA (OIDC tabanlı identity)
- Rekor: Append-only transparent log (audit trail)
- Keyless signing: Long-lived private key yerine identity-based imzalama
- GitHub Actions entegre: sigstore/cosign-installer action
- SLSA uyumlu provenance: Build attestation otomatik üretimi
VEX: Vulnerability Exploitability eXchange
VEX, bir yazılım üreticisinin SBOM’unda listelenen bileşenlerdeki zafiyetlerin gerçekten exploit edilebilir olup olmadığını beyan ettiği standart formattır. Çoğu zafiyet (CVE) belirli kullanım koşullarında etkili değildir.
VEX statement’ları 4 ana durum içerir:
- Not affected: Component etkilenmiyor (örn. zafiyetli fonksiyon kullanılmıyor)
- Affected: Component etkilenir, action gerekli
- Fixed: Zafiyet çözüldü, patched version
- Under investigation: Inceleme devam ediyor
VEX’in pratik faydaları:
- Alert fatigue azalması: Compromise olmayan zafiyetler filtrelenir, %70-85 false positive azalır
- Triage hızı: Hangi CVE’lere odaklanılacağı net
- Müşteri iletişimi: Müşteriler hızlıca “etkilemiyor” yanıtını alır
- Compliance: NIS2, DORA gerektirdiği detayda response
SBOM Üretim ve Yönetim Süreci
Production-grade SBOM üretim süreci 8 adımdan oluşur:
- Asset envanteri: Tüm ürün ve servislerin listesi (1 hafta)
- Format seçimi: SPDX veya CycloneDX (1 gün)
- Tool entegrasyonu: CI/CD’de Syft veya Trivy (1-2 hafta)
- İmzalama: Cosign ile SBOM signing (3-5 gün)
- Storage: OCI registry, S3 veya dedicated SBOM repo (1 hafta)
- Vulnerability mapping: Trivy, Grype, Snyk ile CVE eşleştirme (1 hafta)
- VEX üretimi: Compromise olmayan CVE’ler için statement (sürekli)
- Distribution: Müşteri portal’ı, OCI registry, API (2 hafta)
DevSecOps shift-left rehberimizde detayları bulabilirsiniz. Container security yazımız tedarik zinciri savunmasını tamamlar.
Tedarik Zinciri Güvenlik Pratikleri
SBOM tek başına yeterli değildir; kapsamlı bir tedarik zinciri güvenlik programı için çoklu katman gereklidir:
- Dependency pinning: Exact version, hash-based (npm package-lock, pip-compile)
- Private registry: JFrog Artifactory, AWS CodeArtifact, GitHub Packages
- Proxy ve allowlist: Sadece onaylı public package mirror’ı
- Automated vulnerability scanning: Snyk, Dependabot, Renovate
- License compliance: FOSSA, Snyk Open Source
- Image signing: Cosign, Notary v2
- Admission control: Kubernetes admission webhook ile imzasız image reddi
- Air-gapped build: Hermetic build ortamı (Bazel)
- Secrets in dependencies: GitGuardian, TruffleHog ile leak detection
Maliyet ve Yatırım Analizi
Kurumsal SBOM ve supply chain security programı yıllık maliyeti şirket büyüklüğüne göre değişir:
| Maliyet Kalemi | Küçük (5-15 dev) | Orta (50-200 dev) | Büyük (500+ dev) |
|---|---|---|---|
| Open source toolchain (Syft+Grype+Cosign) | 0 USD | 0 USD | 0 USD |
| Commercial scanner (Snyk/JFrog) | 5.000-15.000 USD | 40.000-120.000 USD | 200.000-800.000 USD |
| SBOM management platform | 0 USD (manual) | 20.000-60.000 USD | 100.000-300.000 USD |
| DevSecOps engineer (FTE) | 0,5 FTE | 1-2 FTE | 5-10 FTE |
| Training + compliance audit | 5.000 USD | 20.000 USD | 80.000 USD |
| Yıllık toplam (USD) | 50.000-100.000 | 250.000-650.000 | 1,5-5 milyon |
| Yıllık TL eşdeğeri | 1,7-3,4 milyon | 8,5-22,1 milyon | 51-170 milyon |
Kurumsal SBOM ve Supply Chain Security Dönüşümünde Karşılaşılan Tipik Sorunlar
SBOM implementasyonunda teknik araç seçimi kadar süreç olgunluğu ve organizasyonel uyum kritiktir. Danışmanlık projelerinde gözlemlenen örüntüler, SBOM programlarının %47’sinin ilk yıl içinde “compliance check-box” seviyesinde kaldığını ve operasyonel değer üretmediğini göstermektedir. Tipik sorunlar:
- SBOM üretiliyor ama kullanılmıyor: CI/CD’de SBOM dosyası oluşturuluyor, ama vulnerability mapping yok
- VEX statement’lar eksik: 1.200 CVE’den 800’ü false positive, triage kaos
- Transitive dependency görünmez: Direct dependency listesi tam, alt-bağımlılıklar atlanmış
- Container ve uygulama ayrı: Application SBOM ve base image SBOM birleştirilmemiş
- Signing ve verification yok: SBOM üretiliyor ama imzalanmıyor, integrity garantisi yok
- Müşteri tarafı eksik: Müşterilere SBOM gönderilmiyor, talep gelince ad-hoc üretim
Sık Sorulan Sorular
SPDX ve CycloneDX arasında hangisini seçmeliyim?
Seçim birincil kullanım amacına bağlıdır. Lisans compliance odaklı projelerde (özellikle açık kaynak ürünler) SPDX daha olgun bir ekosisteme sahiptir; FOSSology, ScanCode gibi araçlarla geniş entegrasyon vardır. Güvenlik-odaklı kullanımda CycloneDX VEX, VDR ve build provenance gibi güvenlik metadatalarını yerel olarak destekler. Çoğu modern toolchain (Syft, Trivy) her ikisini de üretebilir; minimum effort ile her iki formatta da SBOM yayınlamak yaygın pratiktir.
SBOM hangi sıklıkla üretilmelidir?
SBOM her build’de otomatik üretilmelidir. CI/CD pipeline’a Syft veya Trivy entegrasyonu ile her commit/PR’da yeni SBOM oluşturulur; release artifact’i ile birlikte versiyonlandırılır. Production deployment için SBOM signed ve OCI registry/SBOM repository’ye push edilir. Üretim sonrası saatlik/günlük vulnerability scan ile SBOM’a yeni keşfedilen CVE’ler eşlenir; yeni kritik zafiyet keşfinde alert üretilir. Müşterilere her release ile SBOM iletilir.
SBOM müşteriye ne zaman ve nasıl iletilir?
Müşterilere SBOM 3 kanaldan iletilir: (1) Release sayfasında public download (open source projeler), (2) Müşteri portal’ından authenticated download (enterprise SaaS), (3) OCI registry’den signed artifact (container distribution). NIS2 ve DORA gerektirdiği gibi major release ile birlikte ve material change’lerde güncellenmiş SBOM iletilir. Format hem SPDX hem CycloneDX olabilir; müşteri tercihi sorulmalı. SBOM ile birlikte VEX statement’ları, lifecycle bilgisi ve contact bilgisi de paylaşılır.
Tedarik zinciri saldırılarından nasıl korunulur?
Çok katmanlı savunma gerekir: (1) Private package registry (Artifactory, CodeArtifact), (2) Allowlist-based public registry proxy, (3) Dependency pinning hash ile, (4) Automated vulnerability scanning (Snyk, Dependabot), (5) Container image signing (Cosign), (6) Admission control (Kyverno, OPA), (7) Build provenance (SLSA Level 3+), (8) Secret scanning (TruffleHog, GitGuardian), (9) Maintainer trust (sigstore identity), (10) Regular dependency audit. Bu adımlar dependency confusion, typosquatting ve compromised maintainer saldırılarının %92’sini önler.
Açık kaynak araçlarla enterprise-grade SBOM mümkün mü?
Evet. Syft (SBOM üretim) + Grype (vulnerability scan) + Cosign (imzalama) + Rekor (transparent log) açık kaynak stack’i enterprise gereksinimlerinin %80-85’ini karşılar. Commercial alternatifler (Snyk, JFrog Xray, Black Duck) ek özellikler sunar: license risk scoring, exploit availability data, otomatik VEX üretimi, MTTR analytics, AI tabanlı prioritization. Küçük-orta ekipler için open source yeterlidir; 200+ developer ekiplerinde commercial tool managed dashboard ve compliance reporting avantajı sağlar.
Sonuç
SBOM ve yazılım tedarik zinciri güvenliği 2026 itibarıyla regülatör zorunluluk ve teknik en iyi pratik olarak kurumsal yazılım stratejisinin ayrılmaz parçası haline gelmiştir. Tedarik zinciri saldırılarının son 4 yılda %742 artması ve EU Cyber Resilience Act, NIS2, DORA gibi regülasyonların SBOM’u zorunlu kılması, kurumların kapsamlı bir strateji geliştirmesini gerektiriyor. SPDX (lisans odaklı) ve CycloneDX (güvenlik odaklı) iki dominant format olarak farklı senaryolara hitap eder; Syft, Trivy, Snyk gibi araçlarla CI/CD entegrasyonu standart hale gelmiştir. SLSA framework build provenance ile, Sigstore (Cosign, Fulcio, Rekor) integrity garantisi ile, VEX false positive azaltma ile tamamlayıcı katmanlar oluşturur. Küçük ekipler için yıllık 50.000-100.000 USD ile open source toolchain yeterliyken, büyük kurumlar için 1,5-5 milyon USD aralığında kapsamlı program kurulumu gerekir. Doğru implementasyon ile tedarik zinciri zafiyet response süresi 78 saatten 3,5 saate düşer ve SolarWinds, Log4Shell tipi 4-50 milyon USD’lik olayların önüne geçilir.
Ömer ÖNAL
Mayıs 17, 2026SBOM’u SOC2/ISO 27001/FedRAMP audit’lerde “var göstermek” yeterli sanılıyor ama gerçek değer continuous vuln scanning (Grype, Trivy) ile entegre olunca çıkıyor. SPDX vs CycloneDX formatından çok, hangi tool zincirinde maintain edileceği daha önemli karar.