Güvenlik ekipleri boğuluyor. Modern bir tarayıcı, orta ölçekli bir altyapıda tek bir taramada binlerce uyarı üretebilir. Bu uyarıların büyük çoğunluğu yanlış pozitif: gerçekte sömürülemeyen, hiçbir saldırgan tarafından kullanılamayacak, ancak yine de bir analistin saatlerini yiyen "kırmızı" satırlar. Sonuç tanıdık: rapor açılır, ilk on bulgu incelenir, beşi asılsız çıkar, ekibin güveni sarsılır ve geri kalanı "sonra bakarız" listesine düşer. Tam da o "sonra" listesinde, binlerce gürültünün arasında gizlenmiş gerçek bir uzaktan kod çalıştırma açığı kaybolur.

Bu, bir araç problemi değil, bir kanıt problemidir. Çoğu tarayıcı işaretler, ama ispatlamaz. Bir versiyon başlığı görür ve "bu sürümde CVE var" der, ancak o açığın sizin yapılandırmanızda gerçekten tetiklenip tetiklenmediğini denemez. İşaretlemek ucuzdur, kanıtlamak pahalıdır. İşte bu pahalı işi otomatikleştiren motora ihtiyaç vardır. DSET'in egemen yapay zeka güvenlik motoru KAOS, tam olarak bu boşluğu kapatmak için tasarlandı: işaretleyen değil, ispatlayan bir sistem.

Bu yazıda doğrulanmış zafiyetin ne anlama geldiğini, yanlış pozitifin gerçek maliyetini, canary çıpalı doğrulamanın nasıl çalıştığını, PoC destekli bir bulgunun bir sızma testi raporunda nasıl göründüğünü, önceliklendirmenin neden yalnızca CVSS'ye değil kanıtlanmış sömürülebilirliğe dayanması gerektiğini ve güvenli otomatik çözüm döngüsünün nasıl işlediğini anlatacağız.

Hızlı Cevap

Doğrulanmış zafiyet, bir tarayıcının "olabilir" dediği değil, motorun kendi yazdığı bir exploit ile gerçek etkisini ispatladığı güvenlik açığıdır. KAOS her bulguyu kontrollü bir kum havuzunda, benzersiz bir canary token çıpasıyla test eder: token'ı yerleştirir, geri okur ve yalnızca etki gerçekten kanıtlandığında bulguyu raporlar. Böylece rapor yanlış pozitiften arınır, her satırın yanında çalıştırılabilir bir PoC ve somut bir çözüm önerisi bulunur ve önceliklendirme teorik puana değil kanıtlanmış sömürülebilirliğe göre yapılır.

Yanlış Pozitifin Gerçek Maliyeti

Yanlış pozitif sadece can sıkıcı bir ayrıntı değildir, ölçülebilir bir kayıptır. İlk maliyet kalemi analist zamanıdır. Bir güvenlik mühendisinin tek bir uyarıyı manuel doğrulaması, ortamı kurması, isteği yeniden üretmesi ve sonucu yorumlaması dakikalar değil çoğu zaman yarım saati bulur. Tarama başına yüzlerce asılsız uyarı, haftalık iş yükünün tamamını yutar. Bu zaman, gerçek bir zafiyetin kapatılmasına ayrılabilecek zamandır.

İkinci ve daha sinsi maliyet uyarı yorgunluğudur. İnsan beyni tekrar eden asılsız alarmlara karşı duyarsızlaşır. Bir ekip art arda on yanlış pozitif gördüğünde, on birinciye de aynı şüpheyle yaklaşır. Sorun şu ki o on birinci bulgu gerçek olabilir. Endüstrideki en ciddi ihlallerin birçoğu, aslında bir tarayıcının çoktan işaretlediği ama gürültü içinde gözden kaçan bir açıktan kaynaklanır. Yanlış pozitif, gerçek pozitifi öldürür.

Üçüncü maliyet güven erozyonudur. Bir rapor sürekli asılsız bulgu üretirse, yönetim ve geliştirme ekipleri o raporu ciddiye almayı bırakır. Güvenlik ekibinin "kurt geldi" diye bağıran çoban konumuna düşmesi, kurumsal güvenlik kültürüne verilebilecek en büyük zarardır. Geliştiriciler her uyarıyı tartışmaya açtığında, güvenlik ekibinin önerileri itibarını yitirir ve düzeltme süreçleri tıkanır. Doğrulanmış zafiyet yaklaşımı bu üç maliyeti birden ortadan kaldırır: rapora giren her satır zaten ispatlanmıştır, dolayısıyla manuel doğrulama, yorgunluk ve güven kaybı denkleminden çıkar.

