Yazılım tedarik zinciri saldırıları 2024’te yüzde 156 büyüdü (Sonatype State of the Software Supply Chain 2024); SLSA Level 4 attestation pratiği kurumsal CI/CD’nin en güçlü savunma katmanını oluşturuyor.
SLSA Framework 2026: Levels, Tracks ve Pazar Bağlamı
Supply-chain Levels for Software Artifacts (SLSA), Google’ın iç “Borg” deneyimini OSSF (Open Source Security Foundation) altında 2021’de açık standarda dönüştürdüğü tedarik zinciri olgunluk çerçevesidir. v1.0 spec’i 2023 Nisan’da yayınlandı, v1.1 ise 2024 Kasım’da production-ready hale geldi. Çerçeve “Build” ve “Source” track’lerine ayrıldı; Build track Level 0’dan Level 4’e kadar artan kontrol seviyeleri tanımlıyor. Konuyla ilişkili olarak Modern Build Sistemleri: Bazel vs Buck2 vs Pants Karşılaştırması rehberimiz detaylı incelemeyi içerir.
Pazar bağlamı ciddi: ENISA Threat Landscape 2024 raporu yıl içinde 250’den fazla “software supply chain” olayını dokumante etti, ortalama tespit süresi 35 gün. XZ Utils backdoor (CVE-2024-3094) sosyal mühendislik tabanlı bir tedarik zinciri saldırısı olarak 2024 Mart’ta keşfedildi ve milyonlarca Linux sistemini etkileyebilirdi. SolarWinds (2020), Codecov (2021), 3CX (2023) ve Sisense (2024) olayları SLSA Level 3+ kontrollerin neden zorunlu olduğunu kanıtlıyor. CISA, NIST SSDF (SP 800-218) ve OMB M-22-18/M-23-16 memo’ları federal sistemler için SLSA seviyesinde tedarikçi attestation’ı talep ediyor.
SLSA Build Track Seviyeleri Karşılaştırması
SLSA seviyeleri kümülatiftir: her üst seviye alt seviyenin kontrollerini içerir ve üzerine yeni gereksinimler ekler. Level 4 “Hermetic builds” gerektirir — build sırasında hiçbir dış kaynağa internet üzerinden erişim yoktur ve tüm bağımlılıklar önceden belirlenmiş, hash’i doğrulanmış kaynaklardan gelir. Build platform’un kendisi de “tamper-evident” (manipülasyon kanıtlı) olmak zorunda.
| SLSA Seviye | Build Provenance | Hosted Build | Build Isolation | Hermetic | Typical CI |
|---|---|---|---|---|---|
| Level 0 | Yok | Yok | Yok | Hayır | Local make |
| Level 1 | Otomatik üretiliyor | Tercihen | Yok | Hayır | Jenkins basic |
| Level 2 | İmzalı + auth’d | Zorunlu | Yok | Hayır | GitHub Actions OIDC |
| Level 3 | Non-falsifiable | Zorunlu | Tam izolasyon | Hayır | SLSA GitHub generator |
| Level 4 | Two-party review | Zorunlu | Tam izolasyon | Evet, dependency hash | Bazel + air-gapped |
Provenance Şeması ve in-toto Attestation İlişkisi
SLSA provenance, in-toto Attestation Framework üzerinde “SLSA Provenance Predicate” olarak tanımlanır. Provenance dosyası şu alanları içerir: builder kimliği (örn. https://github.com/actions/runner), build türü, çağrılan recipe, materials (source repo + tag + commit hash), ve metadata (start/end time, completeness, reproducible flag). Bu doküman Sigstore Cosign veya Notary v2 ile imzalanır ve OCI registry’ye artifact ile beraber push edilir.
- Subject: Artifact hash (sha256) — provenance hangi artifact’ı tanımlıyor
- Builder ID: Build platform URI’sı + sürüm — kim build etti
- BuildType: Recipe tipi (GitHub Actions workflow, Tekton task, Bazel rule)
- Invocation: Çağrı parametreleri, env, config kaynakları
- Materials: Input artifact’lar ve repo’lar — sha256 hash zincirli
İlgili konu: in-toto attestation build provenance rehberi
Level 3 ve 4 Implementation Pattern’ları
SLSA Level 3’ün en pratik yolu GitHub Actions üzerinden slsa-framework/slsa-github-generator reusable workflow’larını kullanmak. Bu generator OIDC tabanlı keyless imzalama ile Sigstore Fulcio ve Rekor’a otomatik attestation push eder. GitLab tarafında “Pipeline Authentication” 2024 itibarıyla SLSA L3 destekli; CircleCI ise OIDC ve attestation pipeline’ı 2024 Q3’te tamamladı. Level 4 için Bazel veya Nix gibi hermetic build sistemleri ve internal yetkilendirilmiş build platform gerekir; Google iç ekosisteminde Borg ve Bazel kombinasyonu standart.
Kubernetes admission tarafında Sigstore Policy Controller SLSA provenance doğrulaması yapan policy’leri destekliyor. Kyverno 1.12+ “Verify Images” rule’u SLSA L3 attestation’ı doğrulayabiliyor. Bu sayede production cluster’a sadece SLSA L3 imzalı image’ların deploy olması garanti altına alınıyor. Sigstore’un OpenSSF altında olgunlaşması ve CNCF Graduated statüsüne ulaşması 2025’in en önemli güvenlik adımlarından biri.
Operasyon, Compliance ve ROI Profili
SLSA adopsiyonu başlangıçta CI/CD süresini yüzde 10-25 uzatıyor (attestation oluşturma, imzalama, registry’ye push). Maliyet boyutunda CI dakika başına 0,002-0,008 USD ek yük (provider’a göre değişir). Buna karşılık tedarik zinciri ihlali ortalama maliyeti 4,46 milyon dolar (IBM Cost of a Data Breach 2024); ROI açıkça pozitif. ABD Federal kurumlar OMB M-22-18 ile tedarikçilerden self-attestation talep ediyor; AB tarafında Cyber Resilience Act (CRA) 2027 sonu yürürlük takvimiyle SBOM ve SLSA benzeri attestation’ı zorunlu kılıyor.
| Metrik | SLSA L1 | SLSA L2 | SLSA L3 | SLSA L4 |
|---|---|---|---|---|
| CI süre etkisi | +%2-5 | +%5-12 | +%10-25 | +%20-40 |
| Maliyet/build | ~$0,001 | ~$0,003 | ~$0,008 | ~$0,015 |
| Implementasyon süresi | 1-2 hafta | 4-8 hafta | 3-6 ay | 6-12 ay |
| Saldırı yüzeyi azaltma | ~%20 | ~%45 | ~%75 | ~%92 |
| Federal uyum | Yetersiz | Kısmi | Yeterli | Tam |
Sektörel Uygulamalar: Finans, Kamu, Sağlık
Kanada Hükümeti dijital servis tedarikçilerinden 2025 itibarıyla SLSA L3 self-attestation talep ediyor. ABD Department of Defense (DoD) DevSecOps Reference Design 2.0 SLSA L3’ü “tercih edilen” seviye olarak tanımlıyor. Finansal sektörde SWIFT Customer Security Programme (CSP) 2024 controls güncellemesi tedarik zinciri attestation’ı için SLSA’ya atıf yapıyor. Türk bankacılığında BDDK Bilgi Sistemleri Yönetmeliği güncellemeleri 2025’te “üçüncü taraf yazılım kalitesi” maddesini güçlendirdi. SLSA resmi sitesi case study’leri derliyor; SLSA GitHub repository spec ve tooling barındırıyor.
Kurumsal SLSA L4 Yolculuğunda Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Hermetic build için bağımlılık problemleri: npm/PyPI’den dinamik fetch yapan build script’leri L4 için yeniden yazılmak zorunda; Bazel veya Nix migration aylar sürüyor
- Two-party review enforcement: Branch protection rule ile zorunlu kılınsa da büyük ekiplerde “self-approve” boşlukları açılıyor
- Provenance signature key yönetimi: Keyless OIDC kullanılmadığında HSM tabanlı key rotation operasyonu zorlu
- Legacy CI sistemleri: Jenkins veya Bamboo gibi platformlar SLSA L3 için extensive custom work istiyor; modern CI’ya migration daha hızlı
- Internal tooling registry’si yok: Üçüncü taraf action/plugin’ler attest edilmeden kullanılıyor; tedarik zinciri delik kalıyor
- Compliance reporting: Provenance var ama kuruma rapor üretecek dashboard yok; Falco, OpenSearch veya Grafana ile özel panel gerekiyor
Sonuç
SLSA Level 4, kurumsal yazılım tedarik zincirinin en güçlü savunma katmanı. 2026 itibarıyla Federal regülasyon, AB Cyber Resilience Act takvimi, finansal denetim çerçeveleri ve siber sigorta beklentileri SLSA L3-L4 seviyesini “olgun kurumsallık” göstergesi haline getirdi. Pratik yol haritası: önce mevcut CI’ya provenance üretimi ekleyin (Level 1), GitHub Actions reusable workflow’larıyla L2’ye geçin, sigstore-policy-controller ile production policy enforcement ekleyerek L3’ü kapatın, ardından kritik mission-critical pipeline’lar için Bazel veya Nix hermetic build’ler ile L4’e ilerleyin. 12-18 ay süren bu yolculuk hem regülasyon uyumunu hem de XZ Utils benzeri sosyal mühendislik saldırılarına karşı görünürlüğü sağlıyor. SLSA yatırımı en yüksek ROI’li güvenlik harcaması olarak öne çıkıyor.
Sıkça Sorulan Sorular
SLSA Level 3 ile Level 4 arasındaki en önemli fark nedir?
Level 3 build platformun manipülasyon kanıtlı ve izole olmasını gerektirirken, Level 4 buna ek olarak hermetic build (tüm bağımlılıklar önceden belirli, internet yok) ve two-party review zorunluluğu getiriyor. L4 saldırı yüzeyini yüzde 92’ye kadar azaltıyor.
GitHub Actions ile SLSA Level 3 nasıl elde edilir?
slsa-framework/slsa-github-generator reusable workflow’larını çağırmak yeterli. Bu generator OIDC tabanlı keyless Sigstore imzasıyla Rekor’a otomatik attestation push eder. Mevcut build workflow’una 10-15 satır YAML eklemekle L3 elde edilebilir.
SLSA provenance’ı production’da nasıl enforce ederiz?
Kubernetes admission tarafında Sigstore Policy Controller veya Kyverno “Verify Images” rule’u SLSA provenance doğrulaması yapar. Doğrulanamayan image’lar pod’a deploy edilemez. OCI registry tarafında Harbor 2.10+ SLSA L3 attestation görüntülüyor.
SLSA Level 4 için Bazel zorunlu mu?
Hayır, ama hermetic build için Bazel, Nix, Buck2 gibi sistemler en olgun çözümler. Custom Docker BuildKit tabanlı çözümler de mümkün ancak operasyon yükü daha yüksek. Google’ın iç deneyimi Bazel temelli; CNCF ekosisteminde Buildbarn ve BuildBuddy gibi remote execution servisleri popüler.
Türk şirketleri SLSA’yı ne zaman ciddiye almalı?
AB pazarına yazılım satan veya AB müşterilerine SaaS sunan Türk şirketleri için Cyber Resilience Act (CRA) 2027 sonu yürürlük öncesinde SLSA L3 hazırlığı şart. Yerel olarak BDDK Bilgi Sistemleri Yönetmeliği ve KVKK güvenlik tedbirleri SLSA atıflarını artırıyor.
Ömer Önal
Mayıs 23, 2026SLSA Level 4 kurumsal yazılım tedarik zincirinin en yüksek olgunluk seviyesi. XZ Utils ve SolarWinds gibi olaylar Level 3-4 kontrollerinin neden zorunlu olduğunu kanıtladı. Türk şirketleri AB Cyber Resilience Act 2027 takvimi öncesinde Level 3 hedefi koymalı; GitHub Actions reusable workflow’ları ile bu seviyeyi 4-8 haftada elde edebiliyor. Level 4 için Bazel veya Nix tabanlı hermetic build mimari değişikliği gerektiriyor ve 6-12 aylık bir program.