Sertifikalar uzun süre “çalıştığı sürece dokunulmayan” bileşenlerdi. Çoğu ekip için bu sertifikalar bir kez alınır, sistemlere yerleştirilir ve yıllarca dokunulmadan çalışırdı. Yeni düzenleme bu yaklaşımı tamamen geçersiz kılıyor.
CA/Browser Forum’un aldığı kararla birlikte, 1 Mart 2026’dan itibaren oluşturulan tüm kod imzalama sertifikalarının geçerlilik süresi maksimum 460 gün olacak.
Bu değişiklik ilk bakışta sadece bir süre kısaltması gibi görünebilir. Ancak pratikte, geliştirme süreçlerinden güvenlik operasyonlarına kadar uzanan daha geniş bir dönüşümü tetikliyor.
Neden Şimdi?
Bu kararın arkasında iki farklı ama birbirini tamamlayan problem var: biri doğrudan saldırılar, diğeri ise operasyonel kör noktalar.
2024’te ortaya çıkarılan bir saldırı kampanyasında, saldırganların geçerli kod imzalama sertifikalarıyla zararlı yazılım imzaladığı görüldü. Dosyalar güvenilir imza taşıdığı için, klasik güvenlik kontrolleri bu zararlı payload’ları ayırt edemedi.
Diğer tarafta ise daha “sessiz” ama en az onun kadar yıkıcı bir problem var: unutulan sertifikalar.
Microsoft’un yaşadığı büyük kesintiler bu durumu net biçimde ortaya koydu. Supply chain içindeki bağımlılıklarda süresi dolan sertifikalar, sistemlerin beklenmedik şekilde durmasına neden oldu. Modern yazılım mimarisinde her bileşen bir sertifika taşıyor ve bu sertifikalar çoğu zaman gözden kaçıyor.
Bu iki problem birleştiğinde ortaya çıkan tablo şu:
- Sertifikalar saldırı yüzeyine dönüşebiliyor
- Aynı zamanda operasyonel kırılma noktası haline geliyor
460 günlük model, tam olarak bu iki riski aynı anda daraltmayı hedefliyor.
460 Günlük Süre Aslında Ne Anlama Geliyor?
Yeni süre, rastgele seçilmiş bir sayı değil. Ortalama bir saldırganın supply chain’e sızma süresi yaklaşık 15 ay.
460 gün (~15 ay) ile:
- Sertifikalar bu pencere dolmadan rotate ediliyor
- Uzun süreli key compromise senaryoları sınırlandırılıyor
Ama daha önemli bir etkisi var: Organizasyonları zorunlu olarak disipline ediyor
Artık:
- Sertifika yönetimi “unutulabilir” bir konu değil
- Pipeline’ın doğal bir parçası olmak zorunda
Geliştirme ve Operasyon Tarafında Neler Değişecek?
Bu değişiklik en çok development ve release süreçlerini etkileyecek. Çünkü sertifika artık bir “asset” değil, sürekli dönen bir operasyon bileşeni haline geliyor.
Öne çıkan kırılma noktaları:
- Build sistemleri yeniden tasarlanmalı
Uzun süre aynı sertifikayı kullanan yapı sürdürülemez.
Planlı rotation ve dinamik sertifika yönetimi şart. - Legacy signing araçları risk altında
Hardcoded path’ler ve tek sertifika varsayımı yapan sistemler kırılacak. - Air-gapped ortamlar daha karmaşık hale gelecek
Özellikle kamu, sağlık ve endüstriyel sistemlerde sertifika taşıma ve yenileme süreçleri daha sıkı planlanmalı. - Key leak etkisi azalacak
Kısa ömürlü sertifikalar, compromise sonrası etki alanını daraltır. - Compliance ekipleri hızlanmak zorunda
EV ve OV sertifikalar daha sık yenileneceği için takvimler sıkışır.
Kısacası, sertifika yönetimi artık “arka planda çalışan bir süreç” değil, doğrudan release ritmini belirleyen bir faktör.
Kritik Ama Genelde Atlanan Konu: Timestamping
Bu dönüşümde en kritik ama en çok ihmal edilen detaylardan biri timestamping.
Doğru yapılandırılmış bir timestamp şu farkı yaratır:
Sertifika süresi dolsa bile, imzalanmış kod geçerliliğini korur.
Bu sayede:
- Eski versiyonlar bir anda “güvensiz” hale gelmez
- Kullanıcı tarafında kırılmalar yaşanmaz
Ancak sahadaki gerçek şu:
- Birçok sistem timestamp’i default olarak eklemiyor
- Bazı legacy araçlar timestamp doğrulamıyor
Bu yüzden yapılması gerekenler oldukça net:
- Tüm signing süreçleri gözden geçirilmeli
- Timestamp zorunlu hale getirilmeli
- Legacy doğrulama mekanizmaları güncellenmeli
Aksi halde, 460 günlük model altında en büyük operasyonel problem bu noktada yaşanacak.
HSM ve Key Yönetimi: Pazarlık Konusu Değil
Kod imzalama tarafında bir diğer değişmeyen gerçek:
HSM kullanımı zorunlu
Yeni modelle birlikte:
- Her sertifika yenilemede key rotation yapılmalı
- Private key exposure süresi minimize edilmeli
EV ve OV sertifikalar arasındaki farklar devam etse de:
- Geçerlilik süresi aynı (460 gün)
- Güvenlik gereksinimleri aynı seviyede
Asıl Değişim: Operasyonel Ritmin Dönüşmesi
Bu değişikliğin en büyük etkisi teknik değil, operasyonel.
Eskiden:
- Sertifika yönetimi nadiren yapılan bir işti
Şimdi:
- Sürekli akan bir süreç haline geliyor
Bu da şu sonuçları doğuruyor:
- Expire kaynaklı sürprizler azalır
- Pipeline daha öngörülebilir hale gelir
- Release süreçleri stabilleşir
Modern pratikleri benimsemiş ekipler için bu değişim aslında doğal bir evrim. Ancak manuel süreçlere bağımlı organizasyonlar için ciddi bir kırılma yaratacak.
Post-Quantum Döneme Açılan Kapı
460 günlük model sadece bugünü çözmüyor, aynı zamanda geleceğe hazırlıyor.
Önümüzdeki birkaç yıl içinde:
- RSA gibi algoritmalar kademeli olarak terk edilecek
- Post-quantum cryptography (PQC) gündeme gelecek
Bu noktada organizasyonların:
- Tüm kriptografik varlıklarını envanterlemesi
- Merkezi yönetim kurması
- Algoritma geçişlerine hazır olması
gerekiyor.
Kısa sertifika süreleri bu dönüşüm için bir “alıştırma” aslında.
Nereden Başlamalı?
Bu değişime adapte olmak için en pratik yaklaşım, süreci aşamalı ele almak:
1. Görünürlük kazan
Hangi sertifika nerede kullanılıyor, kim sorumlu, ne zaman expire?
2. Timestamp’i standartlaştır
Her imza için zorunlu hale getir.
3. Otomasyonu devreye al
CI/CD pipeline’larına entegre, self-service süreçler kur.
4. Policy ve governance oluştur
HSM kullanımı, algoritmalar, audit trail.
5. Crypto-agility geliştir
Algoritma değişimlerine ve PQC’ye hazır hale gel.
Erken adapte olan ekipler için bu değişim, daha stabil ve öngörülebilir sistemler anlamına geliyor. Geç kalanlar için ise sertifika krizleri, release gecikmeleri, operasyonel yük kaçınılmaz olacak. Bu yeni dönem için tedbirinizi en iyi uzmanlık ve en iyi çözüm ile almak için bize her zaman info@quasys.com.tr üzerinden ulaşabilirsiniz.
