Sigstore ve Cosign: Yazilim Tedarik Zinciri Imzalama 2026

Sigstore nedir sorusunun kısa cevabı: yazılım artefaktlarını (container imajı, binary, SBOM) anahtarsız (keyless) imzalamak, doğrulamak ve şeffaf bir log’a kaydetmek için Linux Foundation altında geliştirilen açık kaynak bir tedarik zinciri güvenliği çerçevesidir. Sigstore üç temel bileşenden oluşur: imza üretici Cosign, kısa ömürlü sertifika veren Fulcio ve Merkle ağacı tabanlı şeffaflık log’u Rekor. 2026 itibarıyla Kubernetes, Python Package Index (PyPI), npm ve Homebrew gibi büyük dağıtım kanalları Sigstore imzalarını üretiyor; CNCF Graduated proje statüsüyle birlikte üretim ortamlarında varsayılan supply-chain doğrulama katmanı haline geldi. SolarWinds, Codecov ve XZ-utils backdoor olaylarından sonra “kim ne zaman ne imzaladı?” sorusu artık opsiyonel değil; Cosign tabanlı doğrulama, build pipeline’ından runtime admission control’e kadar zinciri kapatan minimum standart.

Bu yazıda Sigstore mimarisini bileşen bileşen açıyoruz: Cosign keyless flow’unun OIDC ile nasıl çalıştığı, Fulcio’nun kısa ömürlü X.509 sertifikası nasıl ürettiği, Rekor’un nasıl public ledger gibi davrandığı, Kubernetes admission controller (policy-controller, Kyverno) entegrasyonu, GitHub Actions/GitLab CI içinde imzalama, SBOM imzalama ve SLSA seviyeleri ile ilişkisi. Hedef: Sigstore’u sadece “imza koyan araç” olarak değil, NIST SSDF ve EU CRA uyumlu tedarik zinciri kontrol noktası olarak konumlandırmak.

Sigstore Mimarisi: Cosign, Fulcio ve Rekor Üçlüsü

Sigstore’un tasarım hedefi, geleneksel PGP/GPG temelli imzalamanın iki kronik problemini çözmek: uzun ömürlü private key’lerin saklanması ve imzaların doğrulanabilir bir public log’da bulunmaması. Klasik akışta geliştirici 4096-bit RSA anahtarını yıllarca yerel HSM’de saklamak, periyodik rotate etmek ve key ele geçerse tüm geçmiş imzaları geri çekmek zorundaydı. Sigstore bu sorunu üç eşgüdümlü servisle çözüyor: Cosign (CLI/library), Fulcio (Certificate Authority), Rekor (transparency log). Public good instance olan sigstore.dev üretim ortamlarında varsayılan endpoint; kurumlar isterse self-hosted Fulcio + Rekor deploy edebiliyor.

Keyless flow’un özü kısa ömürlü sertifika: Cosign, OIDC identity provider’dan (Google, GitHub, Microsoft, GitLab) bir ID token alır, Fulcio bu token’ı doğrular ve ortalama 10 dakika geçerli bir X.509 sertifikası imzalar. İmza Rekor’a yazılır; sertifika expiry sonrası bile imza doğrulanabilir kalır çünkü “imza atıldığı anda sertifika geçerliydi” kanıtı log’da Merkle proof olarak duruyor. Bu yaklaşım anahtar yönetimi yükünü sıfıra indirir, ancak organizasyon politikası gerektiriyorsa Cosign uzun ömürlü key çiftiyle de çalışabilir (cosign generate-key-pair).

Aşağıdaki tablo üç bileşenin sorumluluk dağılımını ve 2026 sürümlerini özetliyor.

Bileşen	Rol	Stable sürüm (2026)	Protokol	Self-host
Cosign	İmza üretme + doğrulama CLI/lib	v2.4.x	OCI registry, OIDC	N/A (client)
Fulcio	Kısa ömürlü X.509 CA	v1.6.x	OIDC → X.509 (~10dk)	Evet (Helm chart)
Rekor	Append-only transparency log	v1.3.x	Merkle tree (Trillian)	Evet (PostgreSQL backend)
policy-controller	Kubernetes admission	v0.10.x	ValidatingWebhook	Evet (cluster içi)
Gitsign	Git commit imzalama	v0.10.x	OIDC → SSH/X.509	Fulcio bağımlı

