Zafiyet Tarama Nedir? Zafiyet Yönetimi ve Düzenli Tarama Rehberi

Bir kurum ilk zafiyet taramasını tamamlıyor. Scanner birkaç saat çalışıyor ve yüzlerce sonuç üretiyor. Yönetim dashboard üzerinde kırmızı, turuncu ve sarı sayıları görüyor. Teknik ekip sonuçları Excel’e aktarıyor. En yüksek CVSS skorlarına göre ticket’lar açılıyor.

Üç ay sonra aynı tarama tekrarlandığında tablo çok az değişmiş oluyor.

Bazı bulgular gerçekte ilgili sistemde bulunmuyor. Bazıları patch uygulanmasına rağmen açık görünmeye devam ediyor. Bir kısmında sistem sahibi belli değil. Kritik olarak işaretlenen eski bir servis production trafiği almıyor. Buna karşılık internete açık ve aktif exploitation görülen daha düşük skorlu bir vulnerability, listenin ortasında bekliyor. Yeni açılan cloud varlığı ise scanner scope’una hiç eklenmediği için raporda görünmüyor.

Tarama yapılmış fakat risk yönetilmemiştir.

Bu örnek, zafiyet tarama programlarının neden yalnızca tool seçimiyle kurulamayacağını gösterir. Scanner geniş ve tekrarlanabilir teknik görünürlük sağlar. Hangi bulgunun gerçekten mevcut olduğunu, hangi varlığın iş açısından kritik olduğunu, hangi exposure’ın önce kapatılması gerektiğini ve remediation’ın doğru uygulanıp uygulanmadığını ise süreç, bağlam ve uzman yorumu belirler.

Bu rehberde zafiyet tarama nedir, nasıl çalışır, sızma testinden nerede ayrılır, CVSS skoru nasıl yorumlanır, false positive ve false negative nasıl yönetilir, doğru tarama sıklığı nasıl belirlenir ve kurumsal bir zafiyet yönetimi programı nasıl kurulmalıdır sorularını teknik ayrıntılarıyla ele alacağız.

1. Zafiyet tarama nedir?

Zafiyet tarama, sistemleri ve sistem özelliklerini keşfetmek, kullanılan teknoloji ile configuration hakkında bilgi toplamak ve bu bilgileri bilinen vulnerability verileriyle eşleştirerek potansiyel güvenlik açıklarını belirlemek için yürütülen büyük ölçüde automated bir assessment tekniğidir.

NIST, vulnerability scanning kavramını host’ları, host özelliklerini ve bunlarla ilişkili vulnerability’leri belirlemek için kullanılan bir teknik olarak tanımlar. NIST SP 800-115, taramanın outdated software, missing patch ve misconfiguration tespitinde kullanılabileceğini, sonuçların ise uzman tarafından yorumlanması gerektiğini özellikle belirtir.

Bir tarama şu tür sonuçlar üretebilir:

• Eksik işletim sistemi ve application patch’leri
• Bilinen CVE’lerden etkilenen package ve servisler
• Destek süresi sona ermiş software
• Güvensiz protocol veya service exposure
• Zayıf TLS configuration
• Default veya riskli configuration
• Açık management interface
• Gereksiz port ve servisler
• Web server ve middleware configuration sorunları
• Container image içindeki vulnerable dependency’ler
• Cloud control plane üzerindeki riskli configuration
• Security baseline sapmaları

Bu liste önemli bir sınırı da gösterir. Zafiyet tarama çoğunlukla bilinen, teknik olarak fingerprint edilebilen veya belirli bir kontrolle eşleştirilebilen sorunlarda güçlüdür.

Zafiyet tarama ne değildir?

Zafiyet tarama:

• Bir sistemin tamamen güvenli olduğunu kanıtlamaz
• Scope dışında kalan varlıkları kendiliğinden kapsamaz
• Bütün sonuçların exploit edilebilir olduğunu göstermez
• Business logic akışlarını insan gibi yorumlamaz
• Her authorization problemini güvenilir biçimde bulmaz
• Gerçek iş etkisini tek başına belirlemez
• Remediation’ın doğru yapıldığını ticket durumundan anlayamaz
• Yılda bir kez yapıldığında sürekli görünürlük sağlamaz
• Zafiyet yönetimi programının tamamı değildir

Bir tool’un “0 Critical” göstermesi, kritik risk bulunmadığı anlamına gelmeyebilir. Scanner ilgili host’a erişememiş, authentication kuramamış, yanlış teknoloji version’ı algılamış veya yalnızca bilinen signature set’iyle çalışmış olabilir.

Zafiyet, exposure ve finding aynı şey mi?

Bu üç kavram raporlarda birbirine karışabilir.

Vulnerability, bir threat source tarafından exploit edilebilecek teknik veya süreçsel zayıflıktır.

Exposure, bir varlığın saldırıya açık hale gelmesine katkıda bulunan erişilebilirlik veya configuration durumudur. İnternete açık bir management port her zaman kendi başına CVE değildir fakat attack surface’i büyütür.

Finding, scanner veya assessor tarafından üretilen gözlemdir. Finding gerçek vulnerability, configuration sapması, informational kayıt veya false positive olabilir.

Bu ayrım yapılmadığında her open port “açık”, her scanner signal’i “doğrulanmış zafiyet” gibi raporlanır.

Zafiyet tarama ile zafiyet yönetimi arasındaki fark

Zafiyet tarama bir tespit tekniğidir. Zafiyet yönetimi ise bu tekniği kullanan daha geniş bir kurumsal süreçtir.

Zafiyet yönetimi:

• Hangi varlıkların bulunduğunu bilir
• Her varlığın owner ve criticality bilgisini tutar
• Tarama coverage’ını ölçer
• Findings’i doğrular ve zenginleştirir
• Risk tabanlı remediation sırası oluşturur
• SLA ve exception süreçlerini yönetir
• Düzeltmeyi re-scan ile doğrular
• Yeni CVE ve attack surface değişikliklerini takip eder
• Sonuçların zaman içindeki trend’ini ölçer

Scanner olmadan ölçekli zafiyet yönetimi zordur. Yalnızca scanner kullanmak ise zafiyet yönetimi değildir.

2. Zafiyet tarama ile sızma testi arasındaki fark

Zafiyet tarama ile sızma testi arasındaki farkı “otomatik olan ve manuel olan” şeklinde tek cümlede anlatmak eksik kalır.

Zafiyet tarama büyük ölçüde automation kullanır fakat iyi bir hizmette scope tasarımı, scan profile, credential kontrolü, false positive triage ve risk yorumlama için uzman emeği gerekir. Sızma testi ise manuel analiz ağırlıklıdır fakat keşif, fuzzing, endpoint enumeration ve bilinen vulnerability kontrollerinde automation’dan yararlanabilir.

