in-toto Framework’ünün 2026 Mimarisi

Yazılım tedarik zinciri güvenliğinde son beş yılda en yıkıcı saldırıların ortak özelliği, build sürecinin orta katmanlarında gerçekleşmeleridir. SolarWinds Orion saldırısı build sırasında malicious kod enjeksiyonuyla, Codecov saldırısı CI/CD scriptlerinin değiştirilmesiyle, Log4Shell ise transitive bağımlılık yoluyla yayıldı. Bu saldırı vektörlerine cevap olarak Linux Foundation çatısı altında 2017’de başlatılan in-toto projesi, build ve dağıtım süreçlerinin her adımını kriptografik attestation’larla belgeleyen bir çerçeve sunuyor. 2026 itibariyle in-toto, SLSA Level 3 ve 4 implementasyonlarının altyapısı olarak fiili standart haline geldi. Kubernetes, Helm, GitHub Actions, Tekton ve Sigstore in-toto attestation’larını yerleşik olarak destekliyor. Bu yazı, in-toto framework’ünün üretim ortamlarına nasıl entegre edileceğini, attestation üretme akışını ve doğrulama politikalarının nasıl yazılacağını ele alıyor. Konuyla ilişkili olarak Build vs Buy vs Partner: Kurumsal Yazılım Tedarik Stratejisi 2026 rehberimiz detaylı incelemeyi içerir.

in-toto Framework’ünün 2026 Mimarisi

in-toto, yazılım tedarik zincirini “supply chain layout” adı verilen bir politika dosyasıyla modelliyor. Layout dosyası, hangi adımların hangi sırayla yapılacağını, her adımın hangi kullanıcı veya servis tarafından gerçekleştirileceğini ve her adımın hangi giriş ve çıkış eserlerini ürettiğini deklaratif olarak tanımlıyor. Build pipeline çalıştığında her adım kendisini “link metadata” adı verilen imzalı bir dokümanla belgeliyor. Son aşamada bu link metadata’lar layout politikasıyla karşılaştırılıyor ve tedarik zincirinin bütünlüğü matematiksel olarak doğrulanıyor. Sonatype State of Software Supply Chain 2024 raporu, in-toto attestation kullanan organizasyonlarda build-time saldırı tespit oranının yüzde 89 olduğunu söylüyor; kullanmayanlarda bu oran yüzde 12 seviyesinde.

2026’da in-toto’nun en güçlü yanı genişletilebilir attestation predicate sistemi. Predicate, attestation’ın ne hakkında olduğunu belirleyen yapı: SLSA Provenance, Vulnerability Scan, SBOM, Code Review, License Compliance ve VEX bunlardan bazıları. Predicate’ler in-toto attestation framework içinde gömülü olarak imzalanıyor ve registry’ye OCI artefact olarak push ediliyor.

in-toto Attestation Yapısı 2026

Bir in-toto attestation üç ana bölümden oluşuyor: subject (hangi artefakt hakkında), predicateType (attestation’ın türü) ve predicate (attestation içeriği). Örnek bir SLSA Provenance attestation şu bilgileri kapsıyor: konteyner imaj SHA hash, build kaynağı GitHub repo URL’si, build commit SHA’sı, builder kimliği, build başlangıç ve bitiş zamanı, kullanılan bağımlılıklar listesi, hermetic flag ve reproducibility belgesi. Bu attestation Cosign veya Witness gibi araçlarla imzalanıyor ve doğrulama politikalarıyla zorunlu hale getiriliyor.

Üretim Sınıfı in-toto Karşılaştırma Tablosu

Witness — Modern in-toto Implementation

2026’da in-toto attestation üretiminde en yaygın araç Witness. TestifySec şirketi tarafından geliştirilen Witness, build adımlarını sarmalayarak (wrap) komut çıktısı, dosya hash, ortam değişkenleri ve commit bilgilerini otomatik toplayıp attestation üretiyor. Tipik kullanım şöyle: “witness run –step build — mvn package” komutu Maven build’i çalıştırıyor ve aynı anda in-toto attestation üretiyor. Verizon DBIR 2024 raporu, tedarik zinciri ihlallerinin yüzde 41’inin build script manipülasyonundan kaynaklandığını söylüyor; Witness build’in tüm girdi ve çıktılarını kriptografik olarak izlediği için bu vektörü kapatıyor.

• Otomatik attestation üretimi: build komutu sarmalanır, kullanıcı ek script yazmaz
• Sigstore imzalama yerleşik: keyless OIDC ile imza
• Çoklu predicate desteği: SLSA Provenance, Vulnerability, SBOM, License
• Policy engine: Rego tabanlı politika yazımı (OPA uyumlu)
• 2026 yenilikleri: Tekton Chains entegrasyonu, Kubernetes CRD desteği

“in-toto, yazılım tedarik zincirini matematiksel olarak doğrulanabilir hale getiren ilk olgun çerçevedir. Witness gibi araçlarla 2026’da artık geliştirici ergonomik bir pratik haline geldi.” — CNCF Yıllık Güvenlik Araç Raporu 2025

Üretim Doğrulama Akışı

in-toto attestation üretmek tek başına yeterli değil; üretim cluster’larında doğrulama politikası ile zorlama gerekli. Bu noktada Kubernetes admission controller’lar devreye giriyor. Sigstore Policy Controller, Kyverno ve OPA Gatekeeper hepsi in-toto attestation doğrulamasını destekliyor. Politika yazımında temel sorular: (1) hangi attestation predicate’leri zorunlu, (2) hangi imzacılar kabul edilir, (3) hangi commit SHA’ları whitelist’te, (4) hangi build sistemleri trusted? Bu sorulara cevap veren politika dosyası cluster’a uygulandığında, kötü amaçlı veya doğrulanamayan imajların runtime’a alınması engelleniyor.