Üretim metrikleri: Rekor public instance Mart 2026 itibarıyla 180 milyondan fazla giriş içeriyor (sigstore/rekor metrics endpoint’i), günlük ortalama 400 bin yeni imza giriyor. Sigstore Foundation 2024 yıllık raporuna göre PyPI üzerinden Sigstore imzalı paket yüklemeleri toplam upload’ların %92’sini aşmış durumda — bunun nedeni PyPI’ın Eylül 2023’te attestation desteğini, 2024 sonunda da güvenilir yayıncı (Trusted Publisher) modelini varsayılan yapmasıydı.

Cosign Keyless İmzalama: OIDC Flow Adım Adım

Keyless akışı pratikte tek komut: cosign sign ghcr.io/org/app@sha256:abc123. Komut çalıştığında arka planda altı adımlı bir koreografi gerçekleşir. Birincisi, Cosign yerelde geçici bir ECDSA P-256 anahtar çifti üretir (RAM’de, diske yazmaz). İkincisi, OIDC provider’a redirect yapar; CI ortamında ambient token (GITHUB_TOKEN gibi OIDC token) kullanılır, dev makinada tarayıcı açılır. Üçüncüsü, alınan ID token Fulcio’ya gönderilir, public key challenge ile birlikte. Dördüncüsü Fulcio token’ın iss, aud, sub claim’lerini doğrular ve içine “subject” olarak email/identity yazılı X.509 sertifikası imzalar. Beşincisi Cosign artefakt hash’ini private key ile imzalar. Altıncısı imza + sertifika + payload Rekor’a yazılır, log inclusion proof döner.

Doğrulama tarafında cosign verify --certificate-identity-regexp '.*@org.com' --certificate-oidc-issuer https://accounts.google.com ghcr.io/org/app@sha256:abc123 komutu üç şeyi kontrol eder: imza ECDSA olarak geçerli mi, sertifika içindeki identity beklenen regexp’e uyuyor mu, Rekor’da inclusion proof var mı. Bu üçü tutmazsa exit code 1. CI/CD’de identity bazlı policy yazmak (örn. “sadece release.yml workflow’unun signed olduğu kabul edilir”) supply-chain attack’e karşı en güçlü kontrol katmanlarından biri.

Flow adımı	Süre (avg)	Bileşen	Çıktı	Hata davranışı
OIDC token alma	~200 ms	Identity Provider	JWT	3xx redirect / fail
Ephemeral key üretimi	~5 ms	Cosign (yerel)	ECDSA P-256 pair	Hiç (RAM)
Fulcio sertifika imzası	~400 ms	Fulcio CA	X.509 (~10 dk geçerli)	403 → token rejected
Artefakt imzası	~50 ms	Cosign	DSSE/sig blob	I/O fail
Rekor giriş	~300 ms	Rekor	UUID + inclusion proof	Retry 3x exponential
OCI registry push	~600 ms	Registry	cosign-signature tag	401/403 → auth fail

End-to-end ortalama imzalama 1.5-2 saniye sürer; doğrulama 300-500 ms (Rekor inclusion proof cache’lenirse 150 ms’ye iner). Bu performans bütçesi DevSecOps shift-left pipeline’larında dakikada onlarca image build’in imzalanmasını mümkün kılıyor.

Fulcio: Kısa Ömürlü Sertifika Otoritesi

Fulcio Sigstore’un Certificate Authority bileşeni. Standart bir kurumsal CA’dan iki büyük farkı var: birincisi sertifikaların geçerlilik süresi varsayılan 10 dakika (Cosign sadece imza atıp atılıyor, oturum modeli yok). İkincisi private key Google Cloud KMS veya AWS KMS gibi HSM-backed servislerde saklanıyor, public good Fulcio Cloud KMS kullanıyor. Sertifikanın “subject” alanına OIDC claim’lerinden gelen identity (email, GitHub Actions workflow path, GitLab job URI) yazılıyor, x509v3 extensions altında ek metadata (issuer URL, build trigger, repository) bulunuyor.

