Kullanıcı bir kurulum dosyasını indirdiğinde uygulanan sessiz soru şudur: bu ikili dosyayı, gerçekten geliştiren kişi mi yayımladı? Kaynak kodu incelemek, bağımlılıkları denetlemek, derlemeyi temiz bir ortamda yapmak — bunların hepsi, dosya kullanıcının makinesine ulaşana kadar geçerlidir. Aradaki son halka, yani derleme çıktısından indirme sayfasına kadar olan yol, çoğu ekip için hâlâ zayıftır. Kod imzalama, tam olarak bu halkayı kriptografiyle kapatır. Güven vermekle güveni kanıtlamak arasında fark budur; imza, kanıtın ta kendisidir.

Bu yazıda imzanın ne söylediğini ve ne söylemediğini, küçük ekiplerin imzalamaya nasıl başlayacağını ve anahtarın nasıl korunacağını anlatacağız.

İmza aslında ne söyler?

İmza, ikili dosyanın özetini özel anahtarla şifreleyip dosyanın yanına koymaktan ibarettir. Doğrulayan taraf, geliştiricinin açık anahtarıyla özeti yeniden hesaplar; örtüşmezse dosya yolda değişmiştir. Ama imzanın anlattığı iki ayrı cümle vardır ve bunlar karıştırılmamalıdır: birincisi "bu dosya, bu anahtarın sahibi tarafından imzalandı"; ikincisi "bu anahtarın sahibi, o geliştiricidir". İkinci cümleyi kriptografi değil, sertifika ve güven ağı kurar. Bu yüzden imzalama altyapısı, kimlik doğrulaması altyapısından ayrı düşünülemez.

# Yayın öncesi doğrulama: imza ve sağlama birlikte kontrol edilir
cosign verify --certificate-identity-regexp "https://github.com/ornek/proje/.*" \
  registry.example/app:1.42.0
sha256sum -c SHA256SUMS 2>/dev/null || echo "sağlama dosyası eksik!"

Devreye alma: küçük adımlar

Büyük kurumsal bir altyapı kurmak zorunda değilsiniz. İlk adım, derleme boru hattınızın her yayın öncesi dosyanın özetini (SHA-256) yazması; ikinci adım, özet dosyasını imzalaması; üçüncü adım, imzayı yayın sayfasında kullanıcıya göstermesidir. Kullanıcı için bu, bir komutla doğrulama demektir; ekip için ise "derlemeden çıkan dosya ile sunucudaki dosya aynı mı" tartışmasını bitirir. Konteyner dünyasında imzalama, görüntü kayıt defterine (registry) gömülür ve sürekli entegrasyon doğrulaması otomatik hale gelir.

Adımların sırası da önemlidir: önce imzalamayı ve doğrulamayı otomatize edin, anahtar yönetimini sonraya bırakmayın. Anahtar sonradan taşındığında, eski anahtarla imzalanan yapımların geçerliliği sorusu ortaya çıkar; bunu baştan tasarlamak, ileride kriz masasını önler.

Güven, kullanıcıya kadar taşınmalı

İmzalamanın en gözden kaçan tarafı, doğrulamanın kullanıcı tarafında yapılmasıdır. İndirme sayfanızda özeti ve doğrulama komutunu göstermek, yalnızca ileri düzey kullanıcıların işine yarar sanılır; oysa otomasyonla gelen her istemci, bu doğrulamayı ücretsiz yapar. Paket yöneticileri (npm, pip, Homebrew) imzayı şeffaf şekilde kontrol eder; sizin işiniz, onlara imzalanmış bir şey vermek. Doğrulama örneğini indirme sayfasına koymak da küçük bir sinyaldir: kullanıcısına "dosyamın aynısını aldığından emin ol" diyen satıcı, güvenliğe özen gösteren satıcıdır.

Bir de ekip içi disiplin var: imzalama, yalnızca yayın öncesi değil, güncelleme kanallarının her halkasında tekrarlanır. Bugün imzaladığınız bir güncelleme, altı ay sonra otomatik güncelleme mekanizmasına geldiğinde de imzası doğrulanmalıdır; aksi halde saldırgan, güncelleme yolunu imzasız bırakan pencereyi kullanır.

Kod imzalama, güvenlik zincirinin görünmeyen ama son halkasıdır. Zincirin önceki halkaları — kaynak incelemesi, bağımlılık denetimi, temiz derleme — zaten elinizde; son halkayı eklemek, bir günün değil bir haftanın işidir. Ödeyen, güven hattını kullanıcılarınızın eline kadar uzatan altyapıdır.