Bu maliyetlerin görünmez bir dördüncü boyutu daha vardır: fırsat maliyeti. Yanlış pozitiflerle boğuşan bir ekip, proaktif tehdit modelleme, mimari gözden geçirme veya güvenli kod eğitimleri gibi gerçekten değer üreten işlere zaman ayıramaz. Tüm enerji, makinenin ürettiği gürültüyü temizlemeye gider. Doğrulanmış zafiyet yaklaşımı, gürültü temizleme işini motora devrederek insan uzmanlığını yüksek değerli işlere geri kazandırır. Bu, güvenlik bütçesinin daha akıllıca harcanması demektir.

İşaretleyen Tarayıcı ile İspatlayan Motor Arasındaki Fark

Geleneksel bir tarayıcı imza eşleştirmesi yapar. Bir banner okur, bir yanıt başlığını tanır, bir sürüm numarasını bir CVE veritabanıyla karşılaştırır ve eşleşme bulduğunda uyarı üretir. Bu yaklaşım hızlıdır ama körlemesinedir. Çünkü bir sürümün açık içermesi, o açığın sizin yapılandırmanızda sömürülebilir olduğu anlamına gelmez. Belki ilgili modül devre dışıdır, belki bir WAF önde durmaktadır, belki kod yolu hiç ulaşılabilir değildir. Tarayıcı bunların hiçbirini bilmez, çünkü hiçbirini denemez.

KAOS farklı bir felsefeyle çalışır: üret, doğrula, öğren. KAOS bir aday açık tespit ettiğinde kendi exploit'ini yazar, onu hedefe karşı kontrollü biçimde çalıştırır ve gerçek bir etki üretip üretmediğini gözlemler. Bu, güvenlik açığı kanıtı kavramının (proof of exploitation) operasyonel hale gelmiş halidir. KAOS bir SQL enjeksiyonu için "olabilir" demez; enjeksiyonu çalıştırır, beklenen veritabanı davranışını tetikler ve bunu kanıt olarak kaydeder. Bir uzaktan kod çalıştırma için imza aramaz; komutu çalıştırır ve çıktısını okur.

Bu mimari, KAOS'un çok ajanlı yapısıyla mümkün olur. 75'ten fazla uzman ajan, bir orkestratör (swarm) tarafından koordine edilir. Her ajan belirli bir saldırı yüzeyinde uzmandır: web, mobil, exe, apk, tarayıcı eklentileri, dosyalar, ikili dosyalar, web3 ve akıllı kontratlar, terminal. Bir ajan aday bir açık bulduğunda, doğrulama ajanları devreye girer ve bulguyu kanıt seviyesine taşır. Bu sayede KAOS, tek bir taramada XBOW benchmark'ının tamamını, 104 sorgunun 104'ünü birden çözerek yüzde 100 başarı elde etti. Bu, ezberlenmiş imza değil, fiilen sömürme yeteneğinin kanıtıdır.

Canary Çıpalı Doğrulama Nasıl Çalışır

Doğrulamanın kalbinde basit ama güçlü bir fikir vardır: canary çıpası. Canary, KAOS'un sisteme yerleştirdiği benzersiz, tahmin edilemez bir token'dır. Mantık şudur: eğer KAOS bir açığı gerçekten sömürebiliyorsa, kendi yerleştirdiği bu benzersiz işareti, sistemin başka bir noktasından geri okuyabilmelidir. Token geri okunabiliyorsa etki gerçektir; okunamıyorsa bulgu yanlış pozitiftir ve rapora hiç girmez.

Somut bir örnekle açıklayalım. Bir saklı XSS şüphesi olduğunu varsayalım. Tarayıcı, bir girdi alanının çıktıda kaçışsız yansıdığını görür ve "XSS olabilir" der. KAOS ise benzersiz bir canary değeri içeren bir yük gönderir, sonra etkilenmesi beklenen sayfayı ayrı bir bağlamda tekrar talep eder ve o benzersiz değerin yürütülebilir bağlamda geri döndüğünü kontrol eder. Değer döndüyse, bu yalnızca bir teori değil, kanıtlanmış bir zafiyettir. Bir SSRF için canary, KAOS'un kontrol ettiği bir uç noktaya gelen isteğin içine gömülür; istek geldiyse sunucunun gerçekten dışarı çıktığı ispatlanır.

