Bu rehber, GitHub Actions üzerinde keyless imzalama zincirini kurmayı; imajı tag yerine digest ile sabitlemeyi; Cosign ile imzalama ve doğrulamayı; SBOM ve provenance attestations üretmeyi; Kubernetes admission katmanında kimlik politikasına dönüştürmeyi ele alır.
Yazılım tedarik zincirinde hangi sorunu çözer?
Bir container registry'de latest etiketi görmek, imajın kim tarafından ve hangi kaynak koddan üretildiğini kanıtlamaz. Tag değiştirilebilir; registry hesabı ele geçirilebilir; CI işi beklenmeyen bir fork veya pull request bağlamında çalışabilir; uzun ömürlü imzalama anahtarı loga veya secret'a sızabilir.
Dijital imza iki temel soruya yanıt verir: artefakt üretildikten sonra değişti mi ve imzayı hangi güvenilir kimlik attı? Provenance ise buna “hangi kaynak, workflow, builder ve parametrelerle üretildi?” bağlamını ekler. SBOM bileşen envanteri sağlar. Üçü birlikte kullanıldığında dağıtım kararı yalnız zafiyet taramasına değil, kaynağın ve üretim yolunun doğrulanmasına dayanır.
| Kontrol | Yanıtladığı soru | Tek başına yetmediği nokta |
|---|---|---|
| Digest | Tam olarak hangi byte dizisi? | Kimin ürettiğini söylemez |
| İmza | Artefakt değişti mi, hangi kimlik imzaladı? | Build sürecinin ayrıntısını vermez |
| Provenance | Hangi kaynak ve builder üretti? | İçerikteki bileşenleri listelemez |
| SBOM | Hangi paket ve kütüphaneler var? | Artefaktın güvenilir kimlikten geldiğini kanıtlamaz |
| Admission policy | Dağıtıma ne kabul edilir? | Yanlış kimlik kuralı güveni genişletebilir |
Keyless imzalama nasıl çalışır?
Keyless ifadesi kriptografik anahtar kullanılmadığı anlamına gelmez. Cosign işlem sırasında geçici bir anahtar çifti üretir. CI ortamından alınan OIDC identity token ile birlikte public key'i Fulcio sertifika otoritesine sunar. Fulcio, token içindeki kimlik ve claim'leri doğrular; public key'i kimliğe bağlayan kısa ömürlü bir kod imzalama sertifikası verir.
Cosign artefaktı geçici private key ile imzalar. İmza, sertifika ve ilgili metadata OCI registry'ye eklenir veya blob senaryosunda bir bundle dosyasına yazılır. Rekor şeffaflık günlüğü, imzalama olayına ilişkin kriptografik kaydı denetlenebilir biçimde saklar. Güven kökleri The Update Framework (TUF) ile dağıtılır.
- GitHub Actions işi OIDC token ister.
- Workflow'a özel identity claim'leri token içinde yer alır.
- Cosign geçici anahtar çifti üretir.
- Fulcio OIDC kimliğini doğrular ve kısa ömürlü sertifika verir.
- Cosign imaj digest'ini imzalar.
- Kayıt Rekor şeffaflık günlüğüne gönderilir.
- Doğrulayıcı, imzayı, sertifika zincirini, kimlik claim'lerini ve log kanıtını kontrol eder.
Uzun ömürlü private key'in GitHub secret, KMS veya dosya olarak yönetilmemesi önemli bir avantajdır. Anahtar rotasyonu ve dağıtımı yükü azalır. Ancak güven sırrın kendisinden workflow kimliğine kaydığı için repository izinleri, branch protection, reusable workflow ve action pinleme daha kritik hâle gelir.
Güven modeli ve bileşenler
| Bileşen | Görev | Güvenlik notu |
|---|---|---|
| Cosign | İmza, doğrulama ve attestation işlemleri | Sürümü ve kurulum kaynağı sabitlenmeli |
| OIDC issuer | CI işinin kimliğini kanıtlar | Issuer ve subject/identity dar doğrulanmalı |
| Fulcio | Kısa ömürlü sertifika verir | Güven kökü ve sertifika zamanı doğrulanır |
| Rekor | Şeffaf imzalama kaydı sağlar | Inclusion proof ve signed timestamp önemlidir |
| TUF | Sigstore güven köklerini dağıtır | Metadata güncelliği ve eşik imzaları korunur |
| OCI registry | İmaj ile ilişkili imza/attestation saklar | Digest temelli referans kullanılmalı |
| Admission policy | Çalıştırmadan önce kimliği uygular | Varsayılan reddet ve dar claim kuralı gerekir |
Keyless zincir “GitHub'dan gelen her imzaya güven” değildir. Güven kararı; issuer, repository, workflow dosyası, git ref, event türü ve mümkünse immutable revision gibi alanlarla daraltılmalıdır. Regex ile bütün kimlikleri kabul eden örnekler yalnız laboratuvar gösterimi için uygundur.
Ön koşullar
- İmajı push edebilen ve imzayı saklayabilen bir OCI registry
- GitHub Actions işinde yalnız gereken kapsamda contents: read, packages: write ve id-token: write
- Digest üreten BuildKit veya docker/build-push-action adımı
- Cosign'in sabitlenmiş ve doğrulanmış kurulumu
- Branch protection, zorunlu review ve güvenilir workflow değişiklik süreci
- Pull request'lerden production registry'ye doğrudan push edilmesini engelleyen event politikası
id-token: write repository içeriğine yazma izni vermez; GitHub OIDC token istemesine izin verir. Yine de token, dış hizmette kimlik kanıtı olduğu için yalnız imzalama işine ve gereken job kapsamına verilmelidir.
GitHub Actions ile digest tabanlı imzalama
Aşağıdaki iskelet, imajı build edip registry'ye gönderdikten sonra çıktı digest'ini Cosign ile imzalar. Action referansları örnekte okunabilirlik için sürüm etiketiyle gösterilmiştir; üretimde third-party action'lar tam commit SHA ile sabitlenmeli ve düzenli güncellenmelidir.
CODE TERMINAL
name: build-sign
on:
push:
branches: [main]
permissions:
contents: read
jobs:
image:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
id-token: write
env:
IMAGE: ghcr.io/ORG/APP
steps:
- uses: actions/checkout@v5
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: sigstore/cosign-installer@main
with:
cosign-release: v3.0.2
- id: build
uses: docker/build-push-action@v6
with:
context: .
push: true
tags: ${{ env.IMAGE }}:${{ github.sha }}
- name: Sign immutable digest
env:
DIGEST: ${{ steps.build.outputs.digest }}
run: cosign sign --yes "${IMAGE}@${DIGEST}"İmza tag'e değil IMAGE@sha256:... biçimindeki immutable digest'e uygulanmalıdır. Tag imzalama anından sonra başka digest'e taşınabilir. Dağıtım manifesti de mümkünse digest kullanmalı veya admission controller tag'i resolve edip doğrulanan digest'e sabitlemelidir.
Action'ları neden commit SHA ile sabitlemelisiniz?
Bir GitHub Action'ı @main veya hareketli major tag ile çağırmak kullanım kolaylığı sağlar, ancak o referansın işaret ettiği kod değişebilir. İmzalama iş akışı saldırganın hedefidir; action tedarik zinciri ele geçirilirse OIDC token alınabilir, farklı artefakt imzalanabilir veya digest değişkeni manipüle edilebilir.
Üretim yaklaşımı:
- Third-party action referanslarını tam commit SHA ile sabitleyin.
- Dependabot veya Renovate ile güncelleme PR'ı üretin.
- Yeni SHA'yı action deposunun release etiketi ve imza/provenance verisiyle doğrulayın.
- Workflow dosyaları için CODEOWNERS ve zorunlu review uygulayın.
- Self-hosted runner kullanılıyorsa kalıcı workspace ve credential kalıntılarını temizleyin.
Cosign kurulum örneğindeki @main resmi dokümantasyonda görülebilir, fakat güvenlik açısından production dosyasında immutable SHA daha güçlüdür. Aynı ilke checkout, login, build ve metadata action'ları için geçerlidir.
İmzayı doğru kimlikle doğrulama
Keyless doğrulamada yalnız kriptografik imzanın geçerli olması yeterli değildir. Sertifikadaki kimliğin beklenen workflow'a ait olduğu ve token issuer'ın GitHub Actions olduğu doğrulanmalıdır.
CODE TERMINAL
cosign verify "ghcr.io/ORG/APP@sha256:DIGEST" \
--certificate-identity="https://github.com/ORG/REPO/.github/workflows/build-sign.yml@refs/heads/main" \
--certificate-oidc-issuer="https://token.actions.githubusercontent.com"Kimlik değeri kullanılan Cosign ve GitHub sertifika claim biçimiyle doğrulanmalıdır. İlk başarılı imzadan sertifika metadata'sını inceleyip production politikasına kopyalamak, tahmin edilen subject kullanmaktan daha güvenlidir.
--certificate-identity-regexp=.* ve --certificate-oidc-issuer-regexp=.* gibi geniş seçenekler demo sırasında işe yarayabilir, ancak gerçek doğrulamada “herhangi bir kimlik ve issuer” kabul etmek anlamına gelir. Bu, imzanın varlığını kontrol ederken imzalama yetkisini fiilen sınırsız bırakır.
Branch, tag ve pull request ayrımı
Workflow identity, tetikleyici bağlama göre değişebilir. Main branch push, release tag, pull request ve reusable workflow çağrısı aynı güven seviyesinde değildir. Fork'tan gelen pull request kodu production imajı oluşturup imzalayamamalıdır.
| Event | Önerilen yetki | Politika |
|---|---|---|
| pull_request | contents: read; id-token kapalı | Test yap, production push/imza yapma |
| push main | packages + id-token yalnız imza job'ında | Main workflow kimliğini doğrula |
| release tag | Korunan tag ve manuel/onaylı ortam | Tag ref ve workflow kimliğini doğrula |
| workflow_dispatch | Environment approval ile sınırlı | Aktör, ref ve environment bağlamını izle |
| pull_request_target | Çok yüksek dikkat | Güvenilmeyen PR kodunu checkout edip çalıştırma |
Özellikle pull_request_target, base repository bağlamında daha güçlü izinlere erişebilir. Güvenilmeyen PR head kodunu bu event altında çalıştırmak secret veya token sızıntısına yol açabilir. İmzalama akışı yalnız güvenilir branch'teki incelenmiş kodla çalışmalıdır.
SBOM attestation ekleme
İmzalı imajın hangi bileşenleri içerdiğini kanıtlamak için build sırasında CycloneDX veya SPDX SBOM üretin. Dosyayı artefaktla ilişkilendiren attestation, tüketicinin SBOM'un aynı güvenilir workflow tarafından bildirildiğini doğrulamasına yardımcı olur.
CODE TERMINAL
syft "${IMAGE}@${DIGEST}" -o cyclonedx-json=sbom.cdx.json
cosign attest --yes \
--type cyclonedx \
--predicate sbom.cdx.json \
"${IMAGE}@${DIGEST}"SBOM attestation, listedeki bütün bileşenlerin güvenli olduğunu söylemez. İçerik doğruluğu kullanılan tarayıcıya, paket yöneticisi metadata'sına ve build katmanlarına bağlıdır. Attestation imzalayan kimliği ve predicate type doğrulanmalı; ardından bileşen politikası ayrı değerlendirilmelidir.
Provenance attestation
SLSA provenance; artefaktın kaynağı, builder'ı, invocation bilgisi ve materyalleri hakkında doğrulanabilir bağlam sağlar. GitHub Artifact Attestations veya in-toto uyumlu üreticilerle provenance oluşturulabilir. Amaç yalnız JSON dosyası eklemek değil, dağıtım kararında beklenen builder ve source repository'yi zorunlu kılmaktır.
- Subject digest, gerçekten dağıtılan imaj digest'iyle aynı olmalıdır.
- Source repository ve git revision beklenen origin'i göstermelidir.
- Builder identity izin verilen workflow'a ait olmalıdır.
- Build parametreleri güvenilmeyen girdilerle üretim politikasını aşmamalıdır.
- Provenance, imajdan bağımsız bir yerde değiştirilebilir dosya olarak tutulmamalıdır.
SLSA seviyesi etiketi tek başına güvenlik garantisi değildir. Kurum, kendi tehdit modeline göre hangi claim'leri kontrol ettiğini açıkça tanımlamalıdır.
Blob ve dosya imzalama
Cosign yalnız container imajlarını değil release arşivi, binary ve politika dosyası gibi blob'ları da imzalayabilir. Blob senaryosunda bundle; imza, sertifika ve şeffaflık günlüğü kanıtını birlikte saklar.
CODE TERMINAL
cosign sign-blob release.tar.gz \
--bundle release.tar.gz.sigstore.json \
--yes
cosign verify-blob release.tar.gz \
--bundle release.tar.gz.sigstore.json \
--certificate-identity="EXPECTED_IDENTITY" \
--certificate-oidc-issuer="EXPECTED_ISSUER"Bundle dosyası artefaktla birlikte yayımlanmalı, ancak doğrulayıcı kimliği bundle içinden körlemesine güvenilir kabul etmemelidir. Beklenen identity ve issuer, tüketicinin güven politikasından gelmelidir.
Kubernetes admission katmanında uygulama
CI'da imza üretmek, cluster doğrulamıyorsa yalnız görünürlük sağlar. Sigstore Policy Controller, Kyverno veya benzeri admission politikaları imaj kabulünden önce signature ve attestation koşullarını zorlayabilir.
Sağlam geçiş sırası:
- Önce audit/monitor modunda mevcut imajların imza durumunu ölçün.
- Production namespace için izin verilen registry ve repository listesini çıkarın.
- Beklenen OIDC issuer ile tam workflow identity değerini tanımlayın.
- Tag yerine digest çözümleme ve mutasyon davranışını test edin.
- İmzasız ama kritik kurtarma imajları için süreli, onaylı istisna süreci kurun.
- Canary namespace'te enforce edin.
- Yanlış ret, registry kesintisi ve Rekor erişim sorunları için davranışı doğrulayın.
- Son olarak production kapsamını genişletin.
Fail-open seçimi kullanılabilirlik, fail-closed seçimi güvenlik lehinedir. İnternet veya şeffaflık günlüğü kesintisinde production'ın nasıl davranacağı önceden belirlenmeli; offline verification bundle ve cache stratejisi test edilmelidir.
Policy örneğinin mantığı
Kullanılan admission ürününe göre YAML değişse de mantık aynı kalır:
CODE TERMINAL
IF image.registry == "ghcr.io"
AND image.repository == "ORG/APP"
AND signature.issuer == "https://token.actions.githubusercontent.com"
AND signature.identity == "https://github.com/ORG/REPO/.github/workflows/build-sign.yml@refs/heads/main"
AND subject.digest == resolved_image_digest
THEN allow
ELSE denyPolitika repository adını wildcard ile genişletmemeli, workflow path'ini atlamamalı ve yalnız organization üyeliğine güvenmemelidir. Aynı organization içindeki ele geçirilmiş düşük değerli bir repository, geniş kural varsa güvenilir üreticiye dönüşebilir.
Sık yapılan hatalar
| Hata | Risk | Düzeltme |
|---|---|---|
| Tag'i doğrulamak | Tag başka digest'e taşınabilir | Digest resolve et ve digest'i doğrula |
| Her identity'yi regex ile kabul etmek | Saldırgan kendi geçerli Sigstore imzasını kullanır | Tam workflow identity zorunlu kıl |
| Issuer kontrol etmemek | Beklenmeyen OIDC sağlayıcı kabul edilir | Kesin issuer eşleştir |
| OIDC iznini bütün workflow'a vermek | Gereksiz job token alabilir | Yalnız imza job'ına ver |
| PR kodunu güçlü event altında çalıştırmak | Token ve push yetkisi kötüye kullanılır | Güvenilmeyen kodu ayrı düşük yetkili işte çalıştır |
| Action'ı @main ile çağırmak | Bağımlılık değişikliği build'i ele geçirir | Tam commit SHA sabitle |
| İmzayı üretip admission uygulamamak | Dağıtımda güven zorlanmaz | Cluster politikası ekle |
| SBOM'u imzasız dosya olarak yayımlamak | Envanter değiştirilebilir | Attestation ve identity doğrula |
Rekor ve gizlilik dengesi
Şeffaflık günlüğü denetlenebilirlik sağlar, fakat public-good Sigstore kullanıldığında imzalama kimliğine ilişkin bazı metadata kamusal kayda girebilir. Kişisel e-posta, gizli repository adı veya müşteri proje bilgisi gibi alanların loglanma etkisi değerlendirilmelidir.
Kurumsal gereksinimler public instance yerine private Sigstore bileşenlerini gerektirebilir. Bu durumda Fulcio, Rekor, OIDC ve TUF güven kökü işletme sorumluluğu kuruma geçer. Private kurulum, yanlış yapılandırılırsa public hizmetten daha güvenli olmayabilir; yedekleme, key ceremony, log bütünlüğü ve erişilebilirlik ayrı tasarlanmalıdır.
Offline ve kapalı ağ doğrulaması
Üretim ağı internete çıkamıyorsa doğrulama tamamen devre dışı bırakılmamalıdır. Sigstore bundle; sertifika, imza, timestamp ve transparency log inclusion proof gibi verileri taşıyabilir. Güven kökü kontrollü biçimde iç ağa dağıtılır ve politika, bundle üzerinden doğrulama yapar.
- Trusted root paketini sürümlü ve imzalı dağıtın.
- Kök güncelleme sürecini production değişikliği olarak yönetin.
- Sertifika geçerlilik zamanını signed timestamp bağlamında kontrol edin.
- Bundle ile artefakt digest eşleşmesini zorunlu kılın.
- Eski veya geri alınmış güven kökleri için rollback saldırısını hesaba katın.
Self-hosted runner güvenliği
Self-hosted runner, build cache, Docker socket, registry credential ve önceki job dosyalarını taşıyabilir. Keyless imzalama uzun ömürlü signing key'i kaldırsa da saldırgan runner'ı ele geçirirse izin verilen workflow kimliği altında kötü amaçlı digest imzalatabilir.
Ephemeral runner kullanmak, her işten sonra ortamı yok etmek ve production imzalama job'ını diğer işlerden ayırmak güçlü önlemlerdir. Docker socket erişimi host root eşdeğeri olabilir. Runner grupları, repository erişimi ve network egress izinleri daraltılmalıdır.
Workflow bütünlüğü
İmzanın güven değeri workflow dosyasının değişiklik kontrolü kadar yüksektir. Saldırgan build-sign.yml dosyasını değiştirip kendi payload'ını üretirse sertifika hâlâ beklenen path'i gösterebilir.
- .github/workflows dizisini CODEOWNERS ile güvenlik ekibine bağlayın.
- Main branch'e doğrudan push'u kapatın.
- Zorunlu review ve başarılı test koşulu uygulayın.
- Release environment için ayrı onay ve deployment protection kullanın.
- Reusable workflow kullanılıyorsa çağrılan revision'ı sabitleyin.
- Repository admin bypass yetkilerini izleyin.
- Audit log'da workflow, environment ve branch policy değişikliklerine alarm kurun.
Anahtar tabanlı imzalama ne zaman gerekir?
Keyless varsayılan olarak önerilse de her ortam OIDC veya public transparency log kullanamaz. Donanım güvenlik modülü, kurumsal KMS, uzun süreli offline doğrulama veya yasal anahtar sahipliği gereksinimi key-based modeli gerekli kılabilir.
Bu seçimde private key erişimi, rotasyon, yedekleme, iptal, çoklu imza ve acil durum prosedürü tasarlanmalıdır. “Keyless yoksa local cosign.key'i CI secret'a koy” kolay çözüm gibi görünür, fakat kalıcı signing key'in toplu log veya runner üzerinden sızma riskini büyütür.
Rotasyon ve iptal yaklaşımı
Keyless modelde geçici anahtar çok kısa ömürlüdür; asıl kalıcı güven repository ve OIDC kimlik kuralındadır. Bir workflow ele geçirilirse eski imzalar otomatik olarak geçersiz olmaz. Olay zaman çizelgesi, güvenilen revision ve Rekor kayıtları üzerinden hangi artefaktların etkilendiği belirlenmelidir.
Policy'den etkilenen identity'yi çıkarmak yeni dağıtımları durdurur. Registry'deki şüpheli digest'ler karantinaya alınmalı, cluster envanterinde çalışan pod'lar digest bazında aranmalı ve temiz revision'dan yeniden build edilmelidir. Tag silmek yeterli değildir; çalışan node imaj cache'i ve rollout geçmişi de kontrol edilmelidir.
Doğrulama testleri
| Test | Beklenen sonuç |
|---|---|
| Doğru repo, workflow ve main branch imzası | Kabul |
| Aynı imajı başka repository kimliğiyle imzalama | Ret |
| Geçerli imza fakat farklı issuer | Ret |
| İmzalı tag'i başka digest'e taşıma | Yeni digest ret |
| İmzasız imaj | Ret veya audit aşamasında uyarı |
| SBOM predicate type farklı | İlgili attestation politikası ret |
| Rekor/ağ kesintisi | Belgelenmiş fail-open veya fail-closed davranışı |
| Workflow dosyası farklı branch'te | Production identity politikası ret |
Negatif testler pozitif test kadar önemlidir. Yalnız doğru imajın geçtiğini görmek, yanlış kimliğin de geçtiği geniş bir regex hatasını ortaya çıkarmaz.
Gözlemlenebilirlik
İmzalama ve admission kararları SIEM'e taşınmalıdır. Her olayda image digest, registry, repository, certificate identity, OIDC issuer, workflow run ID, git revision, verification sonucu ve policy sürümü bulunmalıdır.
Alarm örnekleri:
- Beklenmeyen repository veya workflow kimliğinden imza
- Main dışı ref'ten production imajı
- Kısa sürede olağandışı sayıda imzalama
- Admission politikasında wildcard genişlemesi
- İmzasız imaj için istisna açılması
- Aynı tag'in yeni digest'e taşınması
- Runner veya environment korumasının kapatılması
Kademeli üretime geçiş planı
- Envanter: Registry, repository, workflow ve cluster'lardaki bütün imaj kaynaklarını çıkarın.
- Pilot: Düşük riskli tek imajda digest üretimi ve keyless imza uygulayın.
- Kimlik doğrulama: Sertifika claim'lerinden kesin issuer ve identity değerini kaydedin.
- Attestation: SBOM ve provenance üretimini aynı digest'e bağlayın.
- Audit admission: İmzasız ve yanlış kimlikli imajları raporlayın, henüz engellemeyin.
- Negatif test: Farklı repo, branch, issuer ve unsigned senaryolarını deneyin.
- Canary enforce: Sınırlı namespace'te ret politikasını açın.
- İstisna yönetimi: Süreli, sahipli ve denetlenebilir break-glass süreci kurun.
- Production: Varsayılan reddet politikasını kademeli genişletin.
- Sürekli denetim: Action SHA, Cosign sürümü, root metadata ve policy claim'lerini güncelleyin.
Üretim kontrol listesi
- İmaj build çıktısı digest ile alınıyor.
- İmza tag yerine digest'e atılıyor.
- id-token: write yalnız imza job'ında bulunuyor.
- Third-party action'lar immutable commit SHA ile sabit.
- Workflow değişiklikleri CODEOWNERS ve branch protection altında.
- Pull request işleri production push veya imza yapamıyor.
- Verification kesin issuer ve workflow identity kullanıyor.
- Wildcard identity regex üretimde kullanılmıyor.
- SBOM ve provenance aynı subject digest'e bağlı.
- Admission policy audit ve negatif testlerden geçti.
- Offline/ağ kesintisi davranışı belgelenmiş.
- İstisnaların sahibi, nedeni ve bitiş tarihi var.
- Runner kalıcı sır ve workspace bırakmıyor.
- İmzalama ve ret olayları merkezi olarak izleniyor.
Sık sorulan sorular
Keyless gerçekten anahtarsız mı?
Hayır. Cosign geçici anahtar çifti üretir. Fark, uzun ömürlü private key saklamamanız ve imzayı kısa ömürlü sertifikayla OIDC kimliğine bağlamanızdır.
Geçerli herhangi bir Sigstore imzası yeterli mi?
Hayır. Saldırgan da kendi kimliğiyle geçerli imza üretebilir. Beklenen issuer, repository, workflow ve ref kesin olarak doğrulanmalıdır.
Tag imzalamak neden zayıf?
Tag hareketlidir. Doğrulanan tag daha sonra başka digest'e işaret edebilir. İmza ve dağıtım kararı immutable digest üzerinde olmalıdır.
SBOM imzası zafiyet olmadığını kanıtlar mı?
Hayır. Yalnız belirli kimliğin belirli subject için bu SBOM'u beyan ettiğini kanıtlar. Bileşen doğruluğu ve zafiyet politikası ayrıca değerlendirilir.
Rekor kaydı olmadan doğrulama yapılabilir mi?
Bağlama ve bundle biçimine göre offline kanıt kullanılabilir. Ancak güven kökü, signed timestamp ve inclusion proof doğru doğrulanmalıdır; “internete çıkamıyoruz” gerekçesiyle identity kontrolü kaldırılmamalıdır.
Private repository adı şeffaflık günlüğüne girer mi?
Kullanılan kimlik ve attestation metadata'sına bağlı olarak hassas bağlam açığa çıkabilir. Public-good instance kullanmadan önce veri sınıflandırması yapılmalı; gerekirse private Sigstore veya farklı imzalama modeli seçilmelidir.
Sonuç
Sigstore ve Cosign, yazılım artefaktını yalnız hash ile değil, kısa ömürlü sertifikaya bağlanmış CI kimliğiyle doğrulama imkânı verir. Uzun ömürlü signing key'i kaldırmak operasyonel riski azaltır; fakat güveni workflow, repository izinleri ve OIDC claim politikasına taşır.
Başarılı uygulamanın özü şudur: action'ları sabitle, güçlü event'leri ayır, imajı digest ile üret, dar workflow kimliğiyle imzala, aynı kimliği admission katmanında doğrula, SBOM ve provenance'u aynı digest'e bağla, yanlış kimlikleri negatif testlerle reddet. İmza ancak dağıtım politikasına dönüştüğünde gerçek güvenlik kontrolü olur.
Kaynaklar
- Sigstore – Genel Bakış
- Sigstore – Keyless Signing Overview
- Sigstore – CI Quickstart
- Cosign – Signing Containers
- Cosign – Verifying Signatures
- Cosign – Signing Blobs
- SLSA v1.1 – Provenance
- GitHub Docs – OpenID Connect
- GitHub Docs – Security Hardening for GitHub Actions
TR Siber Ekibi