Asıl ayrım şudur:

Terminoloji notu: Sızma testi ile pentest farklı hizmetler değildir

“Pentest”, “penetration testing” ifadesinin yaygın kısaltmasıdır. “Sızma testi” ise aynı çalışmanın Türkçedeki karşılığıdır. Bu nedenle sızma testi ile pentest arasında evrensel bir metodoloji farkı yoktur.

Bazı provider’ların “sızma testi” ve “pentest” adlarıyla farklı paketler satması kendi ticari sınıflandırmaları olabilir. Fakat teknik literatürde bunları iki ayrı assessment türü gibi göstermek doğru değildir.

Zafiyet tarama, sızma testi ve pentest karşılaştırması

Zafiyet tarama ve penetration testing rakip değildir. Biri sürekli ve geniş görünürlük, diğeri seçilen scope üzerinde derin assurance sağlar. Bu ilişkinin diğer boyutlarını Sızma Testi Nedir? Kapsamlı Rehber içinde inceleyebilirsiniz.

Scanner neden IDOR ve business logic açıklarını kaçırabilir?

Bir scanner URL içindeki user_id=172 değerini user_id=173 olarak değiştirebilir. Fakat iki kaydın farklı müşterilere ait olduğunu, ikinci kullanıcının ilk kaydı görmemesi gerektiğini ve response içindeki değişikliğin gerçekten yetkisiz veri erişimi oluşturduğunu her zaman anlayamaz.

IDOR testinde:

• Kullanıcı
• Role
• Tenant
• Object ownership
• Action
• State

ilişkileri birlikte değerlendirilir. Bu problemin neden otomatik kontrollerden kaçabildiğini IDOR açığı neden hâlâ bu kadar yaygın? yazımızda ayrıntılı olarak ele alıyoruz.

Benzer şekilde SSRF scanner tarafından belirli payload pattern’leriyle işaretlenebilir. Ancak DNS resolution, redirect chain, parser difference, cloud metadata boundary, egress policy ve application’ın gerçek business requirement’ı birlikte yorumlanmadan savunmanın yeterliliği anlaşılamaz. Bu katmanları SSRF’yi kapatmak için yalnızca allowlist yeterli mi? rehberimizde inceliyoruz.

3. Zafiyet tarama türleri

Tek bir scanner ve tek bir scan profile bütün attack surface’i kapsamaz. Tarama türü asset, erişim modeli ve cevaplanmak istenen soruya göre seçilmelidir.

Ağ tabanlı zafiyet tarama

Network-based scanning, IP üzerinden erişilebilen host, port, protocol ve servisleri değerlendirir. External veya internal konumdan yürütülebilir.

Tespit edebileceği örnekler:

• Exposed service
• Eski service version
• Bilinen network-reachable CVE
• Zayıf TLS configuration
• Default service
• Anonymous access
• Riskli management protocol
• Network device firmware sorunu

Taramanın nereden yapıldığı sonucu değiştirir. Internet’ten yapılan external scan perimeter control arkasındaki varlıkları göremez. Internal scanner ise içeride erişilebilen daha geniş service set’ini bulabilir.

Web application ve API taraması

Dynamic Application Security Testing veya web vulnerability scanning, çalışan application’a HTTP/S üzerinden istek gönderir ve response davranışını analiz eder.

Şunlarda yararlı olabilir:

• Reflected input
• Bazı injection pattern’leri
• Güvensiz header ve cookie attribute’ları
• Known component exposure
• Directory ve file discovery
• TLS ve server configuration
• Basit authentication configuration sorunları
• Public API endpoint keşfi

Ancak authenticated state, multi-step workflow, one-time token, role geçişi, business logic ve tenant isolation tarama coverage’ını hızla zorlaştırır. Web scanner’ın login olması, bütün application akışını anladığı anlamına gelmez.

Host tabanlı ve agent tabanlı tarama

Host veya agent tabanlı yaklaşım, işletim sistemi üzerinde local package, patch, configuration ve software inventory bilgisine erişir.

Avantajları:

• Network banner’ına daha az bağımlıdır
• Kapalı port arkasındaki local software’i görebilir
• Installed package ile vendor advisory eşlemesi yapabilir
• Local configuration ve patch state hakkında daha ayrıntılı bilgi sağlar
• Network’te her zaman erişilebilir olmayan endpoint’leri değerlendirebilir

Agent kullanımı ayrıca deployment, resource consumption, data handling ve platform compatibility gerektirir.

Cloud zafiyet ve configuration taraması

Cloud assessment tek katman değildir:

• Public endpoint ve service scanning
• Cloud control plane configuration analizi
• IAM permission ve trust değerlendirmesi
• Storage exposure kontrolü
• Security group ve network policy analizi
• Managed service configuration kontrolü
• Workload içindeki operating system ve package scanning
• Serverless ve container dependency analizi

Yalnızca public IP’leri taramak, cloud environment’ı değerlendirmek değildir. Buna karşılık cloud API üzerinden configuration kontrolü yapmak da workload içindeki vulnerable package’leri otomatik olarak kapsamaz.

Container ve image scanning

Container image scanning, image layer’ları içindeki operating system package’lerini ve application dependency’lerini bilinen vulnerability verileriyle eşleştirir.

İyi bir program:

• Base image’i
• Operating system package’lerini
• Language dependency’lerini
• Image digest’i
• SBOM verisini
• Registry’de bekleyen eski image’ları
• Production’da gerçekten çalışan digest’i

birlikte izler.

Build sırasında temiz görünen image, ertesi gün yeni bir CVE yayımlandığında riskli hale gelebilir. Image değişmemiş olsa bile vulnerability verisi değişmiştir. Bu nedenle yalnızca build-time scan yeterli değildir.

Authenticated ve unauthenticated tarama

Unauthenticated scan, scanner’ın hedefe normal network erişimiyle yaklaştığı modeldir. Dış saldırganın görebildiği service ve version sinyallerini anlamak için değerlidir.

Authenticated scan, scanner’a hedef sistem üzerinde kontrollü credential verildiği modeldir. Local package, patch state ve configuration verisi alınabildiği için coverage artar.

İki yaklaşım birbirinin yerine geçmez. Unauthenticated scan gerçek dış görünümü, authenticated scan ise içerideki teknik durumu daha ayrıntılı gösterir.

Passive ve active yaklaşım

Active scan hedefe doğrudan probe gönderir. Daha ayrıntılı sonuç üretebilir fakat production etkisi riski taşır.

Passive discovery network telemetry, flow, DNS, cloud event veya mevcut sensor verisi üzerinden asset ve service gözlemi yapar. Daha düşük etkili olabilir fakat yalnızca görülen trafik kadar bilgi üretir.