Canary yaklaşımının en büyük değeri, kontrol edilebilir oluşudur. Token'ı KAOS oluşturur, dolayısıyla ortamdaki başka hiçbir veriyle karışmaz. Bir bulgunun "tesadüfen" doğru görünmesi imkansızdır, çünkü dünyada o token'ı yalnızca KAOS bilir. Bu, doğrulamayı belirsiz bir tahminden, tekrarlanabilir ve denetlenebilir bir deneye dönüştürür. KAOS bu doğrulamayı kontrollü bir kum havuzunda yapar, yani üretim ortamına zarar vermeden, izole edilmiş ve güvenli bir biçimde.

Bu yaklaşım, üret-doğrula-öğren döngüsünün doğrulama ayağını oluşturur. KAOS bir bulguyu canary ile doğruladığında, sonucu yalnızca rapora değil, bir vektör belleğe de işler. Böylece her kanıtlanmış zafiyet, motorun gelecekteki davranışını besler. Benzer bir saldırı yüzeyiyle tekrar karşılaşıldığında, KAOS daha önce neyin işe yaradığını hatırlar ve doğrulamayı daha hızlı, daha kesin yapar. Bu öğrenme döngüsü, doğrulama mekanizmasını statik bir kontrol listesinden, zamanla keskinleşen yaşayan bir yeteneğe dönüştürür. Canary, yalnızca yanlış pozitifi engellemez, aynı zamanda motorun hafızasını gerçek delillerle besler.

PoC Destekli Bir Bulgu Raporda Nasıl Görünür

Doğrulanmış bir zafiyetin değeri, raporda nasıl sunulduğuyla doğru orantılıdır. KAOS raporlarında her bulgu üç parçadan oluşur: ne olduğu, nasıl kanıtlandığı ve nasıl kapatılacağı. "Nasıl kanıtlandığı" kısmı kritiktir, çünkü orada çalıştırılabilir bir kanıt (proof of concept) yer alır. Çoğu durumda bu, doğrudan terminalde çalıştırılabilen bir curl komutudur. Geliştirici komutu kopyalar, çalıştırır, açığı kendi gözüyle görür. Tartışma biter.

Bu, "olası SQL enjeksiyonu, satır 412" diyen geleneksel bir bulgu ile "şu curl isteğini gönderdiğinizde veritabanı şu yanıtı veriyor, işte canary kanıtı" diyen bir bulgu arasındaki uçurumdur. Birincisi bir iddia, ikincisi bir delildir. Geliştirme ekibi ikinciyi tartışamaz, çünkü kanıt kendi makinelerinde yeniden üretilebilir. Bu, güvenlik ekibi ile geliştirme ekibi arasındaki kronik "bu gerçek mi?" tartışmasını kökünden kaldırır.

KAOS raporları Markdown, HTML, JSON ve SARIF formatlarında üretilir. SARIF özellikle önemlidir, çünkü bulguların doğrudan CI/CD hatlarına ve geliştirici araçlarına entegre edilmesini sağlar. Her bulgu CVSS ve CWE ile sınıflandırılır, OWASP kategorilerine eşlenir ve düzenleyici çerçevelere bağlanır: KVKK, ISO 27001 ve NIS2. Böylece bir bulgu yalnızca teknik bir not olmaktan çıkar, bir uyumluluk ve risk yönetimi öğesine dönüşür. KAOS'un yetenekleri hakkında daha fazla bilgi için KAOS yapay zeka siber güvenlik tarama aracı yazımıza göz atabilirsiniz.

Önceliklendirme: CVSS Değil, Kanıtlanmış Sömürülebilirlik

Birçok güvenlik programı bulguları yalnızca CVSS puanına göre sıralar. Bu, sezgisel ama yanıltıcı bir yöntemdir. CVSS, bir açığın teorik şiddetini ölçer, ancak sizin ortamınızda gerçekten sömürülebilir olup olmadığını söylemez. CVSS 9.8'lik bir açık, ilgili bileşen erişilemezse pratikte sıfır risk taşıyabilir. Buna karşılık CVSS 6.5'lik bir açık, doğrudan internete açık ve sömürülebilir ise acil bir tehdit olabilir.

