Düzeltme ve tekrar test

Bir finding'in yaşam döngüsü rapor yayımlandığında bitmez. Asıl risk azaltımı, doğru düzeltmenin güvenli biçimde uygulanması ve beklenen sonucu verdiğinin bağımsız evidence ile gösterilmesiyle gerçekleşir. “Yama kuruldu”, “kural eklendi” veya “geliştirici düzeltti” ifadeleri önemli değişiklik kayıtlarıdır; tek başlarına kapanış kanıtı değildir.

Sağlam bir kapanış süreci üç soruyu birbirinden ayırır: Ne değiştirildi? Değişiklik kök nedeni giderdi mi? Meşru işlevler çalışmaya devam ediyor mu? Bu soruların cevapları remediation planı, retest ve regresyon kontrolünden gelir.

Remediation kök nedene bağlanır

Önce finding'in ne söylediğini yeniden oku. Etkilenen varlık, koşul, güvenlik etkisi ve orijinal evidence net değilse düzeltme ekibi yanlış probleme müdahale edebilir. Örneğin bir yetkilendirme finding'inde yalnızca arayüzde düğmeyi gizlemek, sunucu tarafındaki eksik erişim kontrolünü düzeltmez.

Remediation, kök nedeni ortadan kaldıran kalıcı değişikliktir. Güvenli sürüme güncelleme, sunucu tarafı yetki kontrolü ekleme, gereksiz servisi kaldırma veya yanlış yapılandırmayı düzeltme buna örnektir.

Mitigation, finding mevcutken ihtimali ya da etkiyi azaltır. Ağ erişimini daraltmak, özelliği geçici olarak kapatmak veya ek izleme uygulamak değerli olabilir. Ancak mitigation; sahibi, süresi ve kalıcı çözüm tarihi olmadan görünmez bir borca dönüşür.

Kapanış ilkesi

Değişiklik kaydı evidence değildir

Bir finding, ekip değişiklik yaptığını bildirdiği için değil; aynı güvenlik iddiası kontrollü retest ile artık doğrulanamadığı ve kabul ölçütleri karşılandığı için fixed olur.

Uygulanabilir düzeltme planı

İyi bir plan yalnızca “güncelle” demez. Şu alanları görünür kılar:

• Finding ve varlık kimliği.
• Kök neden ve seçilen remediation.
• Geçici mitigation varsa kapsamı ve sona erme tarihi.
• Teknik sahip, varlık sahibi ve onaylayan taraf.
• Test ortamı, bakım penceresi ve bağımlılıklar.
• Başarı ölçütü, gözlem süresi ve rollback koşulu.
• Retest için hazır olma tarihi.

Değişiklik önce temsilî ve yetkili bir ortamda sınanır. Üretim verisi kopyalamak yerine sentetik test verisi kullanılır; zorunlu örnekler maskelenir. Bakım sırasında beklenmeyen hata oranı, gecikme veya erişim kaybı görülürse rollback planı uygulanır. Güvenlik aciliyeti, kontrolsüz değişikliği haklı çıkarmaz.

Retest nasıl tasarlanır?

Retest yeni bir scanner çalıştırıp yeşil ekran almak değildir. Orijinal finding'in hipotezi ve kabul ölçütleri yeniden ele alınır. Mümkün olduğunda aynı varlık, aynı erişim yolu ve karşılaştırılabilir yöntem kullanılır. Böylece önce ve sonra evidence'ı anlamlı biçimde karşılaştırılır.

Retest paketinde dört kontrol bulunur:

1. Varlık kontrolü: Değişikliğin doğru sisteme ve doğru bileşene uygulandığı doğrulanır.
2. Pozitif işlev kontrolü: Yetkili kullanıcının meşru işlemi hâlâ yapabildiği gösterilir.
3. Negatif güvenlik kontrolü: Yetkisiz veya hatalı isteğin güvenli biçimde reddedildiği gözlenir.
4. Regresyon kontrolü: Yakındaki işlevlerin, günlüklemenin ve hata yönetiminin bozulmadığı kontrol edilir.