Özellikle OT, medical device ve legacy sistemlerde passive inventory ile dikkatli planlanan active kontroller birlikte kullanılabilir.

4. Zafiyet tarama nasıl çalışır?

Scanner arayüzünde bir target girip “Start” düğmesine basmak, arka plandaki karar zincirini görünmez hale getirir. Sonucun doğruluğunu anlamak için süreci ayırmak gerekir.

Scope ve authorization
        ↓
Asset discovery
        ↓
Port ve service identification
        ↓
Technology fingerprinting
        ↓
Known vulnerability ve configuration check eşlemesi
        ↓
Safe probe veya authenticated local check
        ↓
Evidence, severity ve remediation üretimi
        ↓
Validation, prioritization ve ticketing

Scope ve authorization

Tarama başlamadan önce:

• Domain, IP, CIDR ve cloud account
• Internal veya external scanner konumu
• Production ve non-production ayrımı
• Authenticated scan account’ları
• Yasaklı host ve protocol’ler
• Test window
• Rate limit ve concurrency
• Emergency contact
• Stop condition
• Third-party varlıklar

belirlenmelidir.

Public IP’ye erişilebilmesi onu taramak için otomatik yetki vermez. Cloud provider, managed service veya third-party platform sınırları ayrıca değerlendirilmelidir.

Asset discovery

Scanner önce hangi host’ların canlı olduğunu ve hangi servislerin erişilebilir göründüğünü belirlemeye çalışır. ICMP’ye cevap vermeyen bir host yine de TCP service sunabilir. Bu nedenle yalnızca ping sonucuna güvenmek coverage kaybı oluşturabilir.

Asset discovery şu sinyalleri kullanabilir:

• DNS ve reverse DNS
• TCP ve UDP response
• Cloud inventory
• Agent inventory
• Certificate ilişkileri
• CMDB veya asset management verisi
• EASM discovery

Scanner’a yalnızca bilinen IP listesi verilmişse envanterde olmayan shadow IT varlığı bulunmayabilir.

Port ve service identification

Açık port tek başına servisin ne olduğunu garanti etmez. HTTPS yalnızca 443 üzerinde, SSH yalnızca 22 üzerinde çalışmak zorunda değildir.

Service identification:

• Protocol handshake
• Banner
• Response header
• TLS certificate
• Error message
• Default path
• Packet behavior

gibi sinyalleri birleştirir.

Technology fingerprinting

Fingerprinting aşamasında product, version, operating system ve component tahmin edilir. Hata oranının önemli bir bölümü burada oluşur.

Örneğin:

• Reverse proxy backend bilgisini gizleyebilir
• Vendor güvenlik patch’ini version string’i değiştirmeden backport etmiş olabilir
• Banner kasıtlı olarak özelleştirilmiş olabilir
• Load balancer arkasında farklı patch seviyeleri bulunabilir
• Container image ile runtime package state’i farklı olabilir

Bu nedenle “version göründü, CVE kesin var” yaklaşımı güvenilir değildir.

Vulnerability eşleştirme

Scanner elde ettiği bilgiyi:

• CVE kayıtları
• Vendor advisory’leri
• CPE eşleşmeleri
• Plugin veya template bilgisi
• Security baseline
• Configuration policy

ile karşılaştırır.

Bazı check’ler yalnızca version inference yapar. Bazıları güvenli bir network probe gönderir. Authenticated check’ler package manager veya registry üzerinden local state’i okuyabilir. Raporda hangi yöntemle sonuca ulaşıldığı anlaşılmalıdır.

Raporlama

Ham scanner sonucu genellikle şu alanları içerir:

• Etkilenen host
• Port veya component
• Plugin veya check kimliği
• CVE ve CWE ilişkisi
• CVSS skoru
• Detection evidence
• Açıklama
• Remediation

Bu çıktı henüz kurumsal risk sırası değildir. Asset criticality, exposure, KEV, EPSS, owner, compensating control ve business impact eklenmeden remediation kararı eksik kalır.

5. CVSS nedir, skorlar nasıl yorumlanır?

Common Vulnerability Scoring System, bir vulnerability’nin teknik özelliklerini ortak bir vector ve sayısal skorla ifade etmek için FIRST tarafından sürdürülen standarttır.

CVSS v4.0 üç metric group kullanır:

• Base Metrics: Vulnerability’nin intrinsic teknik özellikleri
• Threat Metrics: Zamanla değişebilen exploitation ve threat durumu
• Environmental Metrics: Kurumun kendi environment ve impact bağlamı

CVSS-B, CVSS-BT, CVSS-BE ve CVSS-BTE gibi nomenclature, hangi metric group’ların hesaba katıldığını gösterir.

CVSS severity, risk değildir

FIRST’ün CVSS v4.0 User Guide içindeki en önemli uyarılardan biri şudur:

Base Score:

• Varlığın kurumunuz için ne kadar kritik olduğunu bilmez
• Sistemin internetten erişilebilir olup olmadığını her zaman yansıtmaz
• Compensating control’leri kurumunuza özgü biçimde bilmez
• Vulnerability’nin aktif olarak exploit edilip edilmediğini tek başına göstermez
• Etkilenen business process’i bilmez
• Verinin hassasiyetini bilmez

Bu nedenle “CVSS 9.8 ise otomatik P1, CVSS 7.5 ise bekleyebilir” kuralı hatalı öncelik üretebilir.

CVSS severity tablosu

Örnekler açıklayıcıdır. Aynı vulnerability, vector değerlerine göre farklı score üretebilir. Aksiyon da yalnızca severity’ye değil gerçek environment’a göre verilmelidir.

CVSS 9.8 ne demektir?

CVSS 9.8, ilgili CVSS metric set’i altında Critical teknik severity anlamına gelir.

Şunlar anlamına gelmez:

• Yüzde 98 ihtimalle exploit edilecek
• Risk seviyesi yüzde 98
• Her kurumda aynı aciliyet
• İnternetten mutlaka erişilebilir
• Exploit’in public olduğu
• Compromise’ın kesin olduğu

Exploitation olasılığı için EPSS, aktif exploitation evidence’ı için CISA KEV ve threat reporting, kurum etkisi için asset ve business context ayrıca değerlendirilmelidir.

6. False positive ve false negative yönetimi

Tarama sonucunun kalitesi yalnızca bulunan finding sayısıyla ölçülemez. İki hata türü birlikte yönetilmelidir.

False positive nedir?

False positive, scanner’ın mevcut olmayan veya hedef için geçerli olmayan bir vulnerability’yi raporlamasıdır.

Yaygın nedenler:

• Yanlış service veya version fingerprinting
• Backport edilmiş security patch
• Banner’ın gerçek package state’ini yansıtmaması
• Load balancer arkasındaki farklı node’lar
• Check’in yalnızca version aralığına dayanması
• Vendor advisory ile package naming uyuşmazlığı
• Compensating control’ün sonucu etkisiz hale getirmesi
• Authentication başarısız olduğu halde local check yapılmış gibi yorumlanması
• Third-party endpoint’in yanlış ownership ile scope’a eklenmesi

False negative nedir?

False negative, gerçekte bulunan vulnerability’nin scanner tarafından tespit edilememesidir.

Yaygın nedenler:

• Varlığın envanterde veya scope’ta olmaması
• Host discovery’nin başarısız olması
• WAF, firewall veya rate limit nedeniyle check’in tamamlanamaması
• Authenticated scan account’ının yetersiz privilege’a sahip olması
• Credential’ın çalışmaması
• Scanner feed’inde ilgili check’in bulunmaması
• Custom application logic
• Farklı URL, route, tenant veya role’ın taranmaması
• Scanner’ın stateful workflow’u takip edememesi
• Vulnerability’nin henüz public bilgiye dönüşmemiş olması
• Image taranırken production’da farklı digest çalışması

False negative daha az görünürdür. Dashboard temiz görünür fakat coverage eksiktir.

False positive nasıl azaltılır?

1. 1Asset ve ownership verisini doğrulayın.
2. 2Scanner feed ve plugin set’ini güncel tutun.
3. 3Uygun scan profile kullanın.
4. 4Mümkün olduğunda authenticated checks çalıştırın.
5. 5Authentication success oranını raporlayın.
6. 6Version inference ile active check sonucunu ayırın.
7. 7Vendor advisory ve package state’i karşılaştırın.
8. 8Kritik findings’i uzman incelemesine alın.
9. 9Suppression yerine gerekçeli exception kullanın.
10. 10Re-scan ile sonucu yeniden gözlemleyin.

NIST SP 800-115, automated tool’ların çok sayıda finding üretebildiğini ve false positive ayrıştırmak için sonuçların çoğu zaman doğrulanması gerektiğini belirtir. İkinci bir scanner kullanmak yardımcı olabilir fakat iki tool aynı fingerprint hatasını tekrar edebilir. Uzman incelemesi bu nedenle önemini korur.

False negative nasıl azaltılır?

False negative yönetimi daha çok coverage engineering problemidir:

• CMDB, cloud inventory, EASM ve scanner inventory’yi karşılaştırın
• Agent ve network scan sonuçlarını birleştirin
• External ve internal viewpoint kullanın
• Authenticated coverage’ı ölçün
• Web application’da role ve route coverage’ını kaydedin
• Container registry ile runtime digest’i karşılaştırın
• Scan error ve unreachable host’ları başarısız sonuç olarak görünür tutun
• Yeni CVE yayımlandığında geçmiş asset inventory’yi yeniden eşleştirin
• Kritik sistemlerde periyodik penetration testing uygulayın

“Finding yok” ile “başarıyla tarandı ve finding yok” aynı durum değildir.

7. Zafiyet yönetimi döngüsü

Kurumsal değer aşağıdaki döngü çalıştığında oluşur:

Varlık keşfi ve scope
        ↓
Tarama ve tespit
        ↓
Validation ve enrichment
        ↓
Risk tabanlı önceliklendirme
        ↓
Owner ve remediation
        ↓
Re-scan ve closure
        ↓
Trend, exception ve tekrar

1. Varlık keşfi

Bilmediğiniz varlığı tarayamazsınız. Domain, subdomain, IP, cloud resource, endpoint, container registry, application, API ve network device envanteri güncel tutulmalıdır.

Her asset için en az:

• Owner
• Business function
• Environment
• Internet exposure
• Data classification
• Criticality
• Technology
• Lifecycle state

bilgisi bulunmalıdır.

2. Tarama ve tespit

Asset türüne uygun scanner, scan profile, viewpoint ve authentication modeli seçilir. Scan error, unreachable asset ve credential failure sonuçtan saklanmaz.

3. Validation ve enrichment

Finding’in gerçekten ilgili asset’te bulunup bulunmadığı değerlendirilir. Sonuca:

• CVSS vector
• EPSS
• CISA KEV
• Public exploit bilgisi
• Exposure
• Asset criticality
• Business impact
• Compensating control
• Finding age

eklenir.

4. Önceliklendirme

Teknik severity, threat ve business context birlikte kullanılarak remediation sırası oluşturulur. Aynı CVE farklı asset’lerde farklı önceliğe sahip olabilir.

5. Owner ve remediation

Finding doğru owner’a atanır. Çözüm yalnızca “patch uygulayın” olmayabilir:

• Patch
• Upgrade
• Configuration change
• Service kapatma
• Network exposure azaltma
• Feature disable
• WAF veya IPS gibi geçici mitigation
• Asset retirement
• Risk acceptance

seçenekleri değerlendirilebilir.

6. Re-scan ve closure

Ticket’ın “Done” olması teknik closure değildir. Scanner veya hedefli validation ile:

• Vulnerability’nin artık gözlenmediği
• Yanlış asset’in patch edilmediği
• Bütün etkilenen instance’ların düzeltildiği
• Compensating control’ün gerçekten çalıştığı
• Regression oluşmadığı

doğrulanmalıdır.

7. Exception ve risk acceptance

Patch uygulanamıyorsa bulgu süresiz biçimde “accepted” olmamalıdır. Exception kaydında:

• Gerekçe
• Risk owner
• Compensating control
• Başlangıç ve bitiş tarihi
• Review periyodu
• Target remediation planı

bulunmalıdır.

Finding lifecycle nasıl görünmeli?

New
  → Under Validation
  → Validated
  → Assigned
  → In Remediation
  → Ready for Re-scan
  → Closed

Alternatif durumlar:
False Positive · Risk Accepted · Mitigated · Cannot Verify · Reopened

“Closed” durumuna yalnızca teknik doğrulama sonrasında geçilmesi, dashboard ile gerçek risk arasındaki farkı azaltır.

8. Önceliklendirme: CVSS, exploitability ve iş etkisi

Binlerce finding bulunan ortamda her şeyi aynı anda düzeltmek mümkün değildir. Fakat yalnızca en yüksek CVSS skorundan başlamak da doğru değildir.

Kullanılabilir bir model şu girdileri bir araya getirir:

Remediation Priority =
f(
  technical severity,
  active exploitation evidence,
  exploitation probability,
  internet exposure,
  asset criticality,
  business impact,
  privilege and interaction requirements,
  compensating controls,
  finding age
)

Bu bir hazır matematik formülü değildir. Kurumun risk appetite ve operation model’ine göre tanımlanması gereken karar çerçevesidir.

CVSS neyi sağlar?