Self-hosted Fulcio deploy’u Helm chart üzerinden yapılır; bağımlılıkları PostgreSQL veya CockroachDB (CT log için) ve bir KMS provider (Google KMS, AWS KMS, HashiCorp Vault, Azure Key Vault). Üretim deploy’unda yaygın hata payı: KMS key rotate edilmediğinde root CA kompromisi olduğunda tüm sertifikaları geri çekme prosedürü zayıf kalır; bu nedenle yıllık rotate ve TUF root rotation 2026 best practice’i. Self-hosted Fulcio’nun tipik kurumsal use-case’i air-gapped ortamlar veya finans/savunma gibi public Fulcio’ya identity sızdırmak istemeyen şirketler.

Desteklenen OIDC issuer’lar:

• GitHub Actions: Workflow-level OIDC token, ambient (env değişkeni) kullanılır. Subject formatı: repo:org/repo:ref:refs/heads/main.
• GitLab CI/CD: v15.7+ OIDC ID token, project + job level. Avantaj: Self-hosted Fulcio için audience override mümkün.
• Google Cloud: Workload Identity Federation üzerinden. Ne zaman seç: GKE içinden imzalama, service account izolasyonu lazımsa.
• Azure DevOps + Microsoft Entra ID: Federated credential. Dezavantaj: Subject format daha az grandüler.
• Buildkite, CircleCI, Bitbucket: 2024-2025’te eklenen native OIDC desteği. Avantaj: Vendor-lock azalır.
• Kullanıcı kimlikleri: Google, Microsoft, GitHub login — dev makinada interaktif imzalama için.

Sertifika içeriğine bakmak için cosign verify-blob --output-text kullanılır; sertifika SAN (Subject Alternative Name) alanında identity, issuer, workflow path, ref/branch, run ID gibi bilgiler yer alır. Bu metadata policy yazarken kritik: “sadece main branch’ten gelen imzalar geçerli” gibi kurallar SAN üzerinden filtrelenir.

Rekor: Şeffaflık Log’u ve Merkle Tree

Rekor, Google Trillian üzerine inşa edilmiş append-only bir Merkle tree log’u. Her giriş bir log index alır ve cryptographic olarak öncekilere bağlanır; geçmişi değiştirmek için tüm log’u baştan oluşturmak gerekir. Bu Certificate Transparency (CT) modeline benzer ama imza artefaktları için. Rekor’a yazılan tipik girişler: hashedrekord (artefakt hash + imza), intoto (SLSA attestation), hashedrekord-v0.0.2 (sertifika dahil yeni format).

Inclusion proof Rekor’un en önemli özelliği: bir imzanın belirli bir tree state’inde var olduğunun kriptografik kanıtı. Cosign doğrulama yaparken bu proof’u kontrol eder; offline doğrulama için checkpoint dosyası kullanır. Rekor public instance’ı Sigstore Foundation tarafından witnessed (üçüncü taraf gözlemciler periyodik olarak root hash imzalar) — bu split-view attack’a karşı koruma sağlar. Self-hosted Rekor için witness ağı CNCF’in 2025’te başlattığı sigstore-witness projesi üzerinden kuruluyor.

Rekor entry type	İçerik	Kullanım	Tipik boyut
hashedrekord	Hash + imza + public key	Container/binary imzası	~2 KB
intoto (DSSE)	Attestation envelope	SLSA provenance, SBOM attestation	5-50 KB
rfc3161	Timestamp token	Long-term doğrulama	~1 KB
jar	Java archive imzası	Maven Central	~3 KB
alpine	APK paket imzası	Alpine Linux	~2 KB