Doğru önceliklendirme üç boyutu birleştirir. Birincisi şiddet, yani CVSS ve CWE ile ölçülen teorik etki. İkincisi sömürülme olasılığı, yani EPSS (exploit prediction scoring system) gibi modellerin tahmin ettiği, bir açığın vahşi doğada gerçekten sömürülme ihtimali. Üçüncüsü ve en önemlisi kanıtlanmış sömürülebilirlik, yani KAOS'un sizin özel ortamınızda o açığı fiilen sömürüp sömüremediği. KAOS bir bulguyu canary ile doğruladıysa, o açık artık teorik değildir, gerçektir.

Bu yaklaşım önceliklendirmeyi tamamen değiştirir. Listenizin en üstüne CVSS'i en yüksek olan değil, KAOS'un fiilen sömürebildiği bulgular gelir. Çünkü kanıtlanmış bir zafiyet, bir saldırganın da yapabileceği bir şeydir. Ekibiniz spekülatif puanları kovalamak yerine, somut delilleri olan açıkları kapatmaya odaklanır. Bu, sınırlı analist saatinin en yüksek getiriyi sağladığı noktaya yönlendirilmesi demektir. Otomatik zafiyet tarama ve yönetim sürecinin nasıl modernleştiğini yapay zeka ile otomatik zafiyet tarama ve zafiyet yönetimi yazımızda detaylandırdık.

Güvenli Otomatik Çözüm Döngüsü

Bir zafiyeti kanıtlamak hikayenin yarısıdır. Diğer yarısı onu kapatmaktır. KAOS, izniniz dahilinde, bulgunun yalnızca raporlanmasıyla yetinmez, çözümü de uygulayabilir. Ancak bu, körlemesine bir otomasyon değildir; kademeli ve denetlenebilir bir güvenli süreçtir. Otomatik müdahalenin en büyük riski, düzeltirken bir şeyi bozmaktır. KAOS bu riski beş adımlı bir kapı sistemiyle yönetir.

İlk adım yedektir: KAOS değişiklik yapmadan önce ilgili dosya veya yapılandırmanın yedeğini alır. İkinci adım denetim kaydıdır: yapılan her işlem bir audit log'a yazılır, böylece geriye dönük tam izlenebilirlik sağlanır. Üçüncü adım düzeltmenin uygulanmasıdır. Dördüncü adım, ve burası kritiktir, doğrulamadır: KAOS düzeltmeyi uyguladıktan sonra aynı canary çıpalı testi tekrar çalıştırır ve açığın gerçekten kapandığını ispatlar. Beşinci adım geri almadır: eğer doğrulama başarısız olursa veya beklenmedik bir yan etki ortaya çıkarsa, KAOS değişikliği geri alır ve sistemi önceki haline döndürür.

Bu döngünün eleganlığı, doğrulama mantığının hem tespit hem çözüm aşamasında aynı olmasıdır. Açığı kanıtlayan canary, çözümü de kanıtlar. Bir açığın gerçekten kapandığını söylemenin tek dürüst yolu, onu tekrar sömürmeye çalışıp başarısız olmaktır. KAOS bunu yapar. Bu sayede çözüm, bir geliştiricinin "düzelttim sanırım" demesine değil, motorun "tekrar denedim, artık çalışmıyor" demesine dayanır. Yetkilendirme, kapsam sınırı ve geri alınabilirlik bu sürecin tamamına yedirilmiştir.

Egemen ve Yerel: Verileriniz Sizde Kalır

Doğrulanmış zafiyet yaklaşımının çoğu zaman göz ardı edilen bir boyutu, verinin nerede işlendiğidir. KAOS, DSET'in egemen, yüzde 100 yerel, sıfır API bağımlılığı olan yapay zeka motorudur. Başka bir modelin etrafına sarılmış bir kabuk değil, kendi yapay zekasıdır. Bu, taramanın ürettiği hassas verinin, kaynak kodunun, yapılandırma ayrıntılarının ve kanıtlanmış açıkların hiçbir dış servise gönderilmediği anlamına gelir.