Vulnerability’nin teknik severity’si için ortak dil sağlar. Vector, score’dan daha değerlidir. Attack Vector, Attack Complexity, Privileges Required, User Interaction ve impact metric’leri remediation kararının nedenini açıklar.

EPSS neyi sağlar?

Exploit Prediction Scoring System, belirli bir CVE için önümüzdeki 30 günde exploitation activity görülme olasılığını günlük olarak tahmin eder.

EPSS:

• İş etkisini ölçmez
• Kurumunuza özgü exposure’ı bilmez
• Compensating control’ü değerlendirmez
• Aktif exploitation evidence’ının yerine geçmez

Probability ve percentile birlikte okunmalıdır. EPSS değeri zamanla değişebildiği için rapora yalnızca score değil score date de eklenmelidir.

CISA KEV neyi sağlar?

CISA Known Exploited Vulnerabilities Catalog, aktif exploitation evidence’ı bulunan vulnerability’ler için güçlü bir prioritization signal’idir.

KEV kaydı:

• Kurumunuzun kesin hedef olduğunu göstermez
• İlgili asset’in internete açık olduğunu göstermez
• Business impact’i tek başına belirlemez

Fakat “teorik olarak exploit edilebilir” seviyesinden daha güçlü threat evidence sağlar. Internet-facing ve kritik bir varlıktaki KEV finding’i hızlı aksiyon gerektirir.

Aynı CVSS, farklı risk

İki sistemde aynı CVSS 9.8 vulnerability bulunduğunu düşünelim.

İlk sistem:

• Internet-facing
• Kritik müşteri işlemlerini destekliyor
• Public exploit mevcut
• KEV içinde
• Compensating control yok

İkinci sistem:

• İzole lab network’ünde
• Hassas data içermiyor
• Kullanılmıyor
• Erişim yalnızca sınırlı yönetim segmentinden
• Kısa süre içinde decommission edilecek

Teknik severity aynıdır. Remediation önceliği aynı olmak zorunda değildir.

Tersi de mümkündür. CVSS 7.5 bir finding, aktif exploitation evidence’ı ve kritik external exposure nedeniyle bazı CVSS 9.x findings’ten önce ele alınabilir.

9. Düzenli zafiyet tarama neden gereklidir?

Bir sistemin bugün taranmış olması yarın aynı risk durumunda kalacağını göstermez.

Risk şu nedenlerle değişir:

• Yeni CVE yayımlanır
• Exploit code public hale gelir
• Vulnerability KEV listesine eklenir
• EPSS değeri yükselir
• Yeni subdomain veya cloud resource açılır
• Firewall rule değişir
• Yeni package kurulur
• Eski servis yeniden etkinleştirilir
• Deployment yanlış configuration getirir
• Patch rollback yapılır
• Asset owner veya business criticality değişir

Varlıkta hiçbir değişiklik yapılmasa bile yeni vulnerability bilgisi onu riskli hale getirebilir.

Tek seferlik taramanın zaman sınırı

Tarama raporu, scan engine ve feed’in o tarihte bildiği check’ler ile o anda erişebildiği asset’leri gösterir.

Raporun ertesi günü:

• Yeni bir CVE yayımlanabilir
• Daha önce erişilemeyen host erişilebilir hale gelebilir
• Patch sonrası service yeniden açılabilir
• Cloud deployment yeni public endpoint oluşturabilir

Bu nedenle rapor bir “güvenlik belgesi” değil, timestamp’i olan assessment evidence’ıdır.

Diff analizi neden değerlidir?

Düzenli taramada yalnızca toplam Critical ve High sayısı karşılaştırılmamalıdır.

Finding’ler şu sınıflara ayrılmalıdır:

• New
• Continuing
• Remediated
• Reopened
• Risk accepted
• Scope added
• Scope removed
• Cannot verify

Toplam bulgu sayısının azalması iyi görünebilir. Fakat on kritik asset scope’tan çıkarıldığı için sayı düştüyse gerçek iyileşme yoktur. Diff analizi scope değişimi ile risk değişimini ayırmalıdır.

SECNODEX’in düzenli zafiyet tarama hizmeti, sabitlenen kapsamı dönemsel olarak yeniden değerlendirerek yeni, devam eden ve kapatılan findings arasındaki değişimi görünür hale getirmek üzere konumlandırılmıştır.

Continuous exposure ile periyodik tarama aynı şey mi?

Hayır.

Continuous EASM, internet-facing varlık ve exposure değişikliklerini yüksek sıklıkta keşfetmeye odaklanır.

Periyodik zafiyet tarama, tanımlı asset setini belirli zaman noktalarında benzer profile ile değerlendirerek karşılaştırılabilir baseline üretir.

Hızlı değişen kurumlarda ikisi birlikte kullanılabilir. EASM yeni varlığı bulur, periyodik authenticated scan host içindeki patch ve configuration durumunu derinleştirir.

10. Tarama sıklığı nasıl belirlenir?

Her kurum ve her asset için “ayda bir” kuralı yeterli değildir. Sıklık aşağıdaki değişkenlere göre belirlenmelidir:

• Asset criticality
• Internet exposure
• Değişiklik sıklığı
• Technology lifecycle
• Threat activity
• Data sensitivity
• Patch cadence
• Scanner erişimi
• Operational safety
• Compliance gereksinimi

Varlık türüne göre örnek tarama periyodu

Bu tablo başlangıç modelidir. “Aylık” ifadesi kritik KEV exposure’ı için yavaş, hassas OT cihazında plansız active scan için fazla agresif olabilir.

Event-based tarama ne zaman yapılmalı?

Takvim beklenmeden scan veya targeted assessment başlatılabilecek olaylar:

• Critical vendor advisory
• CISA KEV eklemesi
• Public exploit yayını
• Internet exposure değişikliği
• Büyük deployment
• Operating system veya middleware upgrade
• Firewall ve network architecture değişikliği
• M&A ile yeni varlık devri
• Incident sonrasında benzer exposure araştırması
• Scanner feed’ine kritik check eklenmesi

En iyi program calendar-based ve event-based tetikleyicileri birlikte kullanır.

11. Authenticated tarama neden daha değerli?

Unauthenticated scan dışarıdan görülen davranışı ölçer. Authenticated scan ise sistemin içine kontrollü biçimde bakarak local package, patch ve configuration durumunu değerlendirebilir.

NIST SP 800-115, administrator-level credential kullanan network scanner’ların host üzerinden vulnerability bilgisi çıkarabildiğini, local scanning’in ise network-based scanning’e kıyasla daha yüksek ayrıntı sağlayabildiğini belirtir.

Authenticated scan neyi daha iyi görebilir?