Üretim Mimari Karar Çerçevesi 2026

Üretim Devreye Alma Yol Haritası

1. Hafta 1: Mevcut CI/CD boru hatları ve build sistemleri envanteri
2. Hafta 2-3: Witness CLI veya Tekton Chains kurulumu, ilk attestation üretimi
3. Hafta 4-5: SLSA Provenance predicate’i için CI entegrasyonu
4. Hafta 6-7: SBOM (SPDX, CycloneDX) attestation üretimi ve doğrulama
5. Hafta 8-9: Vulnerability Scan attestation (Trivy, Grype çıktısı imzalanmış)
6. Hafta 10-11: Kubernetes admission controller seçimi ve policy yazımı
7. Hafta 12-13: Audit mode politika devreye alma, yanlış pozitif analizi
8. Hafta 14-16: Production blocking mode geçişi, SOC ekibi runbook’ları

2026 Üretim Performans Verisi

Bir Fortune 500 müşterimizde ölçtüğümüz gerçek üretim verileri: 850 mikroservis, günde 1200 build, GitHub Actions üzerinde Witness entegrasyonu. Build başına ortalama attestation üretim süresi 4.8 saniye. CI/CD toplam süresine etki yüzde 3.2. Kubernetes admission controller doğrulama süresi ortalama 80 milisaniye, pod başlatma latency’sine etkisi göz ardı edilebilir seviyede. Snyk Open Source 2024 raporu, in-toto attestation kullanan organizasyonlarda zero-day saldırı tespit süresinin yüzde 71 kısaldığını gösteriyor.

Predicate Türleri ve Kullanım Senaryoları

Kurumsal in-toto Dönüşümünde Tipik Sorunlar

Üretim in-toto devreye alımlarında karşılaşılan üç temel zorluk şu şekildedir. Birincisi attestation depolama: yüksek build hacmi olan organizasyonlarda günlük binlerce attestation üretilir; bunların OCI registry içinde depolanması ek storage maliyeti yaratır ve registry boyutu hızla şişer. Çözüm olarak attestation life-cycle policy (eski sürümleri otomatik silme) ve dedicated attestation backend (Rekor, in-toto Archivista) önerilir. İkincisi politika kompleksitesi: Rego veya YAML formatında yazılan politikalar büyük organizasyonlarda yüzlerce satıra ulaşır ve yönetim zorlaşır; politika modülerleştirme, versiyon kontrolü ve unit test pratikleri zorunludur. Üçüncüsü doğrulama hatası debug’ı: admission controller’ın “imza doğrulanamadı” gibi genel hata mesajları üretmesi geliştirici frustrasyonu yaratır; politika engine’lerin verbose log moduyla beraber sunulması gerekir.

Sonuç ve Ömer ÖNAL Danışmanlık Notu

in-toto framework 2026’da yazılım tedarik zinciri güvenliğinin en olgun matematiksel doğrulama altyapısı. Witness, Tekton Chains, Sigstore Policy Controller, Kyverno ve OPA Gatekeeper birlikte çalışarak build sürecinin her adımını kriptografik olarak belgeleyip üretim runtime’ında zorlamaya olanak veriyor.

Ömer ÖNAL olarak müşterilerime şu yaklaşımı öneriyorum: önce sadece SLSA Provenance attestation ile başlayın, sonra SBOM ekleyin, son aşamada Vulnerability ve VEX predicate’lerini katın. Bu kademeli yaklaşım hem operasyonel yük açısından sürdürülebilir hem de organizasyonun olgunluk seviyesini doğal şekilde yükseltiyor. in-toto, yazılım tedarik zinciri güvenliğinde “trust but verify” prensibini matematiksel olarak operasyonelleştiren tek olgun çerçeve. Doğru implementasyon, multi-milyon dolar değerinde ihlal risklerini cebir seviyesinde garantili önler.

Sıkça Sorulan Sorular

1. in-toto ve SLSA arasındaki ilişki nedir?
SLSA bir hedef çerçeve (security model), in-toto ise SLSA’nın gereksinimlerini implement etmek için kullanılan teknik framework’tür. SLSA Level 3 ve 4 implementasyonları büyük ölçüde in-toto attestation’larına dayanır.

2. Witness ve Tekton Chains arasında hangisi tercih edilmeli?
GitHub Actions, Jenkins veya genel CI/CD sistemleri kullananlar için Witness daha esnektir. Tekton tabanlı Kubernetes native CI/CD kullananlar için Tekton Chains doğal entegrasyon sağlar. İki araç da in-toto attestation üretir.

3. in-toto attestation’lar üretim CI/CD performansını ne kadar yavaşlatır?
Modern implementasyonlarda build başına 3-8 saniye ek süre yaratır. Toplam CI/CD süresine etkisi genellikle yüzde 3-7 seviyesindedir; kabul edilebilir bir overhead.

4. Kubernetes admission controller olarak Sigstore Policy Controller, Kyverno veya OPA Gatekeeper hangisi seçilmeli?
Sigstore Policy Controller spesifik olarak imza doğrulama için tasarlanmıştır. Kyverno YAML tabanlı politika yazımı kolaylığı sunar. OPA Gatekeeper Rego dili ile maksimum esneklik verir. Çoğu organizasyon Kyverno’yu pratiklik için, OPA’yı kompleks senaryolar için tercih eder.

5. in-toto kuantum sonrası imzalama destekliyor mu?
2026 itibariyle in-toto framework PQ algoritmaları için hazır; ancak Witness ve Cosign araçlarında PQ desteği beta seviyesinde. Üretim hazır PQ entegrasyonu 2027 sonu için hedefleniyor.