Bu, özellikle düzenlemeye tabi sektörler için kritiktir. Bir zafiyet raporunun kendisi, yanlış ellerde bir saldırı haritasıdır. PoC destekli bir bulgu, bir saldırgana sisteminizi nasıl ihlal edeceğini adım adım anlatan bir reçetedir. Böyle bir verinin üçüncü taraf bir bulut hizmetine akması, çözmeye çalıştığınız riskin ta kendisini yaratır. KAOS yerel çalıştığı için bu risk yoktur. Tarama, doğrulama, raporlama ve çözüm, tamamı sizin kontrolünüzdeki ortamda gerçekleşir.

KAOS bu doğrulama gücünü zengin bir bilgi tabanından alır: 800.000'den fazla doküman, tüm CVE kayıtları ve 17.000'den fazla GitHub deposu. Bu bilgi yereldedir, dolayısıyla KAOS güncel saldırı tekniklerini bilirken, sizin verilerinizi dışarıya açmaz. Üstelik motor, her doğrulanmış bulgudan bir vektör bellek aracılığıyla öğrenir; her kanıtlanmış zafiyet, gelecekteki taramaları daha keskin hale getirir. DSET'in sunduğu siber güvenlik hizmetleri yelpazesinin tamamını hizmetler sayfamızdan inceleyebilirsiniz.

Doğrulanmış Bulgular SLA ve Denetim Konuşmalarını Nasıl Değiştirir

Bir güvenlik programının olgunluğu, çoğu zaman teknik yeteneğinden çok, ürettiği bulguların kuruluş içinde nasıl konuşulduğuyla ölçülür. Geleneksel tarama dünyasında SLA'lar bir kurguya dayanır: "kritik bulgular 7 gün içinde, yükseğer 30 gün içinde kapatılacak." Kulağa disiplinli gelir, ama pratikte çöker. Çünkü bir tarayıcı yüz tane "kritik" üretir, bunların seksen tanesi asılsızdır ve geliştirme ekibi yedi günlük sayacın hangi yirmisi için işlediğini bilemez. SLA, gürültünün üzerine kurulduğu için ölçülemez hale gelir ve herkes onu görmezden gelmeyi öğrenir.

Doğrulanmış zafiyet bu denklemi yeniden yazar. Rapora giren her satır kanıtlanmış olduğunda, SLA artık bir tahmine değil bir gerçeğe bağlanır. "Yedi gün içinde kapat" cümlesi, "bu açığı bir saldırgan bugün sömürebilir, kanıtı raporda, yedi gün içinde kapat" anlamına gelir. Sayaç anlamlı bir şeye işler. Geliştirme ekibi de itiraz edemez, çünkü tartışacak bir belirsizlik kalmamıştır. Ben sahada defalarca gördüm: bir geliştiriciye "olası enjeksiyon, satır 412" dediğinizde iki gün boyunca e-posta trafiği döner; "şu komutu çalıştır, veritabanı şunu döndürüyor" dediğinizde o açık öğleden sonra kapanır.

Denetim ve uyumluluk konuşmaları da aynı biçimde sadeleşir. Bir denetçi, ISO 27001 ya da NIS2 kapsamında karşınıza oturduğunda, ürettiğiniz bulgu listesinin ne kadarının gerçek olduğunu sorar. Geleneksel bir programda bu soruya dürüst bir yanıt veremezsiniz, çünkü kendiniz de bilmezsiniz. Doğrulanmış zafiyet yaklaşımında her bulgunun yanında çalıştırılabilir bir kanıt durur; denetçiye gösterirsiniz, o da tartışmaz. Risk kabul kararları da netleşir: bir açığı kapatmamayı seçiyorsanız, en azından gerçek bir açığı kabul ettiğinizi bilirsiniz, bir tarayıcı hayaletini değil. Bu, denetim toplantısını bir savunma seansından bir karar seansına dönüştürür.

Sahadan Bir Örnek: Kanıtlanmış SQL Enjeksiyonunun Yolculuğu

Soyut anlatım yerine somut bir akış üzerinden gidelim, çünkü doğrulanmış zafiyetin değeri ancak uçtan uca izlendiğinde anlaşılır. Diyelim ki bir e-ticaret uygulamasında arama parametresi var. Klasik bir tarayıcı bu parametreye tek tırnak gönderir, yanıtta bir veritabanı hata mesajı görür ve "olası SQL enjeksiyonu" diye işaretler. İşte tipik yanlış pozitif kaynağı burasıdır: o hata mesajı, açık olmadan da, örneğin bir girdi doğrulama katmanı tarafından üretiliyor olabilir. Tarayıcı bunu ayırt edemez.

