Web Sitenizde Sürekli Güvenlik Taraması Nasıl Yapılır

Haritalamadığınız şeyi tarayamazsınız. Sahip olduğunuz veya işlettiğiniz her web varlığının eksiksiz bir envanterini oluşturarak başlayın. Unutulan bir alt alan adı veya staging ortamını bile gözden kaçırmak, saldırganlar için açık bir kapı bırakabilir.

• Kuruluşunuzla ilişkili her alan adını ve alt alan adını listeleyin (ör. www, api, staging, admin, dev).
• Tüm genel IP adreslerini ve ilişkili hizmetlerini kataloglayın.
• Güvenliğinden sorumlu olduğunuz üçüncü taraf web varlıklarını (iş ortağı portalları, white-label ürünler) belirleyin.
• Üretim dışı ortamları dahil edin — staging ve geliştirme sunucuları sıkça hedef alınır.
• Genel erişime açık tüm API'leri (REST, GraphQL, SOAP) belgeleyin.
• Yeni bir varlık devreye alındığında veya hizmet dışı bırakıldığında bu envanteri güncelleyin.

Tarama sıklığı, uygulamanızın değişim hızıyla ve işlediği verilerin hassasiyetiyle uyumlu olmalıdır. Statik bir tanıtım sitesiyle ödeme platformunun gereksinimleri birbirinden çok farklıdır. Daha sık tarama daha hızlı tespit anlamına gelir; ancak bulgular hacmini yönetebilecek bir ekibe de ihtiyacınız vardır.

• Yüksek riskli uygulamalar (e-ticaret, sağlık, finans): en az günlük, tercihen her dağıtımda tarayın.
• Orta riskli uygulamalar (kimlik doğrulamalı portallar, SaaS ürünleri): en az haftalık ve her sürümde tetiklenecek şekilde tarayın.
• Düşük riskli genel siteler: en az aylık ve önemli içerik ya da altyapı değişikliklerinin ardından tarayın.
• Büyük bağımlılık güncellemeleri, CMS güncellemeleri veya altyapı değişikliklerinin ardından her zaman ek bir tarama başlatın.
• Uygulamanız ek yüke duyarlıysa taramaları düşük trafikli zaman dilimlerine zamanlayın.

İlk yapılandırmayı doğru yapmak, sonradan gürültülü ve hatalı sonuçlarla uğraşmanızı önler. İyi yapılandırılmış bir tarama doğru kapsamı hedefler, uygun kimlik doğrulaması kullanır ve teknoloji yığınınızla en alakalı güvenlik açığı kategorilerini kapsar. Sensagraph, alan adınızı eklediğinizde tam saldırı yüzeyinizi otomatik olarak keşfeder ve tarar.

