Bir scanner size olası zafiyetleri gösterebilir. Sızma testi ise hangisinin gerçekten kullanılabildiğini, başka bir zafiyetle birleştiğinde nereye kadar ilerlediğini ve iş açısından neden önemli olduğunu ortaya çıkarır. Web uygulaması, API, mobil uygulama, iç ağ ve dış ağ kapsamlarında manuel test ağırlıklı çalışır; bulguları yalnızca skorla değil, exploitability, erişilebilen veri, etkilenen rol ve remediation önceliğiyle birlikte raporlarız.
Hızlı İletişim
Talebinizi iş günü içinde inceler, ihtiyacınızı netleştirecek kapsam görüşmesini ekibimizle birlikte planlarız.
Sızma testi, yetkili bir saldırganın belirli bir kapsam içindeki sistemlere hangi yollarla erişebileceğini kontrollü olarak değerlendiren güvenlik çalışmasıdır. Amaç, her teorik zafiyeti sıralamak değil, mevcut kontrollerin gerçek saldırı koşullarında ne ölçüde çalıştığını test etmektir.
İyi planlanmış bir çalışma üç soruya cevap verir: Hangi zafiyet gerçekten exploit edilebilir? Başarılı exploitation hangi veri, işlem veya sisteme etki eder? Riski azaltmak için önce hangi remediation yapılmalıdır?
Bu nedenle sızma testi yalnızca otomatik tarama değildir. Authentication ve authorization akışlarını, kullanıcı rolleri arasındaki sınırları, business logic davranışlarını, session yönetimini ve birden fazla zafiyetin oluşturduğu attack chain'i manuel olarak incelemek gerekir.
Web, API, mobil, iç ağ, dış ağ, cloud ve source-assisted kapsamlarını ayrı ayrı planlıyoruz. Kapsamlandırma görüşmesinde varlık envanteri, erişim modeli ve kritik akışlara göre çalışma planını birlikte netleştiriyoruz.
Authentication, authorization, session, input validation, dosya yükleme ve business logic gerçek davranış üzerinden test edilir. IDOR, SQL Injection, XSS, SSRF ve access control gibi riskler OWASP WSTG temelli incelenir; sadece Top 10 kontrol edilip bırakılmaz.
Endpoint envanteri, object-level ve function-level authorization, token kullanımı, rate limiting, mass assignment ve sensitive business flow riskleri değerlendirilir. Farklı kullanıcı ve tenant rolleri BOLA testlerinin doğruluğunu ciddi ölçüde artırır.
Android ve iOS'ta local storage, cryptography, network communication, WebView, deep link, IPC ve reverse engineering dayanımı incelenir. Client tarafının güvenli olması backend authorization'ın da güvenli olduğu anlamına gelmez.
İnternete açık IP, host, VPN, remote access, mail ve DNS servisleri yetkili kapsamda değerlendirilir. Amaç port ve CVE listesi üretmek değil, gerçekten kullanılabilir ilk erişim yollarını doğrulamaktır.
Kurum içine erişmiş saldırgan veya ele geçirilmiş kullanıcı senaryosu temel alınır. Active Directory, network segmentation, service account, credential exposure, privilege escalation ve lateral movement güvenli sınırlar içinde test edilir.
Kaynak kod, mimari doküman veya implementation ayrıntıları test derinliğini artırabilir. Bu model bir Kaynak Kod Analizi projesiyle aynı değildir; kod, çalışan uygulamadaki attack path'i daha doğru test etmek için destekleyici girdidir.
IAM ilişkileri, public exposure, storage permission, security group, secret kullanımı ve cloud-native servis yapılandırmaları kontrollü olarak test edilir. Cloud provider kuralları ve müşteri onayı başlamadan önce doğrulanır.
Doğru yaklaşım "hangisi daha iyi" sorusundan çok "hangi riski ölçmek istiyoruz" sorusuna bağlıdır. Kapsamlandırmada erişim modelini, varlık sayısını ve kritik akışları birlikte belirliyoruz.
Test ekibine en az bilgi verilir; external attacker perspektifini gösterir. Keşif için daha fazla süre gerekir ve sınırlı proje süresinde bazı iç akışlar görünmeyebilir.
Kullanıcı hesapları, rol bilgileri, API dokümantasyonu veya sınırlı mimari bilgi sağlanır. Çoğu web ve API projesinde süre ile test derinliği arasında dengeli sonuç verir.
Kaynak kod, mimari ve test hesapları paylaşılır. Karmaşık authorization ve business logic akışlarında daha yüksek coverage sağlar; senaryo gerçek saldırgan perspektifini koruyacak şekilde tasarlanır.
Referans çerçeveler test kapsamını yapılandırmaya yardımcı olur. Her projede tüm maddelerin uygulanacağı ya da herhangi bir çerçeve için sertifikasyon sağlanacağı anlamına gelmez; kapsam, sistemin gerçek risklerine göre şekillenir.
Çalıştığımız Standartlar
Yönetici özeti: risk görünümü, kritik attack path'ler ve remediation sırası, teknik olmayan karar vericinin anlayacağı netlikte
Teknik bulgu detayları: etkilenen varlık, ön koşul, tekrar üretim adımları, kontrollü kanıt, olası etki ve teknik remediation
Risk önceliği: CVSS tek başına değil; internetten erişilebilirlik, gereken yetki, erişilen veri ve business criticality birlikte
Kapsam ve sınırlamalar: test edilen varlıklar, erişim modeli, tarihler, hariç tutulan alanlar ve coverage'ı etkileyen kısıtlar
Re-test sonucu: yeniden değerlendirilen bulgular closed, partially remediated veya open statüsüyle; yeni risk doğuran remediation ayrıca belirtilir
Domain, IP, uygulama, API, rol, ortam ve test dışı varlıklar yazılı belirlenir. Test penceresi, iletişim kanalı, rate limit, veri işleme kuralları, stop condition ve acil durum kişileri netleştirilir.
Uygulama akışları, trust boundary noktaları, kritik işlemler ve kullanıcı rolleri çıkarılır. Otomatik keşif destekleyici olarak kullanılır; test planı yalnızca genel checklist'e bırakılmaz.
Authentication, authorization, session, input, business logic ve platforma özgü kontroller manuel değerlendirilir. Potansiyel bulgular kontrollü yöntemlerle doğrulanır.
Tekil bulguların birlikte kullanılması hâlinde oluşabilecek etki değerlendirilir. Düşük görünen bir bilgi ifşası, bir authorization açığının yolunu açıyorsa raporda ilişki açıkça gösterilir.
Bulgular teknik kanıt, etki, ön koşul, risk bağlamı ve remediation önerisiyle hazırlanır. Kritik sonuçlar ikinci bir teknik gözden geçirmeden geçirilir.
Sözleşmedeki kapsama göre düzeltilen bulgular yeniden değerlendirilir. Yalnızca ilgili endpoint'in değişmesi değil, attack path'in gerçekten kapandığı kontrol edilir.
Yeni web uygulaması, mobil uygulama veya API production öncesindeyse
Authentication, ödeme, dosya işleme veya yetkilendirme akışları değiştiyse
Cloud, network veya identity mimarisinde önemli değişiklik yapıldıysa
Yeni bir üçüncü taraf integration devreye alındıysa
Kritik bir güvenlik olayı yaşandıysa ve benzer attack path'ler doğrulanacaksa
Önceki testten bu yana uygulama anlamlı ölçüde değiştiyse
Müşteri, tedarikçi veya denetim süreci teknik güvence kanıtı istiyorsa
Bu sınırları açıkça söylemek hizmeti küçültmez; raporun hangi kararda kullanılabileceğini netleştirir.
Süre; varlık sayısı, kullanıcı rolü, API endpoint sayısı, erişim modeli ve test ortamına göre belirlenir. Tek bir süre vermek teknik olarak doğru değildir. Kapsamlandırma sonrasında efor ve takvim netleştirilir.
Uygun Rules of Engagement, yazılı onay ve risk sınırlarıyla bazı testler production üzerinde yürütülebilir. Hizmet kesintisi veya veri bütünlüğü riski taşıyan yöntemler ayrıca onaylanır ya da güvenli test ortamına alınır.
Evet. Keşif, coverage ve tekrar eden kontroller için otomasyondan yararlanırız. Nihai bulgular manuel doğrulanır; scanner sonucu tek başına rapora bulgu olarak eklenmez.
Tekrar üretim için gerekli teknik kanıt sağlanır. Kanıtın biçimi, production güvenliği ve hassas veri koruması gözetilerek seçilir. Gereksiz veri erişimi veya yıkıcı exploitation yapılmaz.
Zafiyet taraması bilinen sorunları geniş varlık setinde düzenli arar. Sızma testi manuel test, attack chain ve business impact doğrulamasıyla belirli kapsam içinde daha derin inceleme yapar.
Her projede gerekli değildir. Gray box ve white box yaklaşımında kod veya mimari erişimi, özellikle karmaşık authorization akışlarında test derinliğini artırabilir.
Testin tamamlandığını gösteren bir proje dokümanı sunulabilir. Bu belge sistemin tamamen güvenli olduğu veya belirli bir standarda bütünüyle uyduğu anlamına gelmez.
İhtiyacınız tek bir uygulamanın testinden kurum genelinde bir Red Team çalışmasına kadar uzanabilir. Ekibimiz scope’u, kritik varlıkları ve beklenen çıktıları sizinle netleştirir. Ardından iş hedefinize ve risk önceliklerinize uygun, sınırları belirlenmiş bir çalışma planı sunar.
