SBOM (Software Bill of Materials) ve SLSA framework, 2026 itibarıyla yazılım tedarik zinciri güvenliğinin temel taşları haline geldi ve birçok ülkede kamu alımları için zorunlu standart olarak konumlandırıldı. Sonatype 2025 State of the Software Supply Chain raporuna göre kötü amaçlı açık kaynak paket sayısı yıllık bazda yüzde 156 artarak 750 bini aştı; ortalama bir kurumsal uygulama 175 doğrudan, 1.500’ün üzerinde dolaylı (transitive) bağımlılığa sahip. Bu görünmez yüzeyi yönetmek için SBOM yazılım bileşenlerinin makine okunabilir envanterini, SLSA ise üretim sürecinin bütünlüğünü garanti eder; sigstore ve in-toto bu iki katmanı kriptografik attestation ile birbirine bağlar.
Bu rehberde SBOM standartlarını (CycloneDX ve SPDX), SLSA 1.0 spesifikasyonunun build seviyelerini, sigstore zincirini (cosign, fulcio, rekor), VEX ile zafiyet bağlamlandırmayı, regülasyon takvimini (US EO 14028, EU CRA, NIS2) ve olgunlaşma seviyesine göre kurumsal yol haritasını inceliyoruz. DevSecOps shift-left protokolleri ve OWASP Top 10 2026 tedarik zinciri güvenliğinin tamamlayıcı katmanlarıdır.
Tedarik Zinciri Saldırı Yüzeyi: Görünmez Bağımlılık Ağı
Modern yazılım, kurumun yazdığı koddan çok daha geniş bir alandan beslenir: NPM, PyPI, Maven, NuGet ve container base image’ları üzerinden gelen on binlerce satır kod uygulamanın asıl yüzeyini oluşturur. SolarWinds, Codecov, Log4Shell ve xz-utils backdoor olayları farklı katmanlardaki kırılganlığı kanıtladı; CISA 2025 raporuna göre kritik altyapı ihlallerinin yüzde 41’i artık birinci derece koddan değil bağımlılık veya CI/CD zincirinden geliyor. Bu yeni gerçeklik SBOM ve SLSA gibi standartların yalnızca uyum aracı değil, gerçek savunma katmanı olarak kurumsal mimariye yerleşmesini zorunlu kıldı.
| Saldırı | Yıl | Vektör | Etkilenen | SBOM/SLSA katkısı |
|---|---|---|---|---|
| SolarWinds Orion | 2020 | Build sistemi kompromisi (SUNBURST) | 18.000+ kurum | SLSA 3 build izolasyonu + provenance ile tespit |
| Codecov bash-uploader | 2021 | CI script tampering | 23.000+ proje | İmzalı script + sigstore doğrulama |
| Log4Shell (CVE-2021-44228) | 2021 | Transitive bağımlılık RCE | Java ekosisteminin tamamı | SBOM ile dakikalar içinde envanter çıkarma |
| ua-parser-js | 2021 | NPM hesap ele geçirme | Milyonlarca indirme | Publisher attestation + Scorecard |
| 3CX desktop | 2023 | İkili tedarik zinciri kompromisi | 600.000+ kurum | SLSA 3 reproducible build |
| xz-utils backdoor | 2024 | Uzun vadeli sosyal mühendislik | Linux distribütörleri | Maintainer reputation + SLSA provenance |
| Polyfill.io | 2024 | Domain takeover, CDN supply chain | 100.000+ site | SRI + SBOM dış kaynak takibi |
SBOM Nedir ve NTIA Minimum Elements
SBOM (Software Bill of Materials), bir yazılım ürününün içerdiği tüm bileşenleri, sürümlerini, hash değerlerini, lisanslarını ve bağımlılık ilişkilerini listeleyen yapılandırılmış, makine okunabilir belgedir. NTIA’nın 2021’de yayımladığı “Minimum Elements for an SBOM” dokümanı; tedarikçi adı, bileşen adı, sürüm, eşsiz tanımlayıcı (PURL veya CPE), bağımlılık ilişkisi, SBOM yazarı ve zaman damgası alanlarını zorunlu kılar. CISA SBOM ekibi 2025 yılında bu listeyi “Framing SBOM Sharing” çerçevesiyle genişleterek paylaşım modelini standartlaştırdı.
- Source SBOM: Kaynak kod derlenmeden önce static analiz ile üretilir; geliştirici niyetini yansıtır.
- Build SBOM: CI/CD sürecinde derleme anında üretilir; gerçek artefaktı temsil eder ve provenance ile birleşir.
- Analyzed SBOM: Derlenmiş binary’nin tersine mühendislik ile çıkarımı (Syft binary analiz, BinaryAnalyzer).
- Deployed SBOM: Üretimde çalışan workload için runtime’da toplanan envanter.
- Runtime SBOM: Çalışma zamanında yüklenen ve gerçekten erişilen kütüphaneleri kaydeder; “reachable” zafiyet analizi için kritik.
Linux Foundation 2025 SBOM Survey raporu, ankete katılan kurumların yüzde 78’inin en az bir ürün için SBOM üretimini hayata geçirdiğini ve yüzde 47’sinin müşteri sözleşmelerinde SBOM teslimini zorunlu hale getirdiğini gösterir; 2023’te bu oranlar sırasıyla yüzde 52 ve yüzde 19 idi.
CycloneDX, SPDX ve Format Karşılaştırması
SBOM üretiminde iki standart hakim: OWASP CycloneDX ve Linux Foundation SPDX (ISO/IEC 5962). Her ikisi de NTIA minimum elemanlarını karşılar ve ISO standardize edilmiş veri modelleri sunar. ISO/IEC 5230 (OpenChain) lisans uyumu süreciyle SPDX, OWASP topluluğunun güvenlik odağıyla CycloneDX birbirini tamamlar; modern toolchain her ikisini de paralel üretebilir.
| Özellik | CycloneDX 1.6 | SPDX 3.0 |
|---|---|---|
| Sahip kuruluş | OWASP Foundation | Linux Foundation |
| Standart | ECMA-424 | ISO/IEC 5962:2021 |
| Format | JSON, XML, Protobuf | JSON, YAML, RDF, tag-value, spreadsheet |
| Tanımlayıcı | PURL (Package URL), CPE, SWID | PURL, SPDXID, License Identifier |
| Zafiyet bağı | Yerleşik VEX (vulnerabilities[]) | SPDX Security profil eklenti |
| Lisans modeli | SPDX License Expression | Native SPDX License List (sınıf lideri) |
| Genişletilebilirlik | ML-BOM (AI/ML), SaaSBOM, HBOM, CBOM | Profiller: Build, AI, Dataset, Security |
| Yaygın kullanım | Güvenlik, DevSecOps, container | Lisans/uyum, kernel, OpenChain |
| Tipik üreticiler | Syft, Trivy, cdxgen | Syft (SPDX modu), tern, FOSSology |
Pratikte CycloneDX güvenlik analizleri ve VEX entegrasyonu için, SPDX ise lisans uyumu, kamu raporlaması (US Federal Acquisition Regulation), ve açık kaynak topluluk teslimleri için tercih edilir. Teknoloji risk yönetimi KPI çerçevesi her iki formatın üretim oranını “uyum sağlık skoru” altına yerleştirir.
SLSA 1.0 Build Track ve Dört Seviye
SLSA (Supply-chain Levels for Software Artifacts), slsa.dev üzerinde Google öncülüğünde başlayan ve OpenSSF altında olgunlaşan uyum çerçevesidir. Eylül 2023’te yayımlanan SLSA 1.0 spesifikasyonu, eski 4 seviyeli yapıyı “Build track L1-L3” ve gelecek için “Source track” / “Dependencies track” olarak ayrıştırdı. Hedef: bir yapı sürecinin manipülasyona karşı dayanıklılığını artan seviyelerde ölçmek ve “provenance attestation” üretimini zorunlu kılmak. CNCF 2025 anketine göre OSS projelerinin yüzde 34’ü SLSA Build L3 hedefini benimsedi, yüzde 12’si ulaştı.
| Seviye | Ad | Build platform gereği | Provenance | Tipik kullanım |
|---|---|---|---|---|
| L0 | No guarantees | Yok | Yok | Lokal derleme, prototip |
| L1 | Provenance exists | Otomatik build script | Üretiliyor (imzasız olabilir) | Geliştirici makinesinde reprodüksiyon mümkün |
| L2 | Hosted build platform | Hosted, sürüm kontrollü | İmzalı, doğrulanabilir | GitHub Actions reusable workflow, GitLab CI |
| L3 | Hardened builds | İzole, ephemeral runner, non-falsifiable | Build platform tarafından üretilen güçlü provenance | slsa-github-generator, Google Cloud Build dedicated |
- L1 – Provenance exists: Yapı süreci dokümante ve otomatik; “kim, ne, nasıl, nereden” sorularına cevap veren bir provenance dokümanı üretilir.
- L2 – Hosted build: Build, paylaşılmış ama yönetilen bir platformda çalışır; provenance digital olarak imzalanır ve tüketici doğrulayabilir.
- L3 – Hardened build: Build platformu izoleli, ephemeral runner kullanır; provenance build dışından sahtelenemez (non-forgeable). En yaygın hedef seviye.
- Source track (gelecek): Kod review zorunluluğu, iki kişi onayı, sürüm geçmişi koruması.
- Dependencies track (gelecek): Tüm bağımlılıkların SLSA Build seviyesini ve provenance zincirini takip.
sigstore: cosign, fulcio, rekor ile Keyless Signing
sigstore, OpenSSF himayesinde geliştirilen ve “Let’s Encrypt for code signing” olarak konumlanan açık kaynak imzalama altyapısıdır. Klasik PKI yaklaşımındaki uzun ömürlü özel anahtar saklama sorununu, OIDC tabanlı kısa ömürlü sertifika ve şeffaf bir tomruk (transparency log) ile ortadan kaldırır. 2025 itibarıyla NPM, PyPI, Maven Central ve Kubernetes container ekosisteminde fiili standart oldu.
| Bileşen | Rol | Detay | Karşılık |
|---|---|---|---|
| cosign | İmza CLI | Container, blob, attestation imzalama ve doğrulama | OCI 1.1 referrers API ile yerleşik |
| fulcio | Sertifika otoritesi | OIDC kimlik kanıtı karşılığında 10 dakika ömürlü X.509 sertifika | GitHub, Google, Microsoft Entra OIDC desteği |
| rekor | Transparency log | Tüm imzaların append-only Merkle tree kaydı | Geriye dönük denetlenebilirlik |
| policy-controller | Kubernetes admission | Sigstore policy CRD ile imzasız image red | Cluster-wide enforcement |
| gitsign | Git commit imzalama | SSH/GPG anahtar saklama olmadan OIDC imza | Source track destekleyici |
| witness | Attestation generator | Çok adımlı pipeline’ı in-toto formatında belgele | TestifySec, CNCF sandbox |
Akış basittir: cosign, OIDC sağlayıcıdan kimlik kanıtı alır, bu kanıtla fulcio’dan 10 dakikalık sertifika talep eder, artefaktı imzalar, imza ve sertifikayı rekor transparency log’una yazar. Doğrulama tarafı; imzayı, sertifika zincirini, OIDC issuer/identity’sini ve rekor giriş indeksini bir arada denetler. Anahtar saklama sorunu yoktur çünkü anahtar zaten yok.
in-toto Attestation ve Provenance Zinciri
in-toto, NYU ve Purdue araştırması olarak başlayan ve CNCF Graduated proje olan tedarik zinciri framework’üdür; “kim, neyi, nasıl, hangi koşullarda üretti” sorularına şifreleme ile cevap verir. SLSA provenance, in-toto Attestation Framework v1.0’a göre tanımlanır. cosign attestation, predicate alanında SLSA provenance, SBOM, SARIF veya VEX taşıyabilir; tek standart zarf (DSSE) çoklu içerik tipini destekler.
| Predicate | İçerik | Üretici | Tüketim |
|---|---|---|---|
| SLSA Provenance v1.0 | Builder, build type, invocation, materials, byproducts | slsa-github-generator, BuildKit, Tekton Chains | Admission controller, policy engine |
| SPDX/CycloneDX SBOM | Bileşen envanteri | Syft, cdxgen, Trivy | Dependency Track, GUAC |
| VEX | CVE etkilenme durumu (affected/not_affected/fixed/under_investigation) | OpenVEX, vexctl | Scanner false-positive azaltma |
| SARIF | Statik analiz bulguları | CodeQL, Semgrep, Trivy | GitHub Advanced Security, dashboard |
| Scorecard | OSS proje güvenlik puanı | OpenSSF Scorecard action | Tedarikçi seçim filtresi |
| Test results | Junit/Coverage | Witness, Tekton Chains | Release gate |
VEX, GUAC ve Zafiyet Triyajı
SBOM tek başına gürültülü bir envanterdir; bir bağımlılığın varlığı, gerçek istismar edilebilirlik anlamına gelmez. VEX (Vulnerability Exploitability eXchange), bir bileşenin bilinen CVE’den etkilenip etkilenmediğini ve gerçek koşullarda sömürülebilir olup olmadığını belirten makine okunabilir standarttır. CycloneDX VEX, OpenVEX ve CSAF VEX olmak üzere üç format yaygın; üçü de affected, not_affected (with justification), fixed ve under_investigation durumlarını paylaşır.
| Araç | Tip | Güçlü yan | Tipik konum |
|---|---|---|---|
| Trivy (Aqua) | Scanner + SBOM üretici | Container, IaC, OS package, secret tarama; çok düşük false positive | CI gate, runtime DaemonSet |
| Grype (Anchore) | Vulnerability scanner | Syft SBOM ile uyumlu, offline çalışma | Air-gapped ortam |
| Snyk | SaaS scanner | Reachability analizi, IDE entegrasyonu | Geliştirici masaüstü + PR check |
| Dependency-Track (OWASP) | SBOM yönetim platformu | Sürekli izleme, policy engine, OSV/NVD entegre | Kurumsal envanter merkezi |
| GUAC | Graf veritabanı | SBOM/VEX/attestation/scorecard birleşik sorgu | Tedarik zinciri analitiği |
| JFrog Xray / Sonatype Lifecycle | Ticari platform | Artifact repository entegre policy gate | Kurumsal repository |
| OpenSSF Scorecard | OSS sağlık değerlendirme | 21 otomatik kontrol (CI, branch protection, dangerous workflow) | Tedarikçi seçimi |
Synopsys 2025 Open Source Security Risk raporu, VEX kullanan kurumlarda zafiyet triyaj süresinin yüzde 47 düştüğünü ve “yapılması gereken iş” backlog’unun yüzde 63 azaldığını gösterir. GUAC (Graph for Understanding Artifact Composition), 2025’te CNCF Incubating seviyesine ulaştı ve birden çok kaynaktan gelen SBOM, VEX ve scorecard verisini bir graf üzerinde birleştirerek “Log4j etkilenen tüm üretim deployment’larım hangileri?” tipi soruları milisaniyelerde yanıtlıyor.
Regülasyon Takvimi: EO 14028, EU CRA, NIS2
SBOM ve SLSA artık iyi-niyetli bir öneri değil, çoklu yargı bölgelerinde bağlayıcı yükümlülük. ABD’de Executive Order 14028, NIST SSDF (SP 800-218) çerçevesini federal alımlarda zorunlu kıldı; AB’de Cyber Resilience Act 11 Aralık 2024’te yürürlüğe girdi ve 2027 sonbaharında tam uygulamaya geçecek. Türkiye BTK’nın bilgi ve iletişim güvenliği rehberi kritik altyapı tedarikçileri için SBOM teslimini 2025’te referans olarak ekledi.
| Düzenleme | Bölge | Yürürlük | SBOM zorunluluğu | SLSA/imza beklentisi |
|---|---|---|---|---|
| EO 14028 + OMB M-22-18 / M-23-16 | ABD federal | Haziran 2023+ | Self-attestation + makinece okunabilir SBOM | NIST SSDF SP 800-218 uyumu |
| NIST SSDF (SP 800-218) | Global referans | Şubat 2022 (v1.1) | Üretim önerisi | Provenance + integrity gerekleri |
| EU Cyber Resilience Act (CRA) | 27 AB üyesi | 11 Aralık 2024 yürürlük, 11 Aralık 2027 tam uygulama | Üretici tarafından SBOM tutulması zorunlu | Güvenli geliştirme süreci kanıtı |
| EU NIS2 Directive | 27 AB üyesi | 17 Ekim 2024 transposition deadline | Tedarik zinciri risk yönetimi şart | İmzalı yazılım kanıtı önerilir |
| EU AI Act | 27 AB üyesi | 2 Ağustos 2026 GPAI yükümlülükleri | ML-BOM (model envanteri) gerekiyor | Eğitim verisi provenance |
| UK PSTI | İngiltere | 29 Nisan 2024 | IoT ürünleri için zorunlu | Güvenli geliştirme bildirimi |
| BTK BIG Rehberi | Türkiye | 2025 güncellemesi | Kritik altyapı için referans | İmza ve hash doğrulama önerisi |
CRA’nın asıl yıkıcı tarafı sorumluluğu açık kaynak bakımcısına değil ürünü piyasaya sunan üretici (manufacturer) ve “açık kaynak yazılım yöneticisine” (steward) yüklemesidir. Aktif olarak istismar edilen zafiyeti ENISA’ya 24 saat içinde bildirmek artık yasal yükümlülük; 5 yıl boyunca güvenlik güncellemesi sağlamak ürün ömrünün asgari taban koşulu. Zero Trust mimari ve Kubernetes Network Policy bu uyum yükümlülüklerinin çalışma zamanı tamamlayıcılarıdır.
Kurumsal Uygulama Yol Haritası
Tedarik zinciri güvenliğini bir araç sorunundan kurumsal programa çevirmek için aşamalı, ölçülebilir bir yol haritası gerekir. Gartner 2025 öngörüsüne göre 2027 sonunda Fortune 500 şirketlerinin yüzde 60’ı SBOM ve SLSA tabanlı tedarikçi denetim politikalarını sözleşme şartı yapacak. Penetration testing süreci ve Crossplane / Terraform IaC bu yol haritasının yan kuvvetleridir.
- Envanter ve sahiplik (0-30 gün): Tüm üretim uygulamalarını, mikroservislerini ve container image’larını listele; her birinin sahibini ve kritiklik seviyesini ata.
- SBOM üretimi (30-60 gün): Syft, cdxgen veya Trivy ile CI pipeline’a SBOM adımı ekle; her PR’da source SBOM, her merge’de build SBOM üret.
- İmzalama ve attestation (60-90 gün): cosign keyless ile container ve SBOM’u imzala; slsa-github-generator veya BuildKit provenance ile L2 attestation üret.
- Saklama ve dağıtım (90-120 gün): SBOM’ları OCI registry’de referrer artifact olarak tut; dış paylaşım için imzalı erişim kanalı kur.
- Sürekli izleme (120-180 gün): Dependency-Track veya GUAC ile yeni CVE’leri envanterle eşleştir; VEX ile triyaj sürecini otomatikleştir.
- Admission ve policy (180-240 gün): Kubernetes policy-controller veya Kyverno ile imzasız ve SLSA L2 altı image’ları üretime reddet.
- Tedarikçi sözleşmeleri (240-300 gün): Tüm yeni ve yenilenen yazılım alım sözleşmelerine “her sürümle birlikte CycloneDX 1.6 SBOM + cosign imza” maddesi ekle.
- SLSA L3 yükseltme (300-365 gün): Kritik üretim pipeline’ları için ephemeral runner, izole build host ve non-falsifiable provenance üretimi.
Yaygın Tuzaklar ve Anti-Pattern’ler
SBOM ve SLSA programları çoğu zaman teknik değil organizasyonel nedenlerle başarısız olur. Sonatype State of the Software Supply Chain 2025 verilerine göre SBOM üreten kurumların yüzde 43’ü ürettiği belgeyi hiç kullanmıyor; yüzde 28’i tek seferlik bir compliance teslim olarak görüyor. Bu, “SBOM tiyatrosu” olarak adlandırılan tipik anti-pattern’dir.
- Manuel SBOM: Excel dosyasında elle tutulan bağımlılık listesi; ilk gün eskimiş, hiç güvenilemez.
- Sadece source SBOM: Build sırasında eklenen transitive ve container layer bağımlılıkları kaçırılır; üretim gerçeği yansımaz.
- İmzasız SBOM: İçeriğin değiştirilmediğine dair kanıt yok; tedarik zinciri saldırganı SBOM’u da tahrif edebilir.
- VEX’siz tarama: Her tarama yüzlerce CVE bulur, ekip yorgunluğu nedeniyle gerçek tehditler gözden kaçar.
- SBOM tek seferlik: Her sürümde yeniden üretilmeyen SBOM, “kullandığım” yazılımla ilgili değildir.
- Tedarikçi kara delik: SBOM toplanır ama imzaları doğrulanmaz, içeriği analiz edilmez, sadece arşivlenir.
- SLSA seviyesini görsel olarak ilan etmek: README’de “SLSA L3” rozeti var ama gerçek provenance üretilmiyor; doğrulama yok.
Sık Sorulan Sorular
SBOM her yazılım projesinde üretilmeli midir?
Evet ve maliyet artık ihmal edilebilir seviyede. CI pipeline’a eklenen Syft veya Trivy adımı tipik bir build süresine 5-15 saniye katar ve CycloneDX 1.6 + SPDX 3.0 formatlarını paralel üretir. Üretilmemesi durumunda kurumsal müşteri sözleşmeleri, kamu ihaleleri (özellikle ABD federal ve 2027 sonrası AB CRA kapsamı), denetim ve siber sigorta yenileme süreçlerinde uyum sorunları doğar. Açık kaynak projelerde bile SBOM üretimi ve Scorecard kaydı, tedarikçi seçim filtresinde projenin değerlendirilme şansını artırır.
SLSA Build L3’e ulaşmak ne kadar zaman ve maliyet alır?
Olgun bir DevSecOps pratiğine sahip ekipler için 3-6 ay tipiktir, sıfırdan başlayan kurumlar için 9-12 ay gerçekçi. Süreç; build sunucusunun izolasyonu, GitHub Actions reusable workflow veya Tekton Chains’in benimsenmesi, ephemeral runner kullanımı, slsa-github-generator ile non-falsifiable provenance üretimi ve attestation saklama adımlarını içerir. GitHub Actions kullanan ekipler için ek altyapı maliyeti yok; self-hosted ekipler için izole runner pool kurulumu ana yatırım. Build L4 (eski 4. seviyenin reproducible build kısmı) topluluğun büyük çoğunluğu için pratik dışı kalmaya devam ediyor.
CycloneDX ve SPDX birlikte mi kullanmalı, biri yeterli mi?
Modern toolchain (Syft, cdxgen, Trivy) tek bir tarama girdisinden her iki formatı paralel üretebilir ve ek yük neredeyse sıfırdır. Pratik öneri: iç güvenlik ekipleri ve VEX entegrasyonu için CycloneDX 1.6’yı birincil; lisans uyumu, kamu raporlaması ve OpenChain ISO/IEC 5230 süreci için SPDX 3.0’ı paralel üret. CRA kapsamında Avrupa pazarına ürün satan üreticiler için her iki formatı sağlamak en güvenli yoldur; çünkü düzenleyici otoritelerin tercih ettiği format ürün kategorisine göre değişebiliyor.
SBOM tedarikçilerle nasıl paylaşılır ve gizlilik korunur?
Tipik kanallar: yazılım teslim paketine SBOM’un eklenmesi, OCI registry’de OCI 1.1 referrers API üzerinden imzalı artifact olarak yayınlanması, müşteri portalında indirilebilir hale getirilmesi veya CISA “Framing SBOM Sharing” çerçevesindeki access control modellerinin uygulanması. Gizlilik kaygıları (içsel kütüphane adları, modül isimleri) için CycloneDX “redacted” alanları veya SBOM’u sözleşmeli güven üçgeni üzerinden sadece denetlenmiş paydaşlarla paylaşmak uygun yoldur. Kritik altyapı tedarikçileri için sözleşmelere “her sürümle birlikte güncel SBOM ve imzalı provenance” maddesi 2025’te standart hale geldi.
Container ve AI/ML iş yükleri için SBOM nasıl üretilmeli?
Container için Syft veya Trivy ile multi-layer SBOM (her image layer için ayrı bileşen tespit) üretip OCI registry’de referrer olarak ekleyin; cosign attest komutuyla SBOM ve SLSA provenance’ı aynı OCI artifact’a bağlayabilirsiniz. AI/ML iş yükleri için CycloneDX ML-BOM (Machine Learning BOM) profili kullanın: model dosyası hash, eğitim veri seti referansı (datasheet), framework sürümü, eval metrikleri ve lisans bilgisini tek yapıda toplar; bu özellikle EU AI Act 2 Ağustos 2026 GPAI yükümlülükleri için kritik. Modeli üreten pipeline da SLSA Build track’inde imzalanmalı.
Sonuç: Olgunluk Skoru ve 2026 Önerimiz
SBOM ve SLSA, 2026 yazılım tedarik zinciri güvenliğinin temelini oluşturuyor ve EO 14028, EU CRA, NIS2 ile düzenleyici beklentilerin yanı sıra Fortune 500 kurumsal alım kararlarının ayrılmaz parçası haline geldi. Olgunluk değerlendirmemiz net: SBOM üretimi her ekip için minimum baz (L0 – “olmazsa olmaz”), cosign keyless imzalama ile L1 attestation production-ready (yüksek olgunluk, düşük maliyet), SLSA Build L2 hosted CI kullanan herkesin hedefi (yüksek olgunluk, sıfır ek altyapı), SLSA Build L3 kritik üretim sistemleri için tavsiye edilen yatırım (orta olgunluk, izole runner gerekir). VEX ile zenginleştirilmiş Dependency-Track veya GUAC tabanlı sürekli analiz, “SBOM tiyatrosu”ndan kaçınmanın tek yoludur; tek seferlik bir compliance teslim değil, sürekli işleyen bir programdır.
Verdict: 2026’da SBOM + cosign + SLSA Build L2 minimum standart kabul edilmeli; üretim ve uyum riskini gerçek anlamda azaltmak isteyen kurumlar bunun üstüne VEX, GUAC ve SLSA Build L3 katmanlarını eklemeli. Erken benimseme, yalnızca düzenleyici uyum riskini değil, ihale kazanma şansını, siber sigorta primini ve gerçek saldırı yüzeyini belirgin biçimde iyileştirir; geç kalanlar için 2027 CRA tam uygulama tarihi sert bir uyanış olacak.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.