• Installed package ve gerçek version
• Missing security update
• Local privilege ile exploit edilebilen vulnerability
• Registry ve configuration state
• Service yalnızca local interface’te dinlese bile ilgili package
• Disabled fakat kurulu component
• Browser, runtime ve developer tool package’leri
• Security baseline sapmaları
• Local account ve policy durumu

Network banner’ı yalnızca dışarı gösterilen bilgidir. Authenticated check package manager, registry veya system API üzerinden daha doğrudan evidence alabilir.

Authentication başarısı ölçülmeden tarama tamamlanmış sayılmaz

Scanner hedefe network üzerinden ulaştı diye credentialed checks çalışmış olmayabilir.

Rapor şu metrikleri içermelidir:

• In-scope host sayısı
• Ulaşılabilen host sayısı
• Authentication denenen host sayısı
• Başarılı authentication sayısı
• Local checks çalışan host sayısı
• Privilege yetersizliği bulunan host sayısı
• Credential error ve timeout sayısı

Yüz host’un yalnızca yirmisinde authenticated check çalıştıysa rapor “credentialed scan tamamlandı” diye özetlenmemelidir.

Credential güvenliği nasıl sağlanmalı?

• Dedicated scanner account kullanılmalı
• Gereken coverage ile uyumlu en düşük privilege seçilmeli
• Credential vault veya güvenli secret management uygulanmalı
• Password veya key rapora yazılmamalı
• Source IP ve kullanım zamanı sınırlandırılmalı
• Interactive login mümkünse kapatılmalı
• Account activity loglanmalı
• Scan sonrası rotate veya revoke edilmeli
• Third-party scanner storage modeli doğrulanmalı
• Cloud role için kısa ömürlü credential tercih edilmeli

Bazı local checks administrator veya root seviyesinde erişim gerektirebilir. Bu durumda “least privilege” söylemiyle yetersiz account kullanmak yerine risk açıkça yönetilmeli ve account yalnızca scanner işleviyle sınırlandırılmalıdır.

12. Bulut ve konteyner zafiyet taraması

Cloud ve container güvenliğinde en sık yapılan hata, tek bir image scanner sonucunu bütün environment’ın güvenlik görünümü kabul etmektir.

Cloud assessment’ın dört katmanı

1. IaC scanning

Terraform, CloudFormation, Kubernetes manifest veya benzeri tanımlar deployment öncesinde policy ve misconfiguration açısından analiz edilir.

Örnekler:

• Public storage configuration
• Geniş security group rule’u
• Encryption eksikliği
• Public load balancer
• Privileged container tanımı
• Secret’ın code içinde bulunması

IaC scan, deploy edilmiş gerçek environment’ın drift durumunu tek başına göstermez.

2. Control plane configuration

Cloud API üzerinden:

• IAM role ve policy
• Public resource
• Logging
• Encryption
• Network boundary
• Backup
• Key management
• Cross-account trust

değerlendirilir.

Configuration’ın riskini anlamak için effective permission ve resource relationship gerekebilir. Tek tek yanlış ayarlar attack path’i göstermeyebilir.

3. Workload ve image scanning

Virtual machine, container image ve runtime package’leri bilinen CVE’lerle eşleştirilir.

Image scan sonucu şu sorularla zenginleştirilmelidir:

• Vulnerable package gerçekten runtime path’inde kullanılıyor mu?
• Fixed version mevcut mu?
• Image production’da çalışıyor mu?
• Rootless veya sandbox gibi control’ler var mı?
• Workload internetten erişilebilir mi?
• Image immutable mı?
• Eski tag ile yeni digest karışıyor mu?

4. Runtime exposure

Bir vulnerability image içinde bulunsa bile gerçek risk:

• Network exposure
• Runtime privilege
• Mounted secret
• Host access
• Service account permission
• Namespace ve network policy

ile değişir.

NIST SP 800-190, container security risklerini yalnızca image içeriğiyle sınırlamaz. Image, registry, orchestrator, host operating system ve runtime katmanlarının birlikte korunması gerekir.

Base image güncellemek neden yetmeyebilir?

Application dependency’si ayrı package manager üzerinden kurulmuş olabilir. Multi-stage build içinde eski artifact taşınabilir. Image tag aynı kalırken digest değişebilir. Production deployment ise registry’deki güncel image yerine eski digest’i çalıştırıyor olabilir.

Doğrulama zinciri şu şekilde kurulmalıdır:

Source ve lockfile
        ↓
Build artifact
        ↓
Image digest ve SBOM
        ↓
Registry
        ↓
Deployment manifest
        ↓
Production runtime digest

Tarama sonucu bu zincirde hangi artifact’e ait olduğunu belirtmelidir.

13. Uyum çerçevelerinde zafiyet tarama

Zafiyet tarama raporu compliance programı için evidence sağlayabilir. Fakat tek başına sertifika, mevzuat uyumu veya güvenlik garantisi değildir.

ISO/IEC 27001

ISO/IEC 27001:2022, Information Security Management System için risk bazlı yönetim yaklaşımı tanımlar. Annex A içindeki teknik vulnerability yönetimi kontrolü, kullanılan information system’larda bulunan technical vulnerability bilgisine zamanında erişilmesini, exposure’ın değerlendirilmesini ve uygun önlemlerin alınmasını hedefler.

Standart “bütün kurumlar ayda bir scanner çalıştırmalıdır” şeklinde evrensel bir periyot tanımlamaz. Kurum:

• Risk assessment
• Asset criticality
• Threat environment
• Change frequency
• Legal ve contractual requirement

üzerinden süreç ve sıklık belirlemelidir.

Audit evidence olarak yalnızca PDF rapor değil:

• Scope ve asset coverage
• Finding kayıtları
• Risk değerlendirmesi
• Remediation ticket’ları
• Exception onayları
• Re-scan sonuçları
• Program metric’leri

sunulabilmelidir.

PCI DSS

PCI DSS v4.x Requirement 11 kapsamındaki vulnerability scanning beklentileri daha belirgindir.

PCI SSC açıklamalarına göre:

• Internal ve external vulnerability scan’ler en az üç ayda bir yapılmalıdır
• Significant change sonrasında ek tarama gerekir
• İlgili external scan gereksinimleri için PCI SSC tarafından onaylanmış ASV kullanılmalıdır
• Düzeltmeler re-scan ile doğrulanmalıdır

“Çeyreklik” dört takvim çeyreğinde rastgele gün seçmek anlamına gelmez. PCI SSC, taramalar arasında en fazla yaklaşık üç ay veya 90 gün olmasını amaçlar.

ASV scan’in geçmesi bütün PCI DSS gereksinimlerinin karşılandığını göstermez. SECNODEX zafiyet tarama hizmetinin resmi ASV scan yerine geçtiği de varsayılmamalıdır. Kurumun merchant yapısı ve compliance-accepting entity beklentisi ayrıca doğrulanmalıdır.