Rekor’a yazılan veri PII içermeyecek şekilde tasarlanmış: artefakt hash’i + imza + sertifika. Sertifika içinde email görünebilir (kullanıcı kimliği OIDC ile imzalandıysa) — kurumsal kullanımda bu sebeple bot identity (CI workflow) tercih edilir, kişisel email log’lanmaz. Public Rekor verisinin tamamı search.sigstore.dev üzerinden sorgulanabilir.

GitHub Actions ve GitLab CI ile Pipeline Entegrasyonu

CI/CD ortamında Sigstore entegrasyonunun avantajı ambient OIDC: ekstra secret yönetimi gerekmiyor. GitHub Actions için en yaygın pattern sigstore/cosign-installer ve id-token: write izniyle workflow tanımlamak. Tipik bir image build + sign + push akışı:

• permissions: id-token: write ve packages: write en az gereken iki izin. Avantaj: least-privilege.
• Container build: docker buildx build –push ile multi-arch image üretilir, digest çıktı olarak yakalanır.
• Cosign sign: cosign sign --yes ${IMAGE}@${DIGEST} ile imzalanır. Önemli: tag yerine digest kullan, tag mutable.
• SBOM attestation: cosign attest --predicate sbom.spdx.json --type spdxjson ile SBOM Rekor’a iliştirilir.
• SLSA provenance: slsa-github-generator reusable workflow ile in-toto attestation üretilir.
• Verify gate: Sonraki job’da cosign verify --certificate-identity-regexp ile kendi imzanı doğrula (sanity check).

GitLab CI tarafında farklı: id_tokens bloğu altında audience belirleyip ID_TOKEN env değişkeni alınır, COSIGN_IDENTITY_TOKEN=$ID_TOKEN cosign sign şeklinde override edilir. GitLab 16+ runner’ları native destekliyor. Buildkite, CircleCI ve Jenkins (plugin üzerinden) benzer pattern.

Sigstore Foundation 2025 State of Software Supply Chain raporuna göre Fortune 500 şirketlerin %38’i en az bir kritik pipeline’da Cosign veya benzer imzalama kullanıyor (2023’te %14’tü). Artış driver’ları: EU CRA (Cyber Resilience Act) 2027 yürürlük, SLSA Build Level 3 kurumsal hedef ve container güvenliği alanında policy-as-code adopsiyonu.

Kubernetes Admission Control: policy-controller ve Kyverno

Cosign imzasının değeri pipeline’da değil, runtime’da doğrulamada ortaya çıkıyor. Kubernetes admission control, imzasız veya doğrulanamayan image’ların cluster’a giremesini engelliyor. Sigstore’un kendi çözümü policy-controller (eski sigstore-policy-controller, Cosign v2 ile entegre); rakipler Kyverno (CNCF Incubating, verifyImages rule’ı ile) ve OPA Gatekeeper (eklenti gerektirir).

