---
title: "Guardian360 tarama motorunu neden değiştiriyor ve neden \"daha az\" \"daha güvenli\" anlamına gelecek | Guardian360"
description: "Bir süredir güvenlik açığı tarayıcılarıyla çalışıyorsanız, düzeni bilirsiniz: bir tarama çalıştırın, devasa bir liste alın, önem derecesine göre sıralayın ve kırmızıların peşine düşün. İşe yarar, ta ki…"
url: https://guardian360.net/tr/blog/why-guardian360-is-replacing-its-scanning-engine-and-why-less-will-mean-safer/
locale: tr
source: guardian360.net
---
[← Tüm yazılar](https://guardian360.net/tr/blog)

Awareness

# Guardian360 tarama motorunu neden değiştiriyor ve neden "daha az" "daha güvenli" anlamına gelecek

Yazan Guardian360 · 16 Ocak 2026

Bir süredir güvenlik açığı tarayıcılarıyla çalışıyorsanız, düzeni bilirsiniz: bir tarama çalıştırın, devasa bir liste alın, önem derecesine göre sıralayın ve kırmızıların peşine düşün.

Bu *işe yarar*, ta ki yaramayana kadar.

Çünkü 2026'daki gerçek şudur: güvenlik açığı verileri patlıyor, saldırgan davranışı hızla değişiyor ve çoğu BT ekibindeki en kıt kaynak araçlar değil… zamandır.

Bu nedenle Guardian360, Lighthouse'ta iki büyük değişiklik yapıyor:

1. Tarayıcı cephanemizi (tarama "motor dairemiz") değiştiriyoruz.
2. Teknik bulguları iş riskine bağlayan, ISO 27001, NIS2 ve diğer çerçevelerle uyumlu, risk temelli bir yaklaşım getiriyoruz.

Ve evet: birçok iş ortağı ve müşteri için bu, haklı bir soru doğuracak:

**"Daha az güvenlik açığı mı göreceğiz… ve bu gerçekten güvenli mi?"**

Bu kararların ardındaki "nedeni" ve neden daha az, daha ilgili bulgunun genellikle daha iyi sonuçlara, daha iyi içgörülere ve pahalı saatlerin çok daha etkili kullanımına yol açtığını inceleyelim.

## 1. Tarayıcı cephanemizi neden değiştiriyoruz

Taramayı şu hale getirmek için temeli yeniden inşa ediyoruz:

- **Daha güvenilir** (tutarlı sonuçlar, daha az uç durum sürprizi)
- **Daha hızlı** (daha az bekleme, daha sürekli görünürlük)
- **Daha hafif** (daha düşük ayak izi ve operasyonel yük)

Ve stratejik bir neden de var:

**Sanal makinelerin ötesine geçerek bir aracıya doğru**

Bugün birçok tarama çözümü hâlâ büyük ölçüde sanal makinelere ve ağır dağıtımlara dayanıyor. Yönümüz net: **aracı temelli yetenekleri etkinleştirmek**, böylece iş ortakları ve müşteriler, varsayılan yaklaşım olarak her zaman sanal cihazları sürdürmeye gerek kalmadan kapsam elde edebilir.

Bu, değişiklik uğruna değişiklik değildir. Bu, Lighthouse'un bir sonraki aşamasına hazır bir tarama platformu inşa etmekle ilgilidir: **sürekli içgörüler, daha düşük operasyonel sürtünme ve daha eyleme geçirilebilir sonuçlar.**

## 2. Risk temelli bir yaklaşımı neden getiriyoruz (ve neden ISO 27001 ile NIS2'ye daha iyi uyuyor)

Çoğu tarayıcı teknik bir soruyu yanıtlamak için tasarlanmıştır:

"Bu güvenlik açığı ne kadar ciddi?"

Ancak ISO 27001, NIS2 ve modern güvenlik yönetişimi, sizden farklı bir soruyu yanıtlamanızı gerektirir:

"Peki bu, kuruluşumuz için ne anlama geliyor ve önce ne yaparız?"

Bu değişim önemlidir, çünkü teknik önem derecesi tek başına iş riskini tanımlamaz. İş riski bağlama bağlıdır: güvenlik açığının nerede bulunduğu, neye dokunduğu ve kötüye kullanılırsa ne olacağı.

### CIA: "yalnızca önem derecesi" temelli güvenlik açığı yönetiminde eksik olan bileşen

Bu bağlamı açık hale getirmenin pratik bir yolu klasik CIA üçlüsüdür:

- **Gizlilik (Confidentiality)**: istismar, hassas bilgileri (müşteri verileri, fikri mülkiyet, kimlik bilgileri, tıbbi kayıtlar) ifşa eder mi?
- **Bütünlük (Integrity)**: istismar, kurcalamaya (verileri değiştirme, işlemleri manipüle etme, yapılandırmaları değiştirme, günlükleri zehirleme) izin verebilir mi?
- **Kullanılabilirlik (Availability)**: istismar, kesinti veya aksamaya (fidye yazılımı etkisi, hizmet kesintisi, üretim durması) neden olabilir mi?

Başka bir deyişle: aynı CVE, varlığın CIA profiline bağlı olarak *çok farklı şeyler* ifade edebilir.

Örnek: aynı güvenlik açığı, farklı iş riski

Düşük değerli bir test sunucusundaki "yüksek önem dereceli" bir güvenlik açığı rahatsız edici olabilir, ancak işi tehdit edici değildir.

Aynı güvenlik açığı şu sistemlerde bulunduğunda:

- bordro işleyen bir sistem (bütünlük),
- kişisel veriler içeren bir müşteri portalı (gizlilik),
- veya hastane için kritik bir uygulama (kullanılabilirlik),

…birdenbire önemli bir iş riskine dönüşür.

Dolayısıyla, her bulguyu eşit muamele edip yalnızca CVSS'ye göre sıralamak yerine, risk temelli bir yaklaşım şunu sorar:

- Hangi varlık etkileniyor?
- Bu varlık gizlilik, bütünlük ve kullanılabilirlik açısından ne kadar kritik?
- Bu ortamda erişilebilir / istismar edilebilir mi?
- Kötüye kullanılırsa gerçek dünyadaki etkisi nedir?
- En etkili sonraki eylem nedir?

**Bu neden ISO 27001 ve NIS2'ye daha iyi uyuyor**

ISO 27001 bir "tüm güvenlik açıklarını topla" standardı değildir. Riski kontrollü, tekrarlanabilir bir şekilde tanımlayan, değerlendiren ve işleyen bir ISMS işletmekle ilgilidir. Risk temelli bir yaklaşım bunu doğrudan destekler: bir şeye *neden* öncelik verdiğinizi, *ne* yaptığınızı ve riski *nasıl* azalttığını gösterebilirsiniz.

NIS2, kuruluşları yalnızca teknik çıktıya değil, ölçülebilir dayanıklılığa ve hesap verebilir risk yönetimine yönlendirir. Risk temelli bir yaklaşım, iş ortaklarının ve müşterilerin iş terimleriyle iletişim kurmasına yardımcı olur, çünkü yönetim kurulları ve denetçiler "8.000 bulgumuz vardı" değil, "kritik hizmetlere yönelik riski azalttık" duymak ister.

Sonuç: daha iyi kararlar, daha iyi kanıt, daha az boşa harcanan çaba

Bulguları CIA ve iş bağlamıyla ilişkilendirerek, Lighthouse şuradan geçiş yapabilir:

- "İşte korkutucu bir liste"

şuraya:

- "İşte gerçekten önem verdiğiniz şeyleri tehlikeye atan sorunlar ve bunları düzeltmek için en akıllıca sıra."

Risk temelli yaklaşımın özü budur: daha az önlem değil, daha iyi önceliklendirme ve daha güçlü yönetişim.

## 3. Rahatsız edici gerçek: her CVE sizin ortamınız için önemli değildir

İşte güvenlik açığı yönetiminde sıklıkla gözden kaçan kısım: **CVE evreni devasadır** ve büyük kısmı sizin özel müşteri ortamınız için hiçbir zaman önemli olmayacaktır.

- National Vulnerability Database (NVD), **yüz binlerce CVE** listeler (yazının yazıldığı sırada 326 binden fazla)( [https://nvd.nist.gov/general/nvd-dashboard](https://nvd.nist.gov/general/nvd-dashboard)).
- Bu arada, "bu, gerçek ortamda istismar ediliyor" için pratik bir referans olan CISA Known Exploited Vulnerabilities (KEV) kataloğu **yaklaşık 1.484 kayıt** içerir (2025 yıl sonu raporlaması)( [https://www.securityweek.com/cisa-kev-catalog-expanded-20-in-2025-topping-1480-entries](https://www.securityweek.com/cisa-kev-catalog-expanded-20-in-2025-topping-1480-entries)).

Bu karşıtlık "diğer her şeyi görmezden gelin" anlamına gelmez. Şu anlama gelir:

**Önem derecesi, risk ile aynı şey değildir**

Bir CVSS puanı, belirli varsayımlar altında bir şeyin ne kadar kötü *olabileceğini* söyler. Önümüzdeki günlerde veya haftalarda istismar edilme olasılığının ne kadar yüksek olduğunu **söylemez**.

EPSS gibi modeller bu yüzden vardır: gözlemlenen sinyallere ve kalıplara dayanarak istismar olasılığını tahmin etmek için. FIRST'ün EPSS belgeleri, istismar faaliyetinin yayımlanan CVE'lerin küçük bir alt kümesinde nasıl yoğunlaştığını gösterir (örnekleri, 30 günlük bir pencerede gözlemlenen istismar faaliyetiyle ~%2,7 gösterir)( [https://www.first.org/epss/model](https://www.first.org/epss/model)).

Ve tehdit raporlaması, istismarın önemli bir ilk erişim vektörü olduğunu göstermeye devam ediyor, ancak yine, saldırganların en iyi yatırım getirisini elde ettiği yerde yoğunlaşıyor. Verizon'un 2025 DBIR raporu, güvenlik açıklarının istismarını önde gelen bir ihlal vektörü olarak (%20) vurgular ve yıldan yıla önemli bir artış olduğunu belirtir ([https://www.verizon.com/about/news/2025-data-breach-investigations-report](https://www.verizon.com/about/news/2025-data-breach-investigations-report)).

Yani evet: **güvenlik açıkları önemlidir**. Ancak **eşit derecede değil** ve hepsi aynı anda değil.

## 4. "Daha az güvenlik açığı" neden daha iyi güvenlik sonuçlarına yol açabilir

Devasa bir bulgu listesi, öngörülebilir üç sorun yaratır:

**1) Gürültü sinyali gömer**

Her şey acil göründüğünde, hiçbir şey acil değildir. Ekipler, teknik olarak geçerli ancak pratikte alakasız öğeleri önceliklendirmek için zaman harcar.

**2) Zaman, riskli olana değil, kolay olana harcanır**

İş bağlamı olmadan, giderme bir yama popülerlik yarışmasına dönüşür: etkilenen sistem kritik olmasa veya erişilemez olsa bile "önce en yüksek CVSS".

**3) Raporlama gösterişe dönüşür**

Riski *azalttığınızı* kanıtlamak yerine, *çok çalıştığınızı* kanıtlamaya çalışırsınız.

Risk temelli bir yaklaşım bunu tersine çevirir:

- Neyin **istismar edilebilir**, **erişilebilir** ve **önemli** olduğuna odaklanın
- Bulguları **iş etkisine** bağlayın
- Gidermeyi **ölçülebilir**, **açıklanabilir** ve **denetlenebilir** hale getirin

Güvenlik açığı yönetimini kahramanca değil, sürdürülebilir hale getirmenin yolu budur.

## 5. İş ortakları Lighthouse'ta neler bekleyebilir

Yeni tarama temeli ve risk temelli yaklaşımla, iş ortakları şunları elde edecek:

- **İş riskine daha iyi içgörü** (teknik önem derecelerine ek olarak)
- **Daha ilgili tarama sonuçları**, boşa harcanan çabayı azaltarak
- **Daha etkili giderme**, çünkü eylemler gerçek dünya riskine ve iş bağlamına göre önceliklendirilir
- **Daha güçlü uyumluluk kanıtı**, çünkü kararlar ve eylemler açıklanabilir ve yönetişim gereksinimleriyle eşleştirilebilir

Misyonumuza pratik anlam kazandırmanın yolu budur:

**"Dijital yönetişim ve dayanıklılık el altında."**

Ve vizyonumuz:

**"Karar vericileri işlerini güvence altına almak, uyum sağlamak ve optimize etmek için içgörülerle güçlendirmek."**

## 6. Sonuç olarak

Amacımız *daha fazla* bulgu göstermek değil.

Amacımız **doğru bulguları** doğru anda, doğru bağlamda göstermek, böylece iş ortakları ve müşteriler sınırlı zamanlarını riski en çok azaltacakları yere harcayabilir.

"10.000 sorun bulundu" ifadesini gururla gösteren tarayıcılara alışkınsanız, bu değişim ilk başta mantığa aykırı gelebilir.

Ama pratikte, **daha az gürültü + daha fazla ilgililik = daha iyi içgörü + daha hızlı risk azaltma**.

Ve Lighthouse tam olarak oraya yöneliyor.