KVKK

6698 sayılı Kanun’un 12. maddesi kapsamında veri sorumlusu, kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek, muhafazasını sağlamak amacıyla uygun teknik ve idari tedbirleri almakla yükümlüdür. Veri sorumlusu gerekli denetimleri yapmak veya yaptırmak zorundadır.

Kişisel Verileri Koruma Kurumu, alınacak önlemlerin veri sorumlusunun yapısına, faaliyetlerine, risklerine ve korunan kişisel verinin niteliğine uygun olması gerektiğini belirtir. Bu nedenle:

• Tek bir tarama otomatik KVKK uyumu sağlamaz
• Kanun bütün kurumlar için aynı scan frequency’yi belirlemez
• Zafiyet tarama, uygun teknik tedbirlerin ve denetim sürecinin girdilerinden biri olabilir
• Kişisel veri içeren test evidence’ı için data minimization ve güvenli saklama gerekir

Compliance amacıyla yapılan tarama da teknik olarak doğru scope ve remediation süreci gerektirir.

14. Zafiyet tarama araçları ve sınırları

Nessus, Greenbone/OpenVAS ve benzeri scanner isimleri sık anılır. Tool seçimi önemlidir fakat tek başına program kalitesini belirlemez.

Network ve host scanner’ları

Nessus veya Greenbone/OpenVAS gibi çözümler:

• Port ve service discovery
• Known CVE check’leri
• Authenticated local kontroller
• Configuration ve compliance check’leri
• Plugin tabanlı detection

için kullanılabilir.

Farkı yalnızca “hangisi daha çok vulnerability buluyor?” sorusuyla ölçmek doğru değildir.

Değerlendirme kriterleri:

• Feed güncelliği
• Authenticated scanning coverage
• Platform desteği
• Detection evidence kalitesi
• False positive yönetimi
• Safe check seçenekleri
• API ve ticketing integration
• Agent desteği
• Data residency
• Role-based access
• Scan performance ve rate control

olmalıdır.

Web scanner’ları

Web scanner:

• Crawl
• Parameter discovery
• Payload injection
• Response comparison
• Browser automation
• Passive header ve cookie analysis

kullanabilir.

Sınırlar:

• Karmaşık login ve MFA
• CAPTCHA
• Signed request
• Multi-step transaction
• Role ve tenant geçişleri
• Business logic
• Race condition
• Out-of-band callback
• Destructive action safety

alanlarında belirginleşir.

Scanner’ın application’a login olabilmesi, authenticated coverage’ın yeterli olduğu anlamına gelmez. Hangi role, route ve workflow’ların gerçekten ziyaret edildiği ölçülmelidir.

Template tabanlı scanner’lar

Template tabanlı araçlar, belirli bir technology veya CVE için hızlı ve tekrar edilebilir check sağlar. Yeni vulnerability için kısa sürede kuruma özel targeted scan yürütmekte değerlidir.

Riskleri:

• Community template kalitesinin değişken olması
• Güvenli olmayan request veya payload
• Version-only matching
• Kopya bulgular
• Template’in yalnızca belirli deployment biçimini tanıması
• Scope dışı callback veya third-party interaction

Her template production için güvenli kabul edilmemelidir. Source review, rate limit ve controlled rollout gerekir.

Scanner’ın temel sınırları

Hiçbir scanner:

• Envanter dışındaki bütün varlıkları garantiyle bulamaz
• Henüz bilinmeyen 0-Day’i signature olmadan güvenilir biçimde tespit edemez
• Her custom application davranışını anlayamaz
• Her finding’in business impact’ini belirleyemez
• Bütün exploit chain’i insan muhakemesi olmadan kuramaz
• Remediation ownership problemini çözemez
• Risk acceptance kararı veremez

Tool, güvenlik kararını destekler. Kararın kendisi değildir.

Tek scanner mı, birden fazla scanner mı?

İkinci tool farklı detection mantığıyla coverage artırabilir. Fakat sonuçları toplamak şu sorunları doğurabilir:

• Duplicate findings
• Farklı severity
• Farklı asset naming
• Aynı CVE için farklı evidence
• Status senkronizasyonu
• Aynı false positive’in tekrarı

Multi-scanner modelinde normalization ve finding correlation gerekir. Daha fazla tool otomatik olarak daha iyi zafiyet yönetimi anlamına gelmez.

15. Zafiyet tarama raporu nasıl okunmalı?

Yönetim yalnızca toplam Critical sayısına, teknik ekip ise yalnızca plugin output’a bakarsa raporun önemli kısmı kaybolur.

Önce coverage’a bakın

Raporun ilk sorusu “kaç vulnerability bulundu?” değil, “neyi ne ölçüde taradık?” olmalıdır.

Kontrol edilecek alanlar:

• Planlanan asset sayısı
• Tarama tamamlanan asset sayısı
• Unreachable asset
• Authentication success
• Scan error
• Excluded asset
• Scan tarih ve saati
• Scanner konumu
• Feed veya plugin güncelliği
• Scan profile

Coverage düşükse finding sayısı güvenilir başarı göstergesi değildir.

Detection yöntemini okuyun

Finding:

• Banner inference
• Version check
• Authenticated package check
• Active probe
• Configuration read
• Agent inventory

yöntemlerinden hangisine dayanıyor?

Authenticated package evidence ile yalnızca banner tahmini aynı confidence seviyesinde değerlendirilmemelidir.

CVSS vector’a bakın

Yalnızca 9.8 Critical etiketine bakmak yerine:

• Attack Vector
• Attack Complexity
• Privileges Required
• User Interaction
• Subsequent System impact

gibi metric’leri inceleyin.

CVSS version da yazılmalıdır. CVSS v3.1 ve v4.0 score’ları bağlamı bilinmeden doğrudan karşılaştırılmamalıdır.

Risk context’i kontrol edin

İyi raporda:

• Internet exposure
• Asset criticality
• Business owner
• KEV
• EPSS ve score date
• Public exploit
• Data sensitivity
• Compensating control
• Finding age
• Remediation SLA

yer almalıdır.

Remediation gerçekten uygulanabilir mi?

“Upgrade edin” tek başına yeterli değildir.

Remediation:

• Etkilenen component’i
• Minimum fixed version’ı
• Vendor advisory’yi
• Configuration değişikliğini
• Restart veya downtime gereksinimini
• Geçici mitigation’ı
• Validation yöntemini

mümkün olduğunca açık göstermelidir.

Dönem raporunda hangi metric’ler izlenmeli?

• Asset coverage rate
• Authenticated scan success rate
• New finding sayısı
• Remediated finding sayısı
• Reopened finding sayısı
• KEV exposure yaşı
• SLA breach oranı
• Mean ve median remediation time
• Owner’sız asset sayısı
• Süresi dolmuş exception sayısı
• Critical asset üzerindeki open finding trend’i
• Re-scan bekleyen finding sayısı

Toplam finding sayısı tek başına iyi metric değildir. Daha iyi asset discovery yapıldığında sayı artabilir. Bu, security posture’ın kötüleştiğini değil görünürlüğün iyileştiğini gösterebilir.

16. Zafiyet tarama hizmeti seçerken 8 kriter

1. Asset discovery ve scope yaklaşımı

Provider yalnızca gönderilen IP listesini mi tarıyor, yoksa scope içindeki domain, subdomain ve cloud ilişkileri için asset discovery desteği sunuyor mu? Bulunan olası varlıklarda ownership nasıl doğrulanıyor?

2. Authenticated scanning capability’si

Hangi operating system ve platform’larda credentialed check destekleniyor? Account güvenliği nasıl sağlanıyor? Authentication başarı oranı raporlanıyor mu?

3. Scan profile ve production güvenliği

Safe checks, DoS plugin’leri, rate limit, concurrency, maintenance window, stop condition ve emergency contact nasıl yönetiliyor? “Tarama risksizdir” iddiasından kaçınılmalıdır.

4. Validation seviyesi

Hangi severity seviyeleri uzman tarafından inceleniyor? Version-only findings nasıl ayrıştırılıyor? Exploit doğrulaması yapılacaksa scope ve Rules of Engagement açık mı?

Her düşük seviyeli finding’in penetration testing derinliğinde doğrulanması ölçekli bir tarama hizmetinde gerçekçi olmayabilir. Hizmetin validation standardı sözleşmede netleşmelidir.

5. Risk tabanlı önceliklendirme

CVSS dışında EPSS, CISA KEV, internet exposure, asset criticality, business impact ve compensating control kullanılıyor mu? EPSS değerinin tarihi saklanıyor mu?

6. Diff, re-scan ve lifecycle

Yeni, devam eden, kapanan ve yeniden açılan findings ayrılabiliyor mu? Düzeltme sonrası re-scan dahil mi? Risk acceptance ve exception expiry takip ediliyor mu?

7. Rapor ve integration

Executive ve teknik görünüm ayrılıyor mu? API, ticketing, CSV veya dashboard seçenekleri var mı? Raw evidence ve remediation bilgisi kullanılabilir mi?

8. Uzmanlık ve hizmet sınırları

Provider zafiyet tarama ile sızma testini doğru ayırıyor mu? Web, API, cloud veya internal network alanında deeper assessment gerektiğinde doğru hizmete yönlendirebiliyor mu?

SECNODEX’te zafiyet tarama çıktıları tek başına finding sayısı olarak ele alınmaz. Scope, coverage, validation ihtiyacı ve risk context’i birlikte değerlendirilir. OSCP ve OSWE sertifikalı uzmanların network ve application security deneyimi, kritik bulguların hangi noktada deeper validation veya sızma testi hizmetine taşınması gerektiğinin belirlenmesine katkı sağlar.

18. Sonuç: Tarama bir anı gösterir, zafiyet yönetimi riski azaltır

Zafiyet taramanın güçlü olduğu alan açıktır:

• Geniş asset setinde tekrar edilebilir kontrol
• Known CVE ve missing patch görünürlüğü
• Configuration sapmalarının tespiti
• Düzenli diff ve trend analizi
• Yeni vulnerability bilgisinin mevcut envanterle eşleştirilmesi
• Remediation backlog’unun beslenmesi

Sınırı da aynı ölçüde açıktır:

• Scope dışında kalan varlığı değerlendiremez
• Her finding’i doğrulanmış risk haline getirmez
• Business logic’i ve kuruma özgü attack path’i tam olarak anlayamaz
• Risk sırasını yalnızca CVSS ile doğru kuramaz
• Ticket kapanışını teknik remediation olarak kabul edemez

Bu nedenle doğru denklem “scanner mı, pentest mi?” değildir.

Kurumun:

1. 1Attack surface’i sürekli keşfetmesi
2. 2Varlık türüne uygun taramayı doğru sıklıkta çalıştırması
3. 3Coverage ve authentication başarısını ölçmesi
4. 4Findings’i CVSS, EPSS, KEV ve iş bağlamıyla önceliklendirmesi
5. 5Remediation’ı owner ve SLA ile yönetmesi
6. 6Kapanışı re-scan ile doğrulaması
7. 7Kritik alanları dönemsel sızma testiyle derinleştirmesi

gerekir.

SECNODEX’in Zafiyet Tarama ve Attack Surface Management hizmeti, internet-facing varlıkların keşfi ve exposure değişikliklerinin izlenmesine odaklanır. Düzenli Zafiyet Tarama hizmeti ise tanımlı kapsamın periyodik scan, diff analizi ve re-scan süreciyle takip edilmesini sağlar.

Kurumunuz için asset türlerine, değişiklik hızına ve risk seviyesine uygun bir vulnerability scanning programı oluşturmak için SECNODEX ile iletişime geçebilirsiniz.

Kaynaklar ve ileri okuma

• NIST — Vulnerability Scanning tanımı
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
• NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning
• NIST SP 800-190 — Application Container Security Guide
• FIRST — CVSS v4.0 Specification
• FIRST — CVSS v4.0 User Guide
• FIRST — Exploit Prediction Scoring System
• CISA — Known Exploited Vulnerabilities Catalog
• PCI SSC — Vulnerability scan periyotları hakkında FAQ
• PCI SSC — Approved Scanning Vendors
• ISO — ISO/IEC 27001:2022
• Kişisel Verileri Koruma Kurumu — Veri Güvenliğine İlişkin Yükümlülükler

<!--

EDİTORYAL INTERNAL LINK NOTU

Bu pillar için önerilen yeni cluster içerikleri:

1. 1CVSS Nasıl Yorumlanır? Severity, Risk, EPSS ve KEV Farkı

Önerilen slug: /blog/cvss-nasil-yorumlanir

Pillar bağlantı noktası: 5. ve 8. bölümler

1. 1Authenticated ve Unauthenticated Zafiyet Tarama Arasındaki Fark

Önerilen slug: /blog/authenticated-vs-unauthenticated-zafiyet-tarama

Pillar bağlantı noktası: 3. ve 11. bölümler

1. 1Zafiyet Yönetimi Döngüsü Nasıl Kurulur?

Önerilen slug: /blog/zafiyet-yonetimi-dongusu

Pillar bağlantı noktası: 7. ve 9. bölümler

Cluster içerikleri yayımlandığında yukarıdaki bölümlere doğal internal link eklenmeli.

Her cluster yazısından bu pillar sayfasına açıklayıcı anchor text ile geri bağlantı kurulmalı.

-->