KAOS aynı noktada durmaz. Parametreyi bulduğunda, enjeksiyonun gerçekten veri katmanına ulaşıp ulaşmadığını sınamak için bir yük kurar. Zaman tabanlı bir teknik kullanıyorsa, veritabanına ölçülebilir bir gecikme komutu enjekte eder ve yanıtın gerçekten o kadar geciktiğini doğrular. Boolean tabanlı bir teknik kullanıyorsa, doğru ve yanlış koşulların sayfada farklı çıktılar ürettiğini differential olarak karşılaştırır. Daha da iyisi, çıkarılabilir bir veri kanalı varsa, kendi canary değerini veritabanından geri çekmeye çalışır. O benzersiz değer geri döndüğünde iş biter: bu artık bir hata mesajı yorumu değil, veritabanından okunmuş somut bir kanıttır.

Bulgu rapora şöyle düşer: başlıkta CWE-89 ve hesaplanmış CVSS, gövdede açığın hangi parametrede olduğu, hemen altında kopyala-çalıştır bir curl komutu ve o komutun döndürdüğü canary çıktısı, en sonda da parametreli sorgu ya da ORM bağlama önerisiyle somut çözüm. Geliştirici bu üç şeyi bir arada gördüğünde tartışacak bir şey bulamaz. Komutu kendi makinesinde çalıştırır, açığı görür, parametreli sorguya geçer, ardından KAOS aynı canary testini tekrar koşar ve bu kez değerin geri dönmediğini, yani açığın kapandığını ispatlar. Tespitten kapanışa kadar her adım kanıta dayanır, hiçbir yerinde "sanırım" yoktur.

Gürültünün Bilançoya Yansıyan Maliyeti

Yanlış pozitifin maliyetini analist saatleri üzerinden konuşmak doğru ama eksiktir; asıl resim bilançoya bakınca netleşir. Orta ölçekli bir güvenlik ekibi düşünün, beş mühendis. Her biri haftasının önemli bir kısmını asılsız uyarıları elemeye harcıyorsa, yılda kaç adam-ay'ın gürültü temizliğine gittiğini hesaplamak zor değildir. Bu, doğrudan maaş gideri olarak masaya yatırılabilir ve çoğu yönetici bu sayıyı ilk kez gördüğünde irkilir. Çünkü o bütçe, aslında yeni bir tehdit avı yeteneği ya da bir kıdemli uzmanın işe alımı anlamına gelebilirdi.

Gizli kalan ikinci kalem, geciken kapanış süresidir. Gerçek bir açık, yüzlerce asılsızın arasında ortalama daha geç fark edilir. Bir saldırganın bir açığı bulması ile savunmanın onu kapatması arasındaki bu pencere, ihlal olasılığının doğrudan çarpanıdır. Gürültü bu pencereyi uzatır. Doğrulanmış zafiyet yaklaşımı, rapora yalnızca gerçek açıkları soktuğu için, ekibin dikkatini ilk dakikadan doğru hedefe kilitler ve ortalama kapanış süresini kısaltır. Kısalan her gün, somut bir risk azalmasıdır.

Üçüncü ve en sinsi kalem, kötü önceliklendirmenin yarattığı kör nokta maliyetidir. Ekip enerjisini yüksek CVSS'li ama sömürülemez bir teorik açığa harcadığında, o sırada gerçekten internete açık ve sömürülebilir bir orta şiddetli açık bekler. Saldırgan ikincisini seçer, çünkü onun derdi puan değil erişimdir. Doğrulanmış zafiyet, önceliklendirmeyi saldırganın mantığına hizalar: önce kanıtlanmış olarak sömürülebilen, sonra teorik olarak şiddetli. Bu hizalama, aynı analist saatinden çok daha fazla gerçek risk azalması üretir. Güvenlik harcamasının verimliliği, ne kadar çok taradığınızla değil, kanıta dayalı ne kadar doğru önceliklendirdiğinizle ölçülür.

SSS

Doğrulanmış zafiyet ile geleneksel tarayıcı bulgusu arasındaki fark nedir?

