Bilmem anlatabiliyor muyum, Güvenlik ekiplerinin ağzından en sık duyduğum cümle şu: “Araç taradı, açık buldu, tamamdır.” Güzel. Kulağa rahatlatıcı geliyor, hatta biraz tatmin edici de. Ama işin aslına bakarsanız, otomatik pentest raporunu okuyup “güvendeyiz” demek, bir binanın dışarıdan fotoğrafını çekip “sağlam yapı” demeye benziyor — içeride hangi kapı kilitlenmiyor, hangi süreç boşluk bırakıyor, hangi koridor başka bir odaya açılıyor (ki bu çoğu kişinin gözünden kaçıyor). orası bambaşka hikâye.
Bence, SecurityWeek’in bugün öne çıkardığı webinar tam bu noktaya basıyor. Mesaj net: Otomasyon önemli, bunu kimse tartışmıyor; ama güvenlik doğrulamasını yalnızca araç seviyesinde bırakırsanız, gözünüzün önündeki büyük boşlukları kaçırırsınız. Ben bunu ilk kez 2019’da İstanbul’da bir fintech projesinde çok net gördüm. Dışarıdan her şey yeşildi, raporlar fena değildi, kimse kaşını çatmıyordu… sonra canlı ortamda basit bir erişim zinciri yüzünden bambaşka bir risk ortaya çıktı. Araçlar görmemişti. Neden önemli bu? Süreç görmüştü.
Bunu biraz açayım.
Asıl Problem Araçta Değil, Bakış Açısında
Otomatik pentest araçları kötü değil. Yanlış anlaşılmasın. Hızlıdırlar, tekrarlanabilirler, küçük ekiplerin elinden tutarlar — bunları küçümsemiyorum. Fakat şunu da söylemek lazım: bu araçları nihai karar mekanizması gibi kullandığınız an işler dağılmaya başlıyor. Çünkü araç belirli kalıpları yakalar, insan ise bağlamı okur. Bağlam yoksa güvenlik de biraz körleşiyor, sanki bir satranç tahtasını figürsüz analiz etmek gibi.
Geçen yıl Ankara’daki bir SaaS ekibiyle yaptığım görüşmede şunu duydum: “Rapor temiz çıktı. Müşteri denetiminde sorular gelince terledik.” İşte bu. Tam da bu cümle meseleyi özetliyor. Denetim masasında kimse senden sadece CVE listesi istemiyor. Kimse “kaç tane alarm bastın?” diye alkış tutmuyor. Beklenen şey farklı: Bu sistem gerçekten nasıl kırılır, nereden sızılır, hangi iki kontrol birbirini deliyor?
Evet, doğru duydunuz.
Bir de şu var ayrıca — araçların ölçtüğü şey teknik bulgu oluyor çoğu zaman, halbuki kurumların kaybettiği şey operasyonel güven olabiliyor. Mesela bir API anahtarı rotasyonu gecikiyorsa (söylemesi ayıp) ya da IAM politikaları birbirine girişmişse, otomasyon bunu parça parça yakalayabilir. Bütün resmi kuramaz. O resim kurulmayınca da “güvenlik test edildi” cümlesi havada kalıyor. Rahatsız edici bir boşluk.
Kapsam ile gerçek risk aynı şey değil
Kapsam listesi geniş olabilir. İlk bakışta iyi haber gibi görünür, haklısınız. Ama kapsamdaki her uygulamanın iş kritikliği aynı değildir — bir ödeme ekranındaki zafiyet ile iç raporlama portalındaki zafiyet, kâğıt üstünde benzer görünse de gerçek dünyada yarattığı etki çok farklıdır. Otomatik test aracı ikisini de işaretleyebilir, ikisine de benzer öncelik verebilir; hangisinin patlama etkisi yaratacağını ise ancak program düzeyi analiz söyler.
Araya gireyim: Kısaca: Kapsam var diye güven yoktur.
Neden Program Seviyesi Doğrulama Daha Değerli?
Program seviyesi doğrulama dediğimiz şey aslında daha olgun bir refleks, daha geniş bir bakış. Tek tek araç çıktısına bakmak yerine; varlık envanterini, tehdit modelini, saldırı yüzeyini. Iş önceliğini birlikte değerlendiriyorsun. Yani mutfakta tek tencereyi değil, bütün menüyü görüyorsun (şaşırtıcı ama gerçek). Fark büyük.
Bu yaklaşım bana 2023’te Dubai’de katıldığım kapalı bir güvenlik çalıştayını hatırlatıyor — evet, biraz sıcaktı ve fazla kahve kokuyordu, neyse. Orada konuşulan şey şuydu: Aynı zafiyet farklı ortamlarda bambaşka sonuç veriyor. Geliştirme ortamında “idare eder” görünen bir açık, üretimde zincirleme yetki yükseltmeye dönüşebiliyor. Peki bunu neden söylüyorum? Araç bunu ayrı ayrı gösterebilir; ama iki nokta arasındaki ilişkiyi kurmak insan işi.
Ve işler burada ilginçleşiyor. Bu konuyla ilgili Dijital Oyunlarda Yeni Vergi Dalgası: Türkiye’de Ne Değişiyor? yazımıza da göz atmanızı tavsiye ederim. TSMC’ye Giden Yol: Apple’ı Sarsan Çip Gölgesi yazımızda bu konuya da değinmiştik.
Otomasyon hız verir; fakat kapsamı anlamadan yapılan otomasyon, bazen sadece hızlıca yanlış sonuca götürür.
Ha, bu arada startup ile enterprise arasındaki fark da tam burada beliriyor. Startup tarafında hedef genelde “en az emekle en çok görünürlük” — anlaşılır, kaynaklar kısıtlı. Kurumsalda ise mesele uyumluluk kadar süreklilik de oluyor; onlarca ekip, farklı bulut hesapları, eski sistemler devreye girince tek aracın sesi yetersiz kalıyor. Gürültüye boğuluyor.
| Yaklaşım | Güçlü Yani | Zayıf Yani |
|---|---|---|
| Otomatik pentest | Hızlı sonuç verir, ölçeklenir | Kapsam dışını ve bağlamı kaçırabilir |
| Elde yapılan pentest | Saldırı zincirini daha iyi kurar | Zaman alır ve pahalı olabilir |
| Program seviyesi doğrulama | Daha gerçekçi risk resmi çıkarır | Daha fazla koordinasyon ister |
Küçük Ekipler Ne Yapmalı?
Bütçe sınırlıysa önce dürüst olmak lazım (yanlış duymadınız). Her şeyi aynı anda çözemezsiniz. Bu normaldir, utanılacak bir şey değil. Önce kilit varlıkları çıkarın — müşteri verisi — itiraz edebilirsiniz tabi — olan sistemler mi? Ödeme akışı mı? Yönetim paneli mi? Sonra otomatik testleri bu alanlara yönlendirin (ben de ilk duyduğumda şaşırmıştım). Geri kalanı sıraya koyun.
Ama şunu da söyleyeyim: Yalnızca aracı koşturup raporu PDF olarak klasöre atmak yetmez. Birisi oturup sonuçları yorumlamalı. Bunu İzmir’de çalışan iki kişilik bir ürün ekibinde gördüm; ekipten biri “rapor temiz” deyip geçiyordu, öbürü ise log korelasyonuna bakınca yetkisiz çağrı örüntüsü yakaladı. Küçük ekiplerde bu tür çapraz okuma gerçekten hayat kurtarıyor. Abartmıyorum.
- Kritik servisleri önceliklendir.
- Taramayı CI/CD’ye göm ama manuel gözden geçirmeyi kaldırma. — bunu es geçmeyin
- Bulguları iş etkisine göre puanla.
- Aynı açığın tekrar çıkmasını engelleyecek kontrol ekle.
- Aylık olmasa bile çeyreklik saldırı senaryosu çalıştır.
Kod bloğu gibi düşününce iş kolaylaşıyor
# Basit bir doğrulama akışı fikri
1) Varlıkları sınıflandır
2) Saldırı yüzeyini çıkar
3) Otomatik taramayı çalıştır
4) Manuel inceleme ile zincir oluştur
5) İş etkisine göre önceliklendir
6) Düzeltme sonrası yeniden test et
7) Raporu yönetim diliyle özetle
Aslında — hayır dur, daha doğrusu, Bu akış kâğıt üstünde sade duruyor, kabul. Pratikte ise ciddi disiplin istiyor. En çok da startup’larda herkes her işi yaptığı için güvenlik bazen “boş vakitte bakılır” kategorisine düşüyor… Kötü fikir. Gerçekten kötü fikir.
Enterprise Tarafında Neden Daha Da Zor?
Büyük kurumlarda sorun teknik olmaktan çıkıp organizasyonel hale geliyor çoğu zaman. Bir takım bulutu yönetiyor, başka takım uygulamayı yazıyor, üçüncü takım uyumluluk peşinde koşuyor (inanın bana). Ortada ortak dil yoksa otomatik pentest sonucu da parçalanıyor, kimsenin elinde tam bir resim kalmıyor.
Yani, Bu haberi editör masasında görünce hemen eski notlarıma baktım — 2022’de Frankfurt merkezli bir perakende grubunda benzer tabloyu izlemiştim, isim vermeyeyim. Araçlar gayet çalışıyordu, teknik sorun yoktu. Ama bulgular sahiplenilmiyordu. Açık bulunuyor, dosyaya giriyor, orada uyuyor. Kimin düzelteceği belli değil. Klasik kurumsal sürtünme, biraz sinir bozucu.
Sahiplik meselesi göz ardı ediliyor
Yani, Bulgunun sahibi yoksa çözüm de yavaşlar. Program seviyesinde yaklaşımda yalnızca teknik test değil süreç tasarımı da şart: Kim onaylıyor? Kim yeniden test ediyor? Hangi SLA geçerli? Bunlar sorulmadan otomasyona yatırım yapmak, araba alıp benzinsiz bırakmaya benziyor.
Bir dakika — bununla bitmedi.
Bir de şunu söyleyeyim, hayal kırıklığı kısmı bu: Bazı kurumlar pahalı araç lisanslarına ciddi para döküyor. Eğitim bütçesini kısıyor. Sonra ekip raporu okuyor, ne yapacağını bilmiyor. O an neredeyse tüm yatırım eksik kalıyor. Para gitti, güvenlik gelmedi.
Dengeli Bir Güvenlik Programı Nasıl Kurulur?
Açık konuşayım: ideal model tek bir araca yaslanmayan modeldir. Otomasyonu giriş kapısı gibi kullanırsın, son kararı ise daha geniş bağlamla verirsin. Amaç aracı küçümsemek değil; tam tersine onu doğru yere koymak. Doğru yere konulan araç çok iş görür, yanlış yere konulan ise seni yanıltır.
Pratik adımlar açısından:
- Taramayı sürekli hale getir: Haftalık ya da release bazlı koşsun.
- Bulguları sınıflandır: Teknik açık ile iş riski arasındaki fark net olsun.
- Zincir analizi yap: Tekil açık yerine birleşik saldırıları düşün.
- Düzeltme sonrası tekrar test et: Kapanan açıklara gerçekten kapanmış muamelesi yap.
- Metrikleri sade tut: Yönetimin anlayacağı dille anlat, yoksa rakam çöplüğüne dönersin.
Peki startup ile enterprise burada nasıl ayrılıyor? Startup daha hızlı hareket eder ama kör nokta riski yüksektir. Enterprise daha fazla kaynak taşır ama koordinasyon maliyeti yüzünden yavaşlayabilir. İkisinin ortak derdi ise aynı: güvenliği kutucuk doldurma faaliyetine çevirmemek. Bu konuyla ilgili Cursor’da “Make No Mistakes” Dönemi Başlıyor: Küçük Ama Kurnaz Bir Hamle yazımıza da göz atmanızı tavsiye ederim. Formlar Ölü Olmalı: React’te Neden Yaşatmayalım? yazımızda da bu konuya değinmiştik. Yapay Zekâ Ajanı Akıllı Değil: Asıl Güç Araçlarda yazımızda da bu konuya değinmiştik.
Dengeyi bozan üç klasik hata
Bence en sık görülen hata şu — birincisi yalnızca scan sonucuna güvenmek. İkincisi can alıcı sistemleri diğerlerinden ayırmamak. Üçüncüsü ise bulguyu kapatma sürecini ölçmemek. Açığı görmek kolay aslında; esas zor olan onu takibe almak, üstüne oturmak, kapandığını doğrulamak.
Sahada Ne Öğretiyor?
Neyse, fazla uzatmayayım. Bu webinar bana şunu hatırlattı: Otomasyon iyi bir başlangıçtır, final cümlesi değil. Araçların ürettiği veri değerli, hatta şart; ama onu yorumlayan insan aklı olmadan o veri kolayca gürültüye dönüşüyor. Ciddi gürültüye.
Asıl ders bence şu: Pentesting’i tek seferlik bir etkinlik gibi görmek yerine, sürekli doğrulanan bir program haline getirmek gerekiyor. Bugün tespit ettiğin boşluk yarın farklı bir zincirde geri gelebilir. Güvenlik biraz su sızıntısı gibidir — bir deliği tıkarsın, başka yerden yol bulur. Bu yüzden sadece aleti değil, sistemi güçlendirmek lazım.
Sıkça Sorulan Sorular
Otomatik pentest neden tek başına yeterli değil?
Çünkü otomatik araçlar çoğunlukla belirli desenleri yakalar ama iş bağlamını tam okuyamaz.Gerçek risk bazen birkaç zayıflığın birleşmesiyle oluşur. Bunu insan analizi daha iyi görür.
Küçük şirketler ne kadar manuel test yapmalı?
Bütçe kısıtlıysa kritik sistemlerde manuel inceleme şart olur.Her şeyi elle yapmak gerekmez,
Pentest raporunda en önemli metrik nedir?
Dürüst olmak gerekirse, Sadece bulunan açık sayısı yeterli değildir.Açıktan ziyade iş etkisi,sömürülebilirlik ve düzeltme süresi birlikte okunmalıdır.
Ekip içinde güvenlik sahipliği nasıl sağlanır?
Bulgulara doğrudan sahip atamak işe yarar: Her açığın sahibi,son tarihi ve yeniden test sorumlusu net olursa süreç çok daha hızlı ilerler.
Kaynaklar ve İleri Okuma
SecurityWeek orijinal haber sayfası
Yani, OWASP Web Security Testing Guide (WSTG)
İşin garibi, NIST Cybersecurity Framework
Tuhaf ama, OWASP Amass GitHub Sayfası
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
