Bu haftanın okuma sırasını aktif istismar belirliyor: CISA'nın NetScaler için eklediği yeni KEV kaydı, cihaz envanterine yeniden dönmek için yeterli neden. Altyapı tarafında cgroup v2 geçişini ve swap kullanımını ayrı kararlar olarak ele alıyorum; ilki yükseltme hazırlığı, ikincisi ölçüm gerektiren kapasite deneyi. AI tarafında ise odağı model isimlerinden erişim sınırlarına ve kanıt kalitesine kaydırıyorum. Bu sayıdaki öneriler özellikle internetten erişilen cihazları, Kubernetes node'larını veya özel ağa bağlanan geliştirme ajanlarını yöneten ekipler için. Öncelik her duyuruyu hemen uygulamak değil; hangi işin bakım takvimini değiştirmesi gerektiğini ayırmak. Üretimde bir ayarı açmadan önce beklenen faydayı, kabul edilebilir gecikmeyi ve geri dönüş koşulunu yazılı hale getirmek bu haftanın ortak çalışma önerisi.
NetScaler: yeni KEV kaydını önceki yamalarla karıştırmayın
CISA, 4 Ekim'de CVE-2026-88779'u aktif istismar kanıtına dayanarak KEV kataloğuna ekledi. Katalog kaydı, NetScaler ADC ve Gateway'deki bellek sınırı ihlalini hizmet reddine yol açabilen bir açık olarak tanımlıyor. Buradan uzaktan kod çalıştırma sonucu çıkarmamak gerekir; erişilebilen resmî kayıt bu iddiayı desteklemiyor.
NetScaler'ın CNA kaydında standart ADC ve Gateway dalları için 14.1-73.41 ile 13.1-64.28 öncesi sürümler etkilenmiş olarak listeleniyor. Bunları bütün NetScaler kurulumlarına uygulanabilecek tek bir güvenli sürüm listesi gibi okumayın. Aynı kayıt ADC için ayrıca farklı sürüm girdileri içeriyor; ürün dalınızı ve özel dağıtımınızı doğrulamadan paket seçmeyin. Tam Citrix bülteninin gövdesi bu araştırmada okunamadığı için SAML yapılandırmasına ilişkin önkoşulları burada kesinleştirmiyorum.
NetScaler yöneten ekip için ilk iş, değişiklik kaydına yalnız "Citrix güncellendi" yazmak yerine cihazın tam build bilgisini ve kapatılan CVE'yi koymak olmalı. Ardından bakım penceresini hizmet sürekliliği planıyla birlikte değerlendirin. Özellikle aynı platformda yakın zamanda başka bir yama uyguladıysanız, bu kaydın da kapandığını ayrıca gösterin. CISA kaydında ransomware kullanımı "Unknown"; bunu saldırı olmadığına ilişkin kanıt saymayın. Önerim, sürüm kontrolüne ek olarak olağandışı yeniden başlatmaları ve erişim sorunlarını olay zaman çizelgesinde incelemek; her kesintiyi de bu CVE'ye bağlamamak.
cgroup v2 geçişi yükseltme kontrolünün parçası
Kubernetes projesinin 6 Ekim tarihli açıklaması, v1.35'ten itibaren failCgroupV1 ayarının varsayılan olarak true olduğunu ve cgroup v1 kullanan node'da kubelet'in bu varsayılanla başlamadığını hatırlatıyor. Bu hafta yeni gelen bir varsayılan değil; eski node imajlarıyla yükseltme hazırlayanlar için yeniden gündeme taşınan bir uyumluluk sorunu. Yazı, geçici failCgroupV1: false istisnasının kaldırılmasını v1.38 için planlanmış olarak aktarıyor.
Çalışan node'u kontrol etmek yetmez; onu yeniden üreten imajı da doğrulayın. Resmî rehber, stat -fc %T /sys/fs/cgroup/ komutunda cgroup2fs çıktısını v2 kontrolü olarak veriyor ve kubelet ile container runtime'ın cgroup driver ayarlarının uyumlu olmasını istiyor. Yeni imajla açılan node'un aynı sonucu vermesini kabul kriteri yapın.
Geçiş notunda, cgroup dosya sistemini doğrudan okuyan yazılımların gözden geçirilmesi ve I/O ağırlıklı işlerde active_file kaynaklı bellek baskısının sırf v2'ye geçişle çözülmediği de belirtiliyor. Bu yüzden denemeye izleme ajanlarını dahil edin. Bir node'u boşaltıp yeni imajla açın; uygulamanın limit davranışını ve metriklerin devamlılığını kontrol edin. Geçici istisna gerekiyorsa sahibi ve kaldırılacağı tarih belli olsun.
Node swap: kapasite kazancını kendi yükünüzde ölçün
5 Ekim'deki Kubernetes yazısının yazarları, yerel SSD destekli swap deneylerinde gVisor içindeki Python sandbox kapasitesini 80 eşzamanlı oturumdan 240'a çıkardıklarını bildiriyor. Bu sonuç, sizin uygulamanız için üç kat kapasite taahhüdü değil. Deney, atıl kalan belleğin diske taşınabildiği iş yüklerini inceliyor; aynı yazı, kernel derlemesinde bellek limitini fazla düşürmenin çalışma süresini uzattığını da gösteriyor.
Kubernetes belgelerine göre failSwapOn: false tek başına pod'lara swap kullandırmıyor; varsayılan NoSwap davranışından LimitedSwap'e geçiş ayrıca yapılandırılıyor. LimitedSwap kapsamında Burstable dışındaki QoS sınıfları swap kullanamıyor ve scheduler yerleşim kararında swap kapasitesini hesaba katmıyor. Dolayısıyla disk ekleyip bellek request değerlerini topluca düşürmeyi kapasite planı olarak önermiyorum.
Bu deneme, uzun süre bekleyen geliştirme sandbox'ları veya kesintili çalışan test ortamları için değerlendirilebilir; düşük ve öngörülebilir gecikme beklediğiniz servisten başlamayın. Ayrı bir worker havuzunda aynı yükü swap kapalı ve açık çalıştırıp p95 gecikmesini, disk beklemesini ve tamamlanan iş sayısını birlikte karşılaştırın. Resmî belge swap alanının şifrelenmesini öneriyor; ayrıca noswap desteği bulunmayan node'larda bellek tabanlı volume içeriklerinin diske taşınabileceği konusunda uyarıyor. Secret kullanan işlerde bu kontrolü deneyin önkoşulu yapın.
Codex Cloud'a tailnet erişimi verirken DNS notunu da doğrulayın
Tailscale, 6 Ekim'deki duyurusunda Codex Cloud'un Tailscale bağlantısıyla özel ağ kaynaklarına erişebildiğini anlatıyor. OpenAI'nin ortam belgesi de bu bağlantıyı doğruluyor ve auth key oluştururken Reusable ile Ephemeral seçeneklerini birlikte istiyor. Bu gelişme, özel paket deposuna veya test API'sine erişmesi gereken bulut görevlerini ilgilendiriyor; ben değerlendirmeyi önce test ortamıyla sınırlamayı öneriyorum.
İki resmî kaynak arasında dikkat isteyen bir fark var: Tailscale'in duyurusu MagicDNS ve split DNS'in çalışmadığını söylüyor; erişilen OpenAI belgesi ise ikisini de desteklediğini, özel servis adının IPv4'e çözülmesi gerektiğini belirtiyor. Güncel kurulum için ürünün kendi işletim belgesini esas almak daha makul, fakat bu farkın nedenini kaynaklar açıklamıyor. DNS desteğini kendi görevinizde sınamadan kesin kabul etmeyin.
Tailscale, görev makinelerinin anahtarı üreten kişinin erişimini devralması yerine tag:codex etiketiyle kurala bağlanmasını öneriyor. OpenAI ayrıca hedefin hem VPN kurallarında hem ortamın internet erişim ayarlarında izinli olmasını şart koşuyor. Kurulum incelemesine bu iki politika katmanını da alın. Gerekli test API'sine erişimin başarılı olduğunu görmekle yetinmeyin: aynı görevden üretim yönetim arayüzüne erişimin reddedildiğini de sınayın. Tekrar kullanılabilir anahtarın süresini ve iptal sorumlusunu kayda geçirin; geliştirme kolaylığı için genel tailnet erişimi açmayın.
Cloudflare'ın SecOps ajanlarında alınabilecek tasarım kararı
Cloudflare, 7 Ekim tarihli Managed Defense yazısında kanıt toplamayı model çıkarımından ayırdığını; kapsamı ve veri kaynaklarını önce uygulama kodunun sabitlediğini anlatıyor. Şirketin aktarımına göre uzman ajanlar bu kanıt paketine atıf yapıyor, uygulama kodu atıfları denetliyor ve son müdahale kararı analistte kalıyor. Bu araştırmada analist zamanından ne kadar tasarruf edildiğine ilişkin bağımsız bir ölçüm yapılmadı.
SOC otomasyonu geliştiren ekiplerin incelemesi gereken ayrıntı, başarısız sorguların nasıl raporlandığı. Cloudflare, başarısız bir sorguyu "kontrol edilmedi", eşleşme bulunmamasını ise ayrı bir durum olarak tuttuğunu; kanıt yetersizse sınıflandırma veya sonuç önerisi üretmediğini söylüyor. Kendi SOC otomasyonunuzda da zaman aşımını temiz sonuçtan ayırmayı kabul testi yapın. Aynı alarmı eksik veriyle tekrar çalıştırın ve raporun eksikliği açıkça gösterdiğini kontrol edin.
İlk denemeyi yalnız okuma yetkisiyle sınırlamak yerinde olur. İnceleme paketine kullanılan sorguyu ve zaman aralığını koyun; bir başka analist aynı veriden sonuca ulaşabiliyor mu, buna bakın. Otomatik engelleme yetkisini ayrı bir değişiklik olarak değerlendirin. Cloudflare'ın duyurduğu erişim, uygun uygulama güvenliği alarm ve vakaları için erken beta kapsamında; bunu bütün SOC işlerini kapsayan hazır bir çözüm gibi bütçelendirmeyin.
Bu hafta neye bakmalı?
- NetScaler envanterinde tam build ve ürün dalını CVE-2026-88779 kaydıyla eşleştirin; önceki bakımın bu açığı kapattığını varsaymayın. Kararı cihaz bazında değişiklik kaydına işleyin.
- Kubernetes node imajlarında cgroup sürümünü doğrulayın. Geçici v1 istisnalarını listeleyip yeniden oluşturulan bir node üzerinde izleme ve limit testini tamamlayın.
- Swap denemesini ayrı worker havuzunda yapın. Şifreleme ve secret volume davranışı doğrulanmadan veya gecikme için geri dönüş eşiği belirlenmeden kapsamı büyütmeyin.
- Codex için ayrı Tailscale etiketi kullanın; izinli ve yasak hedef testlerini aynı görevden çalıştırın. DNS davranışını da sonuçlarıyla kaydedin.
- SOC ajanına eksik kanıt içeren bir test vakası verin. Veri kaynağına ulaşılamadığında alarmı temiz saymamasını ve müdahaleyi analist onayına bırakmasını isteyin.
