Quantum-Safe DevOps: Mevcut CI/CD Pipeline’larınızı Kriptografik Borçtan Koruyun

DevOps pratiklerinde güvenlik çoğu zaman pipeline’a bir SAST/DAST aracı eklemek, image’ları Trivy ile taramak ve artifact’leri RSA-2048 ile imzalamaktan ibaret sanılıyor. Oysa kapıda sessizce büyüyen bir problem var: kriptografik borç. Kuantum bilgisayarlar pratik ölçeğe ulaştığında, bugün asimetrik kriptografi üzerine kurduğumuz pipeline güvenliği mimarisinin tamamı domino taşı gibi devrilecek. Daha kötüsü, tehdit “o gün” başlamayacak. Harvest Now, Decrypt Later (HNDL) saldırıları yüzünden bugün depolanan imzalar ve şifreli trafik yarın aleyhimize delil olarak kullanılacak. Bu yazıda teorik fizik tartışmalarına girmeden, doğrudan production hatlarında uygulayabileceğiniz quantum-safe dönüşüm stratejilerini ve pratik konfigürasyonları ele alıyoruz.

Neden şimdi? Mosca teoremi ve CI/CD gerçekliği

Kuantum tehdidini konuşurken çoğu mühendis “Q-Day gelene kadar en az 8-10 yılımız var” rehavetine kapılıyor. Kriptograf Michele Mosca’nın denklemi durumu net özetliyor: X + Y > Z ise sisteminiz zaten risk altındadır. Burada X verinizin gizli kalması gereken süre, Y sistemlerinizi kuantum dirençli hale getirme süreniz, Z ise kuantum bilgisayarların RSA/ECC’yi kıracağı tahmini tarihtir.

Bir bankanın veya fintech girişiminin CI/CD pipeline’ında build edilen artifact’lerin, firmware imajlarının ya da Git commit’lerinin imza geçerlilik ömrü bazen 10-15 yılı bulur. Bugün artifact imzalarken ML-DSA (CRYSTALS-Dilithium) veya stateful hash-based imzalara geçmezseniz, 2030’da geçmişe dönük supply chain doğrulamalarınızın matematiksel hiçbir güvencesi kalmayacak.

1. Git iletişimi: OpenSSH hibrit anahtar değişimine geçiş

Git runner’larınız repository’lere SSH üzerinden bağlanıyorsa, aradaki trafik bugün kaydedilip gelecekte çözülebilir. OpenSSH 9.0 ve üzeri sürümler, varsayılan olarak Streamlined NTRU Prime ve X25519 hibrit algoritmasını (sntrup761x25519-sha512@openssh.com) destekliyor. Bu hibrit yapı şu anlama gelir: Klasik X25519 kırılsa bile kuantum dirençli katman sizi korur, yeni algoritmada bilinmeyen bir açık çıksa bile klasik katman güvence sağlar.

CI/CD runner’larınızın ve Git sunucularınızın (GitLab, self-hosted Gitea vs.) SSH konfigürasyonunu hibrit moda geçirmek için /etc/ssh/ssh_config (veya sunucu tarafında sshd_config) dosyasındaki KexAlgorithms direktifini güncelleyin:

# /etc/ssh/sshd_config veya CI Runner ~/.ssh/config
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

# Host key olarak klasik Ed25519 kullanmaya devam etseniz bile,
# oturum anahtarı değişimi (KEX) kuantum dirençli hale gelir.
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512

Runner üzerinde bağlantının hibrit algoritma kullanıp kullanmadığını doğrulamak için debug çıktısını şu komutla inceleyin:

ssh -vvv git@gitlab.internal.corp 2>&1 | grep "kex: algorithm:"
# Çıktıda şunu görmelisiniz:
# debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com

2. Artifact imzalama: Cosign ve post-quantum algoritmalar

Yıllardır Cosign ile container imzalıyoruz, ama bu imzalar ECDSA P-256 veya RSA-4096’ya dayanıyor. Shor algoritmasını çalıştırabilen bir kuantum bilgisayar karşısında P-256’nın ömrü birkaç saniyedir. NIST, Ağustos 2024’te resmi FIPS standartlarını yayımladı: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) ve FIPS 205 (SLH-DSA).

Şu an üretim ortamlarında saf PQC (Post-Quantum Cryptography) kullanmak, imza boyutları yüzünden overhead yaratabilir (RSA’in 256 baytına karşılık Dilithium-3’ün ~3.3 KB boyutu). Bu yüzden ara çözüm hibrit imzalar veya liboqs entegrasyonudur. Sigstore ekosistemi PQC desteğini deneysel olarak sürdürürken, build pipeline’ınızda OpenSSL 3.x ve oqsprovider kullanarak kendi post-quantum PKI altyapınızı ayağa kaldırabilirsiniz.

Runner container’ı içinde ML-DSA-65 (Dilithium3) tabanlı bir keypair üretip artifact imzalamak için örnek bir yaklaşım:

# liboqs ve oqsprovider kurulu bir base image üzerinde:
# 1. Post-Quantum Private Key üret (FIPS 204 / ML-DSA-65)
openssl req -x509 -new -newkey mldsa65 \
  -keyout pqc_private.key \
  -out pqc_cert.crt \
  -nodes -subj "/CN=CI-PQC-Signer/O=KertenKerem" \
  -provider oqsprovider -provider default

# 2. Release artifact'ının (örneğin binary veya tarball) SHA-256 hash'ini al
sha256sum release-v1.4.0.tar.gz | awk '{print $1}' > artifact.digest

