Firefox 155 ile İki Haftalık Sürüm Döngüsü: Kurumsal Güvenlik Ekipleri İçin Geçiş Rehberi
Firefox 155 ile başlayan iki haftalık sürüm düzeninde kurumsal test halkaları, politika şablonları, portal algılama alan adı ve geri dönüş planı nasıl yönetilmeli?
Firefox 155 neden farklı bir sürüm?
Mozilla, Firefox 155’i 1 Eylül 2026 tarihinde yayımladı ve bu sürümle birlikte kararlı kanalın dört haftalık döngüden iki haftalık düzene geçişini başlattı. Değişiklik, yeni özelliklerin ve düzeltmelerin kullanıcılara daha kısa aralıklarla ulaşmasını amaçlıyor.
Kuruluşlar açısından asıl konu yalnızca sürüm numarasının değişmesi değildir. Test, dağıtım, politika doğrulama ve geri dönüş süreçlerinin artık daha sık çalışması gerekeceği için tarayıcı yönetiminin takvimi yeniden tasarlanmalıdır.
İki haftalık döngü güvenliği nasıl etkiler?
Daha kısa yayın aralığı, güvenlik ve kararlılık düzeltmelerinin daha hızlı teslim edilmesini sağlayabilir. Buna karşılık güncellemeleri uzun süre bekleten bir kurum birkaç sürüm geride kalabilir ve destek ekiplerinin değişiklikleri tek seferde değerlendirmesi zorlaşabilir.
Yeni takvim, test yapmadan güncelleme yapmak anlamına gelmez. Amaç küçük ve sürekli doğrulamalarla güncelleme borcunu azaltmak; kritik iş uygulamalarını, kimlik doğrulama akışlarını ve güvenlik eklentilerini düzenli olarak sınamaktır.
Firefox 155 ile gelen kurumsal değişiklikler
Mozilla’nın kurumsal sürüm notunda Windows için DisableLaunchOnLogin ilkesinin eklendiği belirtiliyor. Bu politika, Firefox’un oturum açılışında otomatik başlatılmasını kurumsal olarak engellemek isteyen yöneticilere merkezi bir seçenek sunuyor.
Aynı notlarda SitePolicies politikasına HttpsOnly seçeneğinin eklendiği ve belirli sitelerin HTTP üzerinden yüklenmesinin engellenebildiği açıklanıyor. Bu yetenek, eski iç uygulamalar ile modern HTTPS zorunluluğu arasında kontrollü bir geçiş planı kurmak için kullanılabilir.
- Mevcut politika şablonlarını Firefox 155 uyumlu sürümle karşılaştırın.
- HTTPS zorunluluğunu önce sınırlı bir iç site grubunda deneyin.
- Oturum açılış davranışını Windows pilot cihazlarında doğrulayın.
- Kimlik doğrulama ve güvenlik eklentilerinin çalışmasını kaydedin.
Portal algılama alan adı değişikliği
Firefox 155 ile bağlantı ve captive portal denetimlerinde kullanılan alan adı detectportal.firefox.com yerine firefox-portal-detection.com oluyor. DNS filtreleri, proxy kuralları veya güvenlik duvarı izin listeleri eski alan adına göre düzenlenmişse kullanıcılar beklenmeyen bağlantı uyarıları yaşayabilir.
Ağ ekipleri yeni alan adını gelişigüzel geniş bir izinle açmamalıdır. Önce DNS ve proxy günlüklerinde kullanım doğrulanmalı, yalnızca gereken hedef ve protokoller için kayıtlı bir değişiklik uygulanmalıdır.
Güvenli dağıtım halkası oluşturun
İlk halka tarayıcıyla yoğun çalışan BT ve güvenlik ekiplerinden, ikinci halka farklı iş uygulamalarını temsil eden gönüllü kullanıcılardan oluşabilir. Son halka ise pilot sonuçları kabul edildikten sonra genel kullanıcı grubuna açılmalıdır.
Her halkada sürüm numarası, uygulama oturumları, sertifika davranışı, proxy bağlantısı, dosya indirme politikaları ve eklenti uyumluluğu ölçülmelidir. Sorun çıktığında hangi sürüme ve hangi yapılandırmaya dönüleceği önceden yazılı olmalıdır.
- Yeni sürümü küçük pilot grubuna yayınlayın.
- İş uygulamaları ve güvenlik politikaları için otomatik kontrolleri çalıştırın.
- Hata oranı ve destek talebi eşiğini değerlendirin.
- Genel dağıtımı kademeli tamamlayıp sürüm uyumunu raporlayın.
ESR ve hızlı kanal kararı
Hızlı sürüm kanalındaki değişim her kuruluşun aynı modeli kullanmasını gerektirmez. Uzun doğrulama süresine ihtiyaç duyan ortamlarda Firefox ESR seçeneği, daha seyrek özellik değişikliğiyle kurumsal uygulamaları yönetmeye yardımcı olabilir.
Karar yalnızca alışkanlığa göre verilmemelidir. Güvenlik düzeltmelerine erişim, uygulama uyumluluğu, destek kapasitesi ve yasal gereksinimler değerlendirilerek kanal bazında belgelenmiş bir politika oluşturulmalıdır.
İlk hafta için kontrol listesi
Firefox 155’in kuruluş envanterindeki yayılım oranı görünür hale getirilmeli ve güncelleme başarısız cihazlar ayrı kuyruğa alınmalıdır. Eski portal algılama alan adına bağlı ağ kuralları ile yeni alan adı için yapılan değişiklikler kayıt altına alınmalıdır.
Kapanış raporu yalnızca dağıtım yüzdesini göstermemelidir. Pilot bulguları, politika doğrulaması, uygulama sahiplerinin onayı, geri dönüş hazırlığı ve çözülmemiş istisnalar aynı kayıtta bulunmalıdır.