Tipik bir Kyverno policy: namespace label’ı production olan tüm pod’ların image’larının ghcr.io/myorg/* deseninden gelmesi ve repo:myorg/.* identity regexp’ine sahip workflow tarafından imzalanmış olması gerek. Eşleşmezse pod admission reddedilir. Production cluster’larda audit modunda başlatıp 1-2 hafta gözlem sonrası enforce moda geçmek best practice.

Admission tool	Sigstore desteği	Policy dili	Performans (p95)	Maturity
policy-controller	Native (Cosign lib)	YAML (ClusterImagePolicy)	~150 ms	GA
Kyverno	Native (verifyImages)	YAML (ClusterPolicy)	~200 ms	CNCF Incubating
OPA Gatekeeper	Eklenti (cosign-gatekeeper)	Rego	~250 ms	CNCF Graduated
Connaisseur	Native (multi-CA)	YAML	~180 ms	Stable
Ratify	Native + Notation	Rego/CEL	~170 ms	CNCF Sandbox

Performans hususları: admission webhook her pod create/update’inde tetiklenir; cluster’a saniyede onlarca pod açılan ortamlarda doğrulama latency’si önemli. Cosign image cache (in-memory) ve Rekor proof caching (TUF) ile p95 latency 50-100 ms’ye iner. Production’da timeout 3 saniye, fail policy “Fail” (imza yoksa reddet) seçilmeli; “Ignore” silent failure riski yaratır.

SBOM Attestation ve SLSA Provenance ile Birlikte Kullanım

Cosign sadece artefakt imzalamıyor; cosign attest komutu in-toto DSSE envelope’unda yapısal predicate’ler eklemeye imkân veriyor. Tipik predicate’ler:

1. SBOM (SPDX 2.3 veya CycloneDX 1.5): Image içindeki tüm OSS bağımlılıklar. Syft veya Trivy ile üretilir, Cosign ile attest edilir.
2. SLSA Provenance v1.0: Build invocation metadata — kim ne zaman hangi commit’ten ne ile derledi. slsa-github-generator üretir.
3. VEX (Vulnerability Exploitability eXchange): Bilinen CVE’lerin gerçek exploitability statüsü (not-affected, fixed, under-investigation).
4. Custom predicate: Şirket içi attestation — örn. “internal-security-review-passed”, “license-clearance-approved”.

Bu pratik SBOM ve SLSA ile birleştiğinde tedarik zinciri haritası ortaya çıkıyor: hangi binary hangi commit’ten geldi, hangi CVE’ler içeriyor, gerçekten exploitable mi. NIST SSDF (SP 800-218) ve Executive Order 14028 (US Federal) uyumu için bu attestation zinciri zorunlu hale geliyor.

Doğrulama tarafında cosign verify-attestation --type slsaprovenance --policy policy.rego ile Rego policy çalıştırılır. Örnek bir kontrol: provenance’taki builder.id “https://github.com/actions/runner” mi? source materials git commit hash beklenen branch’te mi? Bu kontroller geçmezse deploy reddedilir. Ömer Önal yürüttüğü tedarik zinciri güvenliği danışmanlığında en sık karşılaştığı eksikliklerden biri attestation üretiminin var olup doğrulama gate’inin olmaması — yani imza atılıyor ama kimse okumuyor.

Sigstore vs Notary v2 vs PGP: Karşılaştırma

Container image imzalama dünyasında üç yaklaşım yarışıyor: Sigstore (Cosign), Notary v2/Notation (CNCF, Docker Inc. öncülüğünde) ve eski PGP/GPG. Üçü de farklı tasarım kararlarıyla farklı use case’lere fit oluyor. Sigstore keyless ve transparency log’a yatırım yaparken Notary v2 detached imza ve enterprise PKI uyumuna odaklanıyor.

Özellik	Sigstore (Cosign)	Notary v2 (Notation)	PGP/GPG
Anahtar modeli	Keyless (OIDC) veya key	X.509 kurumsal PKI	Long-lived RSA/Ed25519
Transparency log	Rekor (zorunlu)	Opsiyonel (proposal)	Yok
Sertifika ömrü	~10 dk (keyless)	1-3 yıl (kurumsal)	Yıllarca
OCI registry desteği	Tam (cosign tag)	Tam (referrers API)	Yok (yan-band)
Kubernetes admission	policy-controller, Kyverno	Ratify	Manuel
SBOM attestation	Native (in-toto)	Native (artifact ref)	Yok
CNCF statüsü	Graduated (2025)	Incubating	N/A
Tipik enterprise fit	Cloud-native, OSS	Hybrid, regulated	Legacy

Avantaj (Sigstore): Anahtar yönetimi yükü sıfır, transparency log denetlenebilir, açık kaynak ekosistem büyük. Dezavantaj: Kurumsal PKI ile entegrasyon sınırlı, identity OIDC’ye bağımlı. Ne zaman seç: Cloud-native, CI/CD-first, OSS ağırlıklı projeler için varsayılan seçim.

Avantaj (Notary v2): Enterprise X.509 PKI ile uyumlu, regulated industry için familier model. Dezavantaj: Transparency log ekosistemi olgunlaşmadı, daha az hazır araç. Ne zaman seç: Finans, savunma, sağlık gibi kurumsal CA hierarchy zorunluluğu olan sektörler.

İmzalama mimarisinin Zero Trust mimari içine entegrasyonu kritik: imza doğrulama her trust boundary’de tekrarlanmalı (build → registry → admission → runtime). Tek noktada güven varsayımı toplam zinciri zayıflatır.

Üretimde Karşılaşılan Tipik Sorunlar ve Çözümler

Sigstore’u production’a alırken karşılaşılan sorunlar genelde mimari değil operasyonel:

• OIDC token expiry: Long-running CI job’larında token süresi dolar. Çözüm: Cosign her aşamada fresh token alır, manual cache yapma.
• Air-gapped doğrulama: Cluster internet’siz, Rekor’a erişemez. Çözüm: cosign verify --offline + bundle dosyası (imza + sertifika + inclusion proof yerelde).
• TUF root güncelleme: Public TUF root yıllık rotate ediliyor. Çözüm: CI base image’larda Cosign sürümü tazeleme + initial TUF root pinning.
• Identity drift: Workflow path değişti, policy regex eski kaldı. Çözüm: Policy CI’da test edilmeli (cosign verify –dry-run).
• Rekor downtime: Public instance nadiren ama yaşandı (2024 Mart 4 saatlik incident). Çözüm: Retry + exponential backoff + self-hosted mirror.
• Multi-arch image: Manifest list imzası mı, her arch ayrı mı? Çözüm: Recursive flag --recursive ile manifest list + tüm child manifest’ler imzalanır.

Migration story: PGP’den Sigstore’a geçen tipik bir orta-büyük (500-2000 mühendis) organizasyonun timeline’ı yaklaşık 6-9 ay sürer. İlk faz (1-2 ay) yeni image’lar için Cosign imzalama; ikinci faz (2-3 ay) admission audit modu; üçüncü faz (1-2 ay) enforce mode; dördüncü faz (1-2 ay) SBOM attestation + SLSA provenance üretimi. Bu aşamalı geçiş üretim kesintisini sıfıra yakın tutuyor. Secret management yaklaşımı paralel: imzalama key’siz olduğu için secret store yükü azalır.

Sıkça Sorulan Sorular

Sonuç

Sigstore ve Cosign 2026 itibarıyla yazılım tedarik zinciri imzalamanın varsayılan standardı haline geldi. Keyless OIDC akışı anahtar yönetimi yükünü ortadan kaldırırken Rekor transparency log’u doğrulanabilir bir public ledger sağlıyor. Karar çerçevesi açık: cloud-native, CI/CD merkezli, açık kaynak ağırlıklı projeler için Cosign tercih edilen seçim; kurumsal X.509 PKI hierarchy zorunluluğu olan regulated sektörler için Notary v2 alternatifi olgunlaşıyor; ancak iki dünya birleşiyor (referrer API, transparency log uyumu) ve uzun vadede tek bir ekosistem oluşması bekleniyor.

Pratik yol haritası: yeni image’larınızı bugünden Cosign keyless ile imzalamaya başlayın, GitHub Actions veya GitLab CI içinde 10 satır eklemekle başlayabilirsiniz. İkinci adım Kubernetes admission’a audit modunda policy-controller veya Kyverno verifyImages koymak; üç hafta gözlem sonrası enforce’a geçmek. Üçüncü adım SBOM ve SLSA provenance attestation üretimi. Bu üç adım SAST/DAST/IAST kontrolleriyle birleştiğinde gerçek bir defense-in-depth sağlar.

Sigstore-tabanlı bir tedarik zinciri kontrol mimarisi tasarlamak, policy yazımı veya regulated industry uyum çalışması için detaylı görüşme isterseniz iletişim sayfası üzerinden ulaşabilirsiniz.

Referans kaynaklar: Sigstore official documentation, sigstore/cosign GitHub repository, SLSA v1.0 specification, NIST Secure Software Development Framework, Kyverno verifyImages Sigstore guide, CNCF Sigstore Graduated project page.