in-toto Attestation Framework v1.0 spec’inin OSSF altında olgunlaşmasıyla birlikte, 2025’te Sigstore ekosistemine entegre projeler yüzde 312 büyüdü (CNCF Annual Report 2024); build provenance ve compliance audit pratiği için fiili standart haline geldi.
in-toto 2026: Kavramsal Çerçeve ve Pazar Bağlamı
in-toto, NYU Tandon School of Engineering’den çıkan ve OpenSSF altında olgunlaşan bir framework. Yazılım tedarik zincirinin her adımının (clone, build, test, package, sign, publish) “step” olarak tanımlandığı ve her adımın “link” attestation’ı ürettiği bir layout sistemi sunuyor. Final artifact tüm link’lerin layout’la uyumlu olduğunu doğrulanabilir biçimde gösteriyor. CNCF Incubating projesi olan in-toto, 2024’te yedi sürüm yayınladı ve in-toto.io üzerinde resmi dokümantasyonu tutuyor.
Pazar bağlamı güçlü: ENISA Threat Landscape 2024 raporu tedarik zinciri saldırılarının 2023’e göre yüzde 156 arttığını gösterdi (sayfa 41). Sonatype 2024 raporu PyPI ve npm üzerinde 512.847 malicious package tespit etti. in-toto Attestation Framework v1.0 (2024 yayını) “Statement”, “Predicate”, “Subject” üçlüsüyle attestation’ları formalize ediyor. SLSA Provenance v1.0 spec’i in-toto Statement formatını kullanıyor; ikisi birbirini tamamlıyor.
in-toto Layout, Link ve Attestation Modeli
in-toto’nun üç temel sanat eseri var: layout (proje sahibi tarafından imzalanan kural seti), link (her step’in çıktısı olarak ürettiği bir functionary kaydı), final product (verifier tarafından layout ile doğrulanır). Layout, hangi functionary’lerin hangi step’leri imzalamaya yetkili olduğunu, hangi artifact’ların hangi input’lardan üretildiğini ve hangi inspection script’lerinin çalışması gerektiğini tanımlıyor.
| Bileşen | Amaç | İmzalayan | İçerik | Kullanım |
|---|---|---|---|---|
| Layout | Pipeline kuralları | Project owner | Steps, functionaries, expected_command | Tüm doğrulama referansı |
| Link | Step kaydı | Functionary | Materials, products, command, hash | Step’in gerçekleştiğinin kanıtı |
| Statement | Attestation zarfı | Producer | Subject + Predicate + Type | SLSA, SPDX, custom predicate |
| Predicate | Attestation içeriği | Producer | Provenance, vuln scan, test sonucu | Domain-specific veri |
| Bundle | İmzalı zarf | Sigstore Cosign | DSSE envelope + signatures | OCI registry push |
Sigstore ve DSSE ile Entegrasyon
in-toto attestation’lar Dead Simple Signing Envelope (DSSE) formatında imzalanıyor. DSSE, payload + payloadType + signatures üçlüsüyle JWS’in tedarik zinciri özelinde optimize edilmiş alternatifi. Sigstore Cosign 2.0+ in-toto Statement’larını DSSE ile imzalayıp OCI registry’ye attestation manifest olarak push edebiliyor. OIDC tabanlı “keyless” imzalama (Fulcio CA + Rekor transparency log) ile uzun ömürlü private key’lere gerek kalmıyor.
- Predicate type: SLSA Provenance v1.0, SPDX 2.3/3.0, CycloneDX 1.6, vuln-assessment, test-result, custom
- Subject digest: sha256 hash + artifact adı; tek statement birden fazla subject içerebilir
- DSSE envelope: base64 payload, list of signatures (keyid + signature)
- Rekor entry: Transparency log’da timestamp + Merkle proof; non-repudiation sağlıyor
İlgili konu: Sigstore Cosign container imzalama pattern
Production Pipeline Pattern’ı
Tipik bir kurumsal CI/CD pipeline’ında in-toto kullanımı şu sırayı izler: birinci adımda repo clone link’i (git tag + commit hash), ikinci adımda build link’i (Bazel/Maven/npm çıktısı + materials), üçüncü adımda SAST scan attestation’ı (Semgrep veya CodeQL output), dördüncü adımda SBOM oluşturma (CycloneDX 1.6), beşinci adımda vuln scan (Grype veya Trivy), altıncı adımda container imza (Cosign), yedinci adımda deploy doğrulama (Policy Controller).
GitHub Actions ekosisteminde in-toto/attestation reusable action’ı SLSA Provenance v1.0 + custom predicate üretebiliyor. GitLab tarafında 2024 Q4 sürümünde in-toto entegrasyonu mainstream’e taşındı; “Continuous Vulnerability Scanning” ile attestation export’u standartlaştı. CNCF projesi policy-controller Kubernetes admission tarafında in-toto Predicate type’ı zorunlu kılan policy yazabiliyor.
Compliance Audit ve Forensic Pattern’ları
in-toto’nun compliance açısından gücü “evidence trail” oluşturmasında. Bir incident sonrasında forensic ekip, etkilenen artifact’ın hash’ini Rekor’da arar, ilgili Statement’ı çeker, üretildiği build environment’ı (builder URI, GitHub Actions run ID, commit hash) inceler, hangi reviewer’ın hangi commit’i onayladığını PR metadata’sından çıkarır. SOC 2 Type II, ISO 27001, FedRAMP ve PCI DSS 4.0 audit’lerinde “change management evidence” bölümü in-toto Rekor entry’leri ile karşılanabiliyor.
| Audit Çerçevesi | İlgili Madde | in-toto Karşılığı | Otomasyon | Audit Kanıtı |
|---|---|---|---|---|
| SOC 2 Type II | CC8.1 Change Mgmt | Build Statement | Tam otomatik | Rekor entry + commit hash |
| ISO 27001:2022 | A.8.32 Change Mgmt | SLSA Provenance | Tam otomatik | OCI manifest |
| PCI DSS 4.0 | Req 6.5.1-6.5.2 | SAST + SBOM | Tam otomatik | Statement bundle |
| FedRAMP Moderate | SI-7 Software Integrity | Sigstore Cosign | Tam otomatik | DSSE envelope |
| EU CRA (2027) | Annex I §1.f | Vuln Assessment | Tam otomatik | VEX statement |
Sektörel Uygulamalar: Finans, Sağlık, Kamu
Finansal sektörde SWIFT CSP 2024 controls “supply chain integrity” maddesi için Cosign + in-toto attestation tipik karşılık. Sağlık tarafında FDA “Cybersecurity in Medical Devices: Quality System Considerations” 2023 nihai kılavuzu SBOM ve software integrity attestation gerektiriyor; in-toto bu zorunluluğa uyuyor. ABD federal alımında OMB M-22-18 / M-23-16 tedarikçi self-attestation’ı talep ediyor; FedRAMP Rev 5 control mapping’inde in-toto SI-7 ve CM-3 control’lerine doğrudan eşleniyor. in-toto Specification GitHub v1.0 spec’i barındırıyor; CNCF in-toto sayfası incubation metriklerini gösteriyor.
Kurumsal in-toto Adopsiyonunda Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Layout tasarım karmaşıklığı: 20+ step’li monorepo pipeline’ları için layout JSON 800+ satıra çıkıyor; layout-as-code template araçları gerekiyor
- Functionary key yönetimi: Keyless OIDC kullanılmıyorsa her CI runner için HSM-protected key gerekiyor; rotation kompleks
- OCI registry attestation storage: Manifest list boyutu büyüyor (10+ attestation per image); registry GC policy ayarlanmalı
- VEX integration eksikliği: Vulnerability assessment attestation üretiliyor ama VEX (Vulnerability Exploitability eXchange) field’ları boş kalıyor
- Reviewer attestation: Code review onayını attestation’a dahil edecek pattern (PR metadata → Statement) hâlâ olgunlaşmamış
- Cross-pipeline trust: Mikroservis A’nın in-toto’su B’nin pipeline’ında doğrulanmıyor; bundle distribution stratejisi yok
Sonuç
in-toto Attestation Framework, 2026’nın tedarik zinciri güvenliği için fiili evrensel dili. SLSA, Sigstore, SPDX, CycloneDX ekosistemleriyle birlikte çalışıyor ve compliance, forensic, runtime enforcement boyutlarında tek bir veri modeli sunuyor. Pratik yol haritası: önce build provenance Statement’larını üretmeye başlayın (GitHub Actions slsa-github-generator), ardından SBOM ve SAST scan’leri Statement formatına dönüştürün, üçüncü aşamada Kubernetes admission tarafında policy-controller ile enforcement ekleyin. Audit ekibinizle Rekor entry’leri üzerinden compliance evidence pipeline’ı kurun. 6-9 ay süren bu yolculuk hem regülasyon uyumunu otomatikleştiriyor hem de SolarWinds benzeri saldırılara karşı kurumsal stack’i sertleştiriyor. in-toto yatırımı SBOM ve SLSA programları için merkezi attestation katmanı olarak en yüksek stratejik geri dönüş sağlıyor.
Sıkça Sorulan Sorular
in-toto ile SLSA arasındaki ilişki nedir?
SLSA, tedarik zinciri olgunluk çerçevesi (ne yapılmalı). in-toto, attestation’ların formal data model’i (nasıl ifade edilmeli). SLSA Provenance v1.0 spec’i in-toto Statement formatını kullanıyor. İkisi tamamlayıcı: SLSA hedefi tarif ediyor, in-toto attestation taşıyıcısı.
Keyless OIDC imzalama ne avantaj sağlıyor?
Uzun ömürlü private key’lere gerek kalmıyor; her imza için CI runner’ın OIDC kimliği üzerinden geçici sertifika alınıyor (Sigstore Fulcio). Key rotation, kompromise riski, HSM operasyonu yokluğu ile maliyet ve risk düşüyor. GitHub Actions, GitLab CI, CircleCI native destekli.
in-toto attestation’ları nerede saklanır?
OCI registry’de attestation manifest (Cosign push), Rekor transparency log’da Merkle proof, opsiyonel olarak Sigstore Rekor mirror. Production’da üçü birden tutuluyor: OCI hızlı erişim, Rekor non-repudiation, mirror availability için.
Hangi predicate type’ları üretmek için pipeline’a eklenmeli?
Minimum: SLSA Provenance (build kanıtı), SPDX/CycloneDX (SBOM), Vuln Assessment (scan sonucu), Test Result (CI test çıktısı). Audit talebi varsa VEX (vulnerability exploitability) ve custom code review predicate eklenebilir.
Türk şirketleri in-toto’yu ne zaman uygulamak zorunda?
AB pazarına yazılım satanlar için Cyber Resilience Act (CRA) 2027 sonu yürürlük takvimi öncesinde hazırlık şart. Yerel olarak BDDK Bilgi Sistemleri Yönetmeliği “üçüncü taraf yazılım denetimi” maddesi in-toto bilgisini doğrudan kabul ediyor. Finansal ve sağlık sektörü erken adoption için öncü.
Ömer Önal
Mayıs 23, 2026in-toto Attestation Framework 2026’nın tedarik zinciri güvenliği için fiili evrensel veri modeli. SBOM, SLSA, vulnerability assessment ve test sonuçları tek bir Statement formatında ifade ediliyor. SOC 2 Type II, ISO 27001, PCI DSS audit’lerinde change management evidence için doğrudan kabul ediliyor. Türk şirketler için pratik başlangıç noktası: GitHub Actions üzerinden in-toto Statement üretmek, sonra Kubernetes admission policy ile enforcement eklemek. 6-9 aylık bu yolculuk audit otomasyonunda büyük sıçrama sağlıyor.