# 3. Hash'i ML-DSA anahtarıyla imzala
openssl dgst -sign pqc_private.key \
  -provider oqsprovider -provider default \
  -out artifact.sig artifact.digest

# 4. Doğrulama testi (Deployment aşamasında çalışacak kod)
openssl dgst -verify <(openssl x509 -in pqc_cert.crt -pubkey -noout -provider oqsprovider) \
  -signature artifact.sig \
  -provider oqsprovider -provider default \
  artifact.digest

Bu akışın klasik Cosign akışından tek farkı, kullanılan matematiksel yapının lattice-based (örgü tabanlı) olması. Bir imzayı production cluster’ında Admission Controller seviyesinde doğrulamak istiyorsanız, gatekeeper veya Kyverno pod’larınızın da liboqs kütüphanesini tanıyan OpenSSL/BoringSSL runtime’larına sahip olması gerektiğini unutmayın.

3. Kriptografik envanter: CBOM (Cryptographic Bill of Materials)

SBOM (Software Bill of Materials) çıkarmayı öğrendik, ama uygulamanızın hangi şifreleme kütüphanelerine, hangi anahtar uzunluklarına ve hangi TLS versiyonlarına bağımlı olduğunu biliyor musunuz? Kodunuz doğrudan crypto/tls çağırıyor olabilir, ama üçüncü parti bir Go paketi derleme anında RSA-1024’e hardcode edilmiş eski bir algoritma kullanıyor olabilir.

CycloneDX standardı, CBOM konseptiyle kriptografik varlıkların taranmasını ve listelenmesini destekler. CI aşamasına ekleyeceğiniz bir CBOM adımı, kuantum göçü (migration) başladığında envanter çıkarmak için harcayacağınız ayları kurtarır.

# Syft ile projenin kriptografik bağımlılıklarını içeren SBOM JSON çıktısı üretme
syft dir:. -o cyclonedx-json=bom.json

# bom.json içerisindeki zayıf kriptografik bağımlılıkları CI aşamasında filtreleme
jq '.components[] | select(.name | test("crypto|tls|ssl|ssh")) | {name: .name, version: .version}' bom.json

Pipeline’ınızda kurumsal bir tarama yapıyorsanız, IBM CBOM Toolkit gibi statik analiz araçlarını derleme öncesi kancalara (pre-commit / CI gate) bağlayabilirsiniz. Böylece kod tabanındaki crypto.GenerateKey(rsa.Reader, 2048) gibi çağrılar CI seviyesinde hata verdirilerek engellenir:

# semgrep ile CI pipeline'ında kuantum-zayıf anahtar kullanımını fail etme örneği
semgrep --config=p/crypto \
  --lang=go \
  --pattern='rsa.GenerateKey($R, 2048)' \
  --error \
  ./src

4. HashiCorp Vault ve Transit Secret Motoru

Pipeline içinde hassas environment variable’ları şifrelemek (envelope encryption) için yaygın olarak HashiCorp Vault Transit Engine kullanılır. Mevcut transit engine konfigürasyonunuz büyük olasılıkla data encryption için aes256-gcm96, anahtar değişimi için ise ECDSA/RSA kullanıyordur. AES-256, kuantum bilgisayarlar karşısında güvenlidir (Grover algoritması anahtar arama uzayını 2^128’e düşürür, bu da hâlâ pratikte kırılamaz bir seviyedir). Asıl problem, Vault client ile server arasındaki mTLS oturumu ve transit key’lerin wrap edilme yöntemidir.

Vault mTLS iletişimini güvenceye almak için reverse proxy ve ingress seviyesinde TLS 1.3 zorunlu tutulmalı, desteklenen cipher suite’ler de sınırlandırılmalıdır:

# NGINX veya Cloud Ingress TLS 1.3 konfigürasyonu
ssl_protocols TLSv1.3;
# Kuantum sonrası anahtar değişimini destekleyen hibrit gruplar (X25519MLKEM768)
# Envoy / Nginx son sürümlerinde BoringSSL desteği ile aktifleştirilebilir
ssl_ecdh_curve X25519MLKEM768:x25519:secp384r1;

Cloudflare ve Google Chrome’un halihazırda üretimde kullandığı X25519MLKEM768 hibrit anahtar değişim mekanizması, pipeline runner’larınız ile internal API’larınız arasındaki veri trafiğini HNDL saldırılarına karşı bugünden korur.

DevOps mühendisleri için aksiyon planı

Kriptografik dönüşüm, son gün yapabileceğiniz bir “hotfix” değildir. Bugün atmanız gereken adımlar şunlar:

1. SSH altyapısını denetleyin: Tüm CI runner ve bastion host’larda OpenSSH 9.0+ sürümüne geçin ve hibrit KEX algoritmalarını zorunlu kılın.
2. CBOM üretin: Build süreçlerinize SBOM yanında kriptografik varlık taramalarını ekleyin; kütüphanelerinizdeki sert kodlanmış asimetrik anahtar boyutlarını tespit edin.
3. AES-128’i bırakın: Simetrik şifrelemede taban çizgisi olarak her yerde AES-256 ve ChaCha20-Poly1305 kullanın.
4. Kriptografik esneklik (crypto-agility) kazanın: Kod içinde algoritma isimlerini string parametre olarak geçmeyin; anahtar yönetimini soyutlayan provider katmanları kullanın. Böylece NIST FIPS 204/205 kütüphaneleri genel paket yöneticilerine tam girdiğinde yalnızca config değiştirerek göç edebilirsiniz.

Kuantum çağı geldiğinde pipeline’ları baştan yazmak zorunda kalmamak için mimarideki kriptografik borcu bugünden ödemeye başlayın.