Geleneksel bir tarayıcı imza eşleştirmesi yapar ve bir açığın var olabileceğini işaretler, ancak gerçekten sömürülebilir olup olmadığını denemez. Doğrulanmış zafiyet ise motorun kendi yazdığı bir exploit ile açığı fiilen sömürdüğü, etkisini canary çıpasıyla kanıtladığı bulgudur. Birincisi bir iddiadır, ikincisi tekrarlanabilir bir delildir.

Canary token nedir ve neden yanlış pozitifleri önler?

Canary, KAOS'un sisteme yerleştirdiği benzersiz, tahmin edilemez bir işarettir. KAOS bir açığı sömürdüğünü iddia ettiğinde, kendi yerleştirdiği bu token'ı sistemin başka bir noktasından geri okuyabilmelidir. Token geri okunuyorsa etki gerçektir. Bu işareti dünyada yalnızca KAOS bildiği için, bir bulgunun tesadüfen doğru görünmesi imkansızdır ve yanlış pozitifler rapora hiç giremez.

PoC destekli bir bulgu sızma testi raporumda neye benzer?

Her bulgu üç parça içerir: açığın ne olduğu, nasıl kanıtlandığı ve nasıl çözüleceği. Kanıt kısmında çoğunlukla doğrudan çalıştırılabilen bir curl komutu bulunur. Geliştiriciniz komutu kopyalayıp çalıştırarak açığı kendi gözüyle görür. Raporlar Markdown, HTML, JSON ve SARIF formatlarında üretilir ve bulgular CVSS, CWE, OWASP ile sınıflandırılıp KVKK, ISO 27001 ve NIS2 çerçevelerine eşlenir.

KAOS bulguları yalnızca CVSS puanına göre mi önceliklendirir?

Hayır. CVSS teorik şiddeti ölçer ama sizin ortamınızdaki gerçek riski göstermez. KAOS üç boyutu birleştirir: CVSS ve CWE ile şiddet, EPSS gibi modellerle sömürülme olasılığı ve en önemlisi kanıtlanmış sömürülebilirlik. KAOS'un sizin ortamınızda fiilen sömürebildiği açıklar, en yüksek CVSS'e sahip teorik açıkların önüne geçer.

Otomatik çözüm üretim sistemime zarar verir mi?

KAOS yalnızca izniniz dahilinde ve beş adımlı güvenli bir süreçle çözüm uygular: önce yedek alır, bir denetim kaydı yazar, düzeltmeyi uygular, ardından aynı canary testiyle açığın gerçekten kapandığını doğrular ve bir sorun çıkarsa değişikliği geri alır. Süreç yetkilendirilmiş, kapsamı sınırlı ve geri alınabilir olduğu için kontrol her zaman sizdedir.

Sonuç

Güvenlik artık daha çok uyarı üretmekle ilgili değil, daha az ama kanıtlanmış uyarı üretmekle ilgilidir. Binlerce asılsız "kırmızı" satırın altında ezilen bir ekip, gerçek tehdidi göremez. KAOS bu denklemi tersine çevirir: rapora giren her satır, motorun kendi yazdığı bir exploit ile, kontrollü bir kum havuzunda, canary çıpasıyla ispatlanmıştır. Yanlış pozitif yoktur, çünkü kanıtsız hiçbir şey raporlanmaz. Her bulgunun yanında çalıştırılabilir bir PoC ve somut bir çözüm vardır. Ve izniniz dahilinde, KAOS açığı yalnızca göstermekle kalmaz, güvenli bir döngüyle kapatır.

Bu, egemen, yüzde 100 yerel, kendi yapay zekasına sahip bir motorla, verileriniz hiç dışarı çıkmadan gerçekleşir. Saha kanıtı nettir: KAOS tek bir taramada XBOW benchmark'ının 104 sorgusunun 104'ünü birden çözdü. Analist saatlerinizi gürültüye değil gerçek açıklara harcamak, raporlarınıza güveni geri getirmek ve zafiyetleri yalnızca tespit değil kanıt seviyesinde yönetmek istiyorsanız, doğru zamandasınız.

DSET'in siber güvenlik hizmetler yelpazesini inceleyin ve doğrulanmış zafiyet yaklaşımını kendi altyapınızda görmek için bizimle iletişim kurun. Saldırı yüzeyinizin tamamını proaktif yönetmek için ayrıca saldırı yüzeyi yönetimi ve dış saldırı yüzeyi keşfi yazımız ve KAOS sayfamız yol gösterici olacaktır.

Kaynaklar