Örneğin laboratuvar uygulamasında bir kullanıcının başka ekibin kaydını okuyabildiği finding düşün. Remediation, her istek için sunucu tarafında nesne sahipliğini kontrol etsin. Retest yalnızca eski örnek kaydın artık açılmadığını göstermez. Kullanıcının kendi kaydını okuyabildiğini, farklı bir yetkisiz kaydın reddedildiğini, doğrudan API isteğinin de aynı kontrole takıldığını ve hassas ayrıntının hata mesajında sızmadığını doğrular.

Evidence içine gerçek kullanıcı adı, oturum belirteci veya müşteri verisi konmaz. Sentetik hesaplar ve kayıtlar kullanılır; istek ile yanıt kesitleri gerekli alanlarla sınırlanır. UTC zaman, uygulama sürümü, değişiklik kimliği ve test eden kişi/rol kaydedilir.

Retest başarısız olduğunda

Başarısız retest bir suçlama değil, remediation tasarımının hangi varsayımda eksik kaldığını gösteren geri bildirimdir. Önce değişikliğin gerçekten hedef varlığa ulaşıp ulaşmadığı, önbellek veya dağıtım gecikmesi bulunup bulunmadığı ve kullanılan test hesabının doğru role sahip olduğu kontrol edilir. Ardından failure evidence'ı maskelenerek değişiklik sahibiyle paylaşılır. Testi sınırsız biçimde tekrarlamak yerine yeni bir deneme zamanı, sorumlu ve kabul ölçütü belirlenir.

Kısmi başarıda kalan yüzeyi açıkça adlandır. Örneğin web arayüzü artık güvenliyken aynı işlem eski API yolundan yapılabiliyorsa finding kapanmaz; “partially fixed” kalır. Geçici bir kontrol uygulanacaksa kontrolün sahibi, izleme yöntemi ve sona erme tarihi kayda eklenir. Üretim sisteminde plansız ek deneme yapılmaz; yeniden doğrulama yalnız yetkili değişiklik penceresinde veya aynı koşulları temsil eden ayrılmış laboratuvarda yürütülür. Böylece hız baskısı, evidence zincirini ya da hizmet güvenliğini bozmaz.

Kapanış durumları

Retest sonunda üç teknik sonuçtan biri seçilebilir:

• Fixed: Kabul ölçütlerinin tamamı karşılandı; orijinal koşul güvenli yöntemle yeniden üretilemiyor ve regresyon kontrolü geçti.
• Partially fixed: Riskin bir bölümü azaldı, ancak başka varlık, yol veya koşul finding'i sürdürüyor.
• Not fixed: Orijinal koşul hâlâ doğrulanıyor veya değişiklik doğru varlığa uygulanmamış.

Risk accepted teknik bir retest sonucu değildir. Yetkili risk sahibinin, süreli ve gerekçeli iş kararıdır. Finding'in durumu bu nedenle “fixed” olarak değiştirilmez. Benzer biçimde “cannot retest” belirsizliği gizlememelidir; erişim veya ortam sorunu varsa kayıt inconclusive kalır ve sonraki adım yazılır.

Evidence zincirini kapatmak

Kapanış kaydı orijinal finding kimliğine bağlanır. Değişiklik talebi, uygulanan sürüm veya yapılandırma, önce/sonra evidence dosyaları ve retest kararı aynı zincirde bulunur. Evidence dosyalarının bütünlük özeti ve erişim kısıtı korunur; hassas ekler genel rapordan ayrılır.

Bu yaklaşım iki tarafı da korur. Düzeltme ekibi neyin kabul edileceğini önceden bilir; güvenlik ekibi ise “bize düzeltildi dendi” yerine denetlenebilir bir karar üretir. Profesyonel kapanış, finding sayısını azaltmak değil riskin gerçekten azaldığını kanıtlamaktır.