• Birincil alan adınızı ekleyin ve alt alan adlarının kapsama dahil edildiğini onaylayın.
• Tarayıcının korumalı sayfalara ve uç noktalara ulaşabilmesi için kimlik doğrulama bilgilerini (çerezler, API token'ları) sağlayın.
• Aktif taramadan gürültü yaratan bilinen güvenli yolları hariç tutun (ör. oturum kapatma URL'leri, dosya yükleme stres uç noktaları).
• Temel olarak OWASP İlk 10 için kontrolleri etkinleştirin: enjeksiyon açıkları, bozuk kimlik doğrulama, hassas veri ifşası, güvenlik yanlış yapılandırmaları ve daha fazlası.
• TLS/SSL yapılandırma kontrollerinin tarama profiline dahil edildiğini onaylayın.
• HTTP güvenlik başlıklarının (CSP, HSTS, X-Frame-Options vb.) kontrol listesinde yer aldığını doğrulayın.
• Hemen bir temel tarama başlatın ve yinelenen taramaları zamanlamadan önce ilk bulguları inceleyin.

Yüzlerce bulgu üretip bağlam sunmayan bir tarama neredeyse işe yaramaz. Etkili sınıflandırma; gerçek ve istismar edilebilir güvenlik açıklarını bilgilendirici notlardan ayırt etmek ve yalnızca CVSS puanlarına değil, gerçek iş riskine dayalı olarak en tehlikeli sorunları önce düzeltmek anlamına gelir.

• Önem derecelendirmelerini (Kritik, Yüksek, Orta, Düşük, Bilgilendirici) başlangıç noktası olarak kullanın, son söz olarak değil.
• Kişisel veri, kimlik doğrulama veya ödeme işleyen varlıklardaki güvenlik açıklarının önceliğini artırın.
• Bir güvenlik açığının genel internetten mi yoksa yalnızca dahili ağdan mı istismar edilebileceğini kontrol edin.
• Onaylanan yanlış pozitifleri işaretleyin ve gerekçenizi belgeleyin; böylece aynı sorun bir sonraki döngüde yeniden sınıflandırılmaz.
• Sahiplik atayın: Her bulgunun düzeltmeden sorumlu, adı belirli bir kişisi veya ekibi olmalıdır.
• Gerçekçi SLA hedefleri belirleyin — örneğin, Kritik için 24 saat, Yüksek için 7 gün, Orta için 30 gün.

Bir güvenlik açığı geliştirme yaşam döngüsünde ne kadar erken yakalanırsa düzeltmesi o kadar ucuz ve hızlı olur. Güvenlik taramalarını CI/CD hattınıza gömerek, yeni kodun üretime ulaşmadan önce sorunlar açısından kontrol edilmesini sağlarsınız.

• Her pull request veya ana dala yapılan birleştirmede hafif bir tarama (yeni veya değiştirilen uç noktalara odaklanan) başlatın.
• Staging veya ön üretim ortamına yapılan her dağıtımda otomatik olarak tam tarama başlatın.
• Derlemeyi başarısız kılacak bir bulgu eşiği tanımlayın — örneğin, Kritik veya Yüksek önemde bir sorun tespit edilirse dağıtımı engelleyin.
• CI/CD araçlarınızdan (GitHub Actions, GitLab CI, Jenkins vb.) tarama başlatmak için tarama platformunuzun API veya webhook desteğini kullanın.
• Geliştiricilerin bağlam içinde görebilmesi için tarama sonuçlarını pipeline artefakt olarak yayınlayın veya doğrudan sorun takip sisteminize gönderin.
• Uyarı yorgunluğundan kaçınmak için düşük önemli bilgilendirici bulguları derleme kapılarından hariç tutun.

Sabah 2'de keşfedilen bir güvenlik açığı yalnızca birisi hızlıca uyarılırsa işe yarar. Bildirimleri, yeni bir kritik sorun tespit edildiği anda doğru kişilere ulaşacak — ancak herkesi düşük öncelikli gürültüye boğmayacak — şekilde yapılandırın.

• Kritik ve Yüksek önemli uyarıları hemen nöbetçi kanalınıza yönlendirin (Slack, PagerDuty, e-posta veya SMS).
• Orta ve Düşük önemli bulguları gerçek zamanlı uyarılar yerine günlük veya haftalık özete gönderin.
• Hesap verebilirliğin net olması için yalnızca genel bir güvenlik gelen kutusuna değil, doğrudan varlık sahibine bildirin.
• Yükseltme kuralları belirleyin: Kritik bir bulgu tanımlanan süre içinde onaylanmazsa bir üst yönetim kademesini uyarın.
• Bulguları mevcut ITSM veya bilet sisteminize (Jira, ServiceNow, Linear) otomatik olarak iletmek için webhook kullanın.
• Uyarı hattınızın uçtan uca doğru çalıştığını onaylamak için en az üç ayda bir test edin.

Güvenlik açıklarını keşfetmek işin yalnızca yarısıdır. Her bulguyu ilk tespitinden doğrulanmış kapanışına kadar izleyecek bir sisteme ihtiyacınız var; aksi takdirde sorunlar kaybolur, tekrarlanır veya sessiz sedasız görmezden gelinir.

• Tanımlı önem eşiğinizin üzerindeki her bulgu için bir bilet oluşturun — yalnızca tarama raporlarına güvenmeyin.
• Devir teslimler sırasında bağlamın kaybolmaması için biletleri belirli tarama bulgusuna bağlayın.
• Bir düzeltme dağıtıldıktan hemen sonra güvenlik açığının kapatıldığını doğrulamak için etkilenen uç noktayı veya varlığı yeniden tarayın.
• Önem düzeyine göre ortalama düzeltme süresini (MTTR) takip edin ve aylık olarak paydaşlara raporlayın.
• Kabul edilen risklerin kaydını tutun — düzeltmeyi bilinçli olarak ertelediğiniz güvenlik açıklarını, belgelenmiş gerekçe ve inceleme tarihiyle birlikte kaydedin.
• Geciken bulguları haftalık güvenlik standupında veya backlog gözden geçirme toplantısında ele alın.

Uygulamanız gelişiyor — tarama yapılandırmanız da onunla birlikte gelişmelidir. Üç ayda bir yapılan bir inceleme, sonuçların doğru kalmasını sağlar, yanlış pozitifleri azaltır ve uygulamanızın yeni bölümlerinin atlanmamasını güvence altına alır.

• Her çeyrekte varlık envanterinizi denetleyin; altyapınız değiştikçe hedefleri ekleyin veya kaldırın.
• Yanlış pozitif listesini gözden geçirin ve dışlamaları mevcut uygulama davranışını yansıtacak şekilde güncelleyin.
• Uygulamanın yeni korumalı alanları oluşturulduysa yeni kimlik doğrulanmış kullanıcı rolleri veya oturum token'ları ekleyin.
• Tarama kimlik bilgilerinin (API anahtarları, oturum çerezleri) süresi dolmadığını ve hâlâ geçerli olduğunu kontrol edin.
• Uyarı eşiklerinizi gözden geçirin — ekip uyarı yorgunluğu yaşıyorsa veya gerçek sorunları kaçırıyorsa önem kapılarını ayarlayın.
• MTTR trendinizi zaman içinde kıyaslayın ve bir sonraki çeyrek için iyileştirme hedefleri belirleyin.
• Teknik liderlikle üç ayda bir güvenlik durumu özeti paylaşın; toplam bulgu sayısı, çözüm oranları ve trend verileri dahil olsun.