Web Uygulaması Güvenliği İçin Kimden Destek Almalısın?

Önce “Neyi öğrenmek istiyorum?” diye sor

Güvenlik hizmeti seçmek, ihtiyacını tanımlamakla başlar. Uygulamanın kodundaki sorunları mı araştırmak istiyorsun? Kullanıcıların birbirinin verilerine erişip erişemediğini mi kontrol ettireceksin? Yoksa sunucunun yapılandırması konusunda mı desteğe ihtiyacın var?

Hepsini kapsayan bir çalışma isteyebilirsin. Ancak bunların teklifte açıkça belirtilmesi gerekir. “Güvenlik testi yapılacak” cümlesi tek başına hangi alanların inceleneceğini söylemez.

Hangi uzman ne yapar?

Bu rehber kimler için uygun?

• Web sitesi veya uygulaması için güvenlik hizmeti alacak işletmeler.
• Yapay zekâ raporunu uzman incelemesine taşımak isteyen proje sorumluları.
• Yayına çıkmadan veya önemli değişikliklerden sonra değerlendirme planlayan ekipler.

Devam eden bir saldırıdan, hesap ele geçirilmesinden veya veri sızıntısından şüpheleniyorsan rutin inceleme teklifi beklemek uygun olmayabilir. Böyle bir ihtiyaçta siber olay müdahalesi deneyimi olan bir ekip ve ilgili sistem sorumlularıyla iletişime geçmelisin.

Bu yazı acil olay müdahalesi rehberi veya belirli bir mevzuata uyum değerlendirmesi değildir.

Doğru desteği bulmak için ne diye aramalısın?

Arama sonucunda bir hizmet bulmak ilk adımdır. Yetkinliği anlamak için uygulamana benzer projelerdeki deneyimini, çalışma yöntemini ve anonimleştirilmiş örnek raporunu sorabilirsin.

Hizmet almadan önce soracağın sekiz soru

1. Tam olarak hangi alanları inceleyeceksiniz? Site, yönetim paneli, API, kullanıcı rolleri ve bağlantılı sistemlerden hangileri kapsamda? Hangileri kapsam dışında?
2. Nasıl inceleme yapacaksınız? Otomatik tarama, manuel değerlendirme, kaynak kod incelemesi ve iş akışı testlerinden hangileri uygulanacak?
3. Bizden hangi erişimleri isteyeceksiniz? Test hesapları, kaynak kod veya ortam bilgileri gerekiyor mu? Erişimler nasıl sınırlandırılacak?
4. Test hangi ortamda ve hangi koşullarda yapılacak? Test zamanı, izin verilen işlemler, hizmete olası etkiler ve durdurma koşulları nasıl belirlenecek?
5. Rapor nasıl olacak? Kanıt, etki, risk gerekçesi ve uygulanabilir düzeltme önerileri içeren örnek bir rapor görebilir miyiz?
6. Önemli bir sorun bulduğunuzda nasıl haber vereceksiniz? Kritik bulgular için rapor sonunu beklemeden bilgilendirme yapılacak mı? İletişim sorumlusu kim?
7. Düzeltme ve yeniden test kapsamda mı? Kod değişikliğini kim yapacak? Yeniden testin süresi, kapsamı ve ek ücreti var mı?
8. Kod ve verilerimizi nasıl koruyacaksınız? Kimler erişecek, hangi araçlarla işlenecek, nerede saklanacak ve çalışma sonunda ne yapılacak?

Bir teklif daha düşük fiyatlı olduğu için mutlaka daha avantajlı değildir. Diğeri daha kapsamlı inceleme, daha fazla kullanıcı rolü veya yeniden test içeriyor olabilir. Aynı işi karşılaştırdığından emin misin?

Sağlıklı bir çalışma nasıl ilerlemeli?

1. İhtiyaç ve kapsam belirlenir. Uygulamanın amacı, önemli verileri ve kritik işlemleri konuşulur. İncelenecek hedefler netleştirilir.
2. Yetkilendirme ve çalışma koşulları yazılılaştırılır. İzin verilen hedefler, işlemler, zamanlama, iletişim ve veri işleme koşulları belirlenir. Üçüncü taraf sistemler kendiliğinden kapsama girmez.
3. İnceleme ve bulgu değerlendirmesi yapılır. Bulguların gerçekliği ve etkisi araştırılır. Önemli sorunlar kararlaştırılan iletişim yoluyla paylaşılır.
4. Rapor ve düzeltme planı hazırlanır. Yapılacak işlerin sorumluları ve öncelikleri belirlenir. İncelenemeyen alanlar ayrıca gösterilir.
5. Düzeltmeler yeniden kontrol edilir. Sorunların giderilip giderilmediği değerlendirilir. Kalan riskler ve sonraki inceleme ihtiyaçları kaydedilir.

Küçük bir örnek: “Siteyi test etmek” neyi kapsıyor?

Bir uygulamada normal kullanıcı, ekip yöneticisi ve sistem yöneticisi olmak üzere üç rol bulunduğunu düşün. Her rol farklı bilgilere ve işlemlere erişiyor.

Bir teklif yalnızca giriş yapılmadan görülebilen sayfaları inceleyebilir. Başka bir teklif ise üç rolün birbirinin verilerine erişip erişemediğini ve yetkilerinin dışına çıkıp çıkamadığını da değerlendirebilir.

İkisinin adı “web uygulaması güvenlik testi” olsa bile kapsamları aynı değildir. Teklifte test hesaplarını, kullanıcı rollerini ve önemli iş akışlarını belirtmek bu farkı görünür hâle getirir.

Bu, kapsam farkını açıklamak için hazırlanmış temsili bir senaryodur; belirli bir firmaya veya gerçek test sonucuna dayanmaz.

İlk görüşmeye ne hazırlamalısın?

Uzun bir teknik dosya hazırlaman şart değil. Aşağıdaki bilgileri kısa bir özet hâlinde toparlamak görüşmeyi kolaylaştırır:

• Uygulamanın amacı ve kullanıcı rolleri.
• Tutulan hassas veri türleri ve kritik işlemler.
• Bildiğin teknoloji, altyapı ve erişim kısıtları.
• Kaynak koda ve ayrı test ortamına erişim durumu.
• İncelenmesini istediğin alanlar ve hedef tarih.
• Varsa ön inceleme raporu ve bilinen sorunlar.

Yapay zekâ raporunu paylaşırken doğrulanmış sonuç gibi sunma. “Bunlar ön incelemede bildirilen, değerlendirilmesini istediğimiz noktalar” demen yeterlidir.

Ön çalışma hazırlamak istersen yapay zekâ ile güvenlik ön kontrolü komutunu kullanabilirsin. Araçların kullanımı için Cursor, Copilot ve Claude Code rehberine göz atabilirsin.

Dört yaygın yanlış anlama

• “Otomatik tarama yapıldı, sızma testi tamamlandı.” Tarama bazı sorunları gösterebilir. Hizmetin manuel inceleme ve doğrulama kapsamı ayrıca sorulmalıdır.
• “Hosting firması ilgileniyorsa kod da güvendedir.” Sunucu hizmeti ile uygulama kodunun güvenliği farklı sorumluluklardır. Sağlayıcının kapsamını netleştir.
• “Sertifikası varsa her projede yeterlidir.” Sertifikalar değerlendirmeye katkı sağlayabilir. İlgili teknoloji deneyimini ve çalışma kalitesini tek başına garanti etmez.
• “Bir kez test yaptırdım, artık bitti.” İnceleme belirli bir sürüm ve kapsama aittir. Yeni özellikler, değişiklikler ve ortaya çıkan riskler yeniden değerlendirme gerektirebilir.

Sık sorulan beş soru