GitHub Code Scanning’de “Mitigated” Dönemi: Güvenlik Bulgularını Doğru Kapatma Rehberi
GitHub’ın yeni “Mitigated” kapatma nedeni, kodda kalan ancak WAF veya ağ politikasıyla kontrol edilen riskleri görünür kılıyor. Ekipler için uygulama ve denetim rehberi.
GitHub, code scanning uyarıları için Mitigated adlı yeni bir kapatma nedeni sundu. Bu seçenek, güvenlik açığı kodda bulunmaya devam ederken web uygulama güvenlik duvarı, ağ politikası veya başka bir dış kontrol nedeniyle pratik riskin azaltıldığı durumları kaydetmek için tasarlandı.
Değişiklik küçük bir arayüz güncellemesi gibi görünse de uygulama güvenliği yönetişimi açısından önemlidir. Ekipler artık “düzeltmeyeceğiz” kararı ile “risk başka bir kontrolle geçici ya da kalıcı olarak azaltıldı” kararını aynı sepete koymak zorunda değildir.
Yeni “Mitigated” nedeni neyi değiştiriyor?
Daha önce ekipler telafi edici bir kontrol uyguladığında uyarıyı çoğu zaman “Won’t fix” benzeri bir nedenle kapatıyor ve ayrıntıları ayrı bir kayıt sisteminde tutuyordu. Yeni neden, kararın niteliğini doğrudan code scanning uyarısının yaşam döngüsüne ekliyor.
GitHub’ın resmî duyurusuna göre bu seçenek özellikle WAF kuralı veya ağ politikası gibi kod dışındaki kontrollerle riski azaltılan bulgular için kullanılabilir. Uyarı kapatılmış olsa bile açığın kaynak kodda bulunduğu gerçeği değişmez; bu nedenle kayıt, düzeltmenin yerine geçen teknik kanıt olarak görülmemelidir.
“Mitigated” ile “Won’t fix” arasındaki fark
Mitigated, bulgunun geçerli olduğunu ve riskin tanımlı bir kontrolle azaltıldığını ifade eder. “Won’t fix” ise genellikle düzeltmeme kararını anlatır; telafi edici kontrolün varlığını tek başına kanıtlamaz.
Bu ayrım, güvenlik borcunun ölçülmesini kolaylaştırır. Yönetim raporlarında gerçekten kabul edilen riskler, yanlış pozitifler ve dış kontrollerle bastırılan riskler ayrı izlenebilir.
Bir bulgu ne zaman bu nedenle kapatılmalı?
Karar verilmeden önce uyarının veri akışı, saldırı önkoşulları ve etkisi incelenmelidir. Kontrolün yalnızca belirli bir ortamda mı çalıştığı, saldırganın kontrolü aşabileceği alternatif bir yol bulunup bulunmadığı ve kontrol devre dışı kalırsa ne olacağı değerlendirilmelidir.
- Bulgunun gerçek ve yeniden üretilebilir olduğu doğrulanmalı.
- Telafi edici kontrolün sahibi ve kapsamı belgelenmeli.
- Kontrolün etkinliği test veya günlük kanıtıyla gösterilmeli.
- Yeniden değerlendirme tarihi ve kalıcı düzeltme planı yazılmalı.
- Kapatma yorumu, kararın gerekçesini ve ilgili kayıt numarasını içermeli.
Kapatma yorumunda hangi bilgiler bulunmalı?
GitHub belgeleri, kapatma sırasında isteğe bağlı bir yorum eklenebildiğini ve bu yorumun uyarı zaman çizelgesinde tutulduğunu belirtiyor. Yorum; kontrol adı, kapsam, test tarihi, sorumlu ekip, istisna kaydı ve gözden geçirme tarihini içerecek kadar açıklayıcı olmalıdır.
“WAF engelliyor” gibi tek cümlelik bir açıklama denetim için yetersiz kalır. Örneğin hangi kuralın hangi ortamda devrede olduğu ve kuralın atlatılamadığının nasıl sınandığı açıkça belirtilmelidir.
Toplu kapatma neden dikkat ister?
GitHub, aynı nedenle birden fazla uyarının topluca kapatılmasına izin verir. Bu kolaylık, yalnızca gerçekten aynı veri akışına ve aynı telafi edici kontrole bağlı bulgular filtrelendiğinde kullanılmalıdır.
Farklı servislerdeki uyarıları tek seferde “Mitigated” olarak kapatmak yanlış güven hissi oluşturabilir. Her depo, dağıtım ortamı ve dışa açıklık düzeyi için kontrol kapsamının ayrıca doğrulanması gerekir.
Yönetişim için uygulanabilir iş akışı
En sağlıklı model, geliştirici incelemesi ile güvenlik onayını birbirinden ayırmaktır. Yazma yetkisine sahip kullanıcıların kapatma isteği oluşturduğu, güvenlik yöneticisinin ise kanıtı inceleyerek kararı onayladığı yetkilendirilmiş kapatma süreci daha güçlü bir denetim izi sağlar.
- Uyarıyı teknik olarak doğrulayın.
- Telafi edici kontrolü test edin ve kanıtı kaydedin.
- Risk sahibi ile sona erme veya gözden geçirme tarihi belirleyin.
- Uyarıyı açıklayıcı yorumla “Mitigated” olarak kapatın.
- Kontrol değişikliklerini ve kapatılan uyarıları periyodik olarak yeniden tarayın.
Takip edilmesi gereken temel ölçümler
Ekipler yalnızca açık uyarı sayısını değil, “Mitigated” durumunda bekleyen bulguların yaşını ve kontrol türünü de izlemelidir. Uzun süre kodda kalan yüksek önem dereceli bulgular, dış kontrol çalışsa bile kalıcı düzeltme için önceliklendirilmelidir.
En önemli ilke şudur: kapatma nedeni bir güvenlik kontrolü değildir; yalnızca alınan kararın doğru sınıflandırılmasıdır. Gerçek koruma, ölçülebilir ve düzenli test edilen telafi edici kontrolden gelir.