CVE Raporlama Rehberi: Güvenlik Zafiyeti Nasıl Yayınlanır?

CVE raporlama süreci, siber güvenlik uzmanları için hem teknik bir zorunluluk hem de kurumsal itibar yönetiminin kritik bir parçasıdır. Bu kapsamlı rehber, kendi yazılım çözümlerinizde keşfettiğiniz güvenlik açıklarını uluslararası standartlara uygun olarak nasıl yayınlayacağınızı adım adım açıklamaktadır.

CVE Raporlama Süreci Temelleri

Yazılım yayıncıları olarak geliştirdiğiniz çözümlerin güvenliği tamamen sizin sorumluluğunuzdadır. Bu sorumluluk, sadece güvenli kod geliştirmek veya düzenli güvenlik testleri yapmakla sınırlı değildir. Keşfedilen bir güvenlik açığını kamuoyuna açıklama kararı, kurumsal etiğinizin ve profesyonelliğinizin bir göstergesidir.

CVE (Common Vulnerabilities and Exposures) sistemi, 1999 yılında MITRE Corporation tarafından kurulan ve ABD İç Güvenlik Bakanlığı ile Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA) tarafından desteklenen uluslararası bir standarttır. Bu sistem, her güvenlik açığına benzersiz bir tanımlayıcı (CVE ID) atayarak, organizasyonların açıkları izlemesini, önleyici veya düzeltici önlemler uygulamasını ve genel olarak güvenlik açığı yönetimini basitleştirmesini sağlar.

CVE yayınlama sürecinin temelinde şu üç temel ilke yatar:

• Şeffaflık: Güvenlik açıklarının kamuoyuyla dürüstçe paylaşılması.
• Müşteri Güveni: Proaktif açıklama politikasıyla güvenilir iş ortağı konumunu pekiştirme.
• Regülasyon Uyumu: Yasal ve sektörel yükümlülüklerin eksiksiz karşılanması.

Bir güvenlik açığını gizlemek veya görmezden gelmek, kısa vadede itibar kaybına, uzun vadede ise hukuki sorumluluklara ve ciddi güvenlik ihlallerine yol açabilir. Aksine, proaktif bir açıklama politikası müşterilerinizin güvenini pekiştirir ve sizi sektörde güvenilir bir iş ortağı olarak konumlandırır.

CVE Raporlama Süreci İçin Hazırlık

Her yazılım hatası veya performans sorunu CVE olarak yayınlanmaz. CVE tanımlayıcıları yalnızca belirli kriterleri karşılayan güvenlik açıklarına atanır. CVE yayınlama sürecine başlamadan önce, açığınızın şu temel koşulları karşıladığından emin olmalısınız:

• Bağımsız Düzeltilebilirlik: Güvenlik açığı, diğer herhangi bir açıktan bağımsız olarak düzeltilebilmelidir. Eğer bir açık, başka bir güvenlik açığının çözülmesine bağlıysa, bunlar tek bir CVE olarak değerlendirilmelidir.
• Güvenlik İhlali: Açık, ürününüzün güvenliğinde önemli bir azalmaya neden olmalıdır. Bu; veri ihlali, yetkisiz erişim, hizmet reddi saldırıları veya ayrıcalık yükseltme gibi somut güvenlik risklerini içerebilir.
• Açık Kaynak veya Kamuya Açık Ürün: CVE’ler yalnızca kamuya açık veya kullanıcılara sunulan yazılımlar için atanır. Dahili kullanım için geliştirilen ve hiçbir zaman kamuya açık olmayan ürünler için CVE atanmamalıdır.
• Çalışma Çevresi (Workaround) Yokluğu: Etkili bir geçici çözüm bulunmaması, açığın ciddiyetini artırır ve CVE atanmasını gerektirir.

CVE Raporlama Sürecinde Doğru Otorite

CNA (CVE Numbering Authority), CVE tanımlayıcıları atamakla yetkili kuruluşlardır. CVE yayınlama sürecinin en kritik adımı, kapsamınıza uygun, doğru CNA’yı seçmektir. CNA’lar, MITRE Corporation tarafından koordine edilen ve çeşitli türlerde faaliyet gösteren otoritelerdir.

CNA Türleri ve Kapsamları

• Vendor CNA’lar: Kendi ürünlerindeki güvenlik açıklarına CVE atayan organizasyonlardır (örneğin Apple, Adobe, Oracle).
• Researcher CNA’lar: Güvenlik açıkları keşfeden ve sorumlu açıklama kapsamında CVE atayan güvenlik firmaları veya bireyler (örneğin Trend Micro ZDI, Cisco Talos).
• Coordinator CNA’lar: Çoklu satıcıları veya kritik altyapıyı etkileyen güvenlik açıkları için CVE atayan, genellikle CERT’ler veya hükümet kurumlarıdır (örneğin JPCERT/CC, CISA).
• Open Source CNA’lar: GitHub Security Lab veya Apache Foundation gibi açık kaynak ekosistemlerinden sorumlu otoriteler.

Doğru CNA’yı seçerken şu kriterlere dikkat etmelisiniz:

• Coğrafi Kapsam: Bölgenizde faaliyet gösteren bir CNA
• Raporlama Yetkisi: Kendi açığınızı kendinizin bildirebileceğiniz bir CNA
• Ürün Bağımsızlığı: Belirli bir ürün veya markayla sınırlı olmayan bir CNA

Kapsamınıza uygun bir CNA bulamazsanız, MITRE List of Partners sayfasına başvurabilirsiniz.

CVE Raporlama Süreci

Adım 1: Güvenlik Açığı Değerlendirmesi ve Dokümantasyon

CVE yayınlama sürecine başlamadan önce, keşfedilen güvenlik açığını detaylı bir şekilde analiz etmelisiniz. Bu analiz şu bilgileri içermelidir:

• Ürün Detayları: Çözümünüzün türü, adı, etkilenen sürümler
• Açık Nedeni: Güvenlik açığının teknik kökeni (örneğin buffer overflow, SQL injection, XSS)
• Güvenlik Etkisi: Açığın ürününüzün güvenliği üzerindeki etkisi
• Saldırı Senaryoları: Yama uygulanmadığı takdirde gerçekleşebilecek saldırı türleri
• Teknik Referans: Açık hakkındaki tüm bilgilerin özetlendiği bir bağlantı veya kamuya açık referans

CNA’lara başvururken bu bilgilerin eksiksiz sunulması zorunludur. Aksi takdirde, güvenlik açığınız yayınlanmayabilir.

Adım 2: CNA Başvurusu ve Öncelikli Reddetme Kuralı

CVE ataması “öncelikli reddetme” (right of first refusal) modelini takip eder. Bu, en uygun kapsama sahip CNA’nın önce iletişime geçilmesi ve ilk atama fırsatının verilmesi gerektiği anlamına gelir. Çoğu durumda bu CNA, sorunlu ürünün tedarikçisidir.

Eğer ilgili CNA önceden atama yapmayacağını beyan etmişse, 72 saat içinde atama yapmayacağını bildirmişse veya 72 saat içinde hiç yanıt vermemişse; uygun bir Root CNA güvenlik açığı değerlendirmesi yapmalı ve gerekirse CNA-LR veya uygun kapsama sahip başka bir CNA’ya en geç 72 saat içinde yönlendirme yapmalıdır.

Adım 3: CVE Tanımlayıcı Durumları ve Yayınlama

CNA’ya başvurduğunuzda yetkili kuruluş bir CVE tanımlayıcı atar. Ancak bu tanımlayıcı hemen yayınlanmaz. CVE yayınlama sürecinde şu durumlar söz konusudur:

• Atandı (Assigned): CNA tarafından CVE numarası verildi ancak tüm bilgiler henüz sağlanmadı.
• Rezerve Edildi (Reserved): CNA tarafından tutulan ancak detayları henüz kamuya açıklanmamış tanımlayıcı.
• Reddedildi (Rejected): Güvenlik açığı doğrulanmadığında veya CNA’nın kapsamına girmeyen bir ürünle ilgili olduğunda, CVE tanımlayıcı reddedilebilir.
• Yayınlandı (Published): CNA bilgileri doğruladığında ve güvenlik açığı kapsamına girdiğinde, CVE tanımlayıcı yayınlanır ve “Published” olarak sınıflandırılır.

Yayınlandıktan sonra, bazı bilgilerin revize edilmesi gerekiyorsa, ilgili CNA’ya başvurarak güvenlik açığıyla ilgili bilgileri güncelleme talebinde bulunabilirsiniz.

CVE Raporlama Sürecinde Regülasyon ve Uyum

CVE yayınlama süreci, yalnızca teknik bir prosedür değil, aynı zamanda yasal ve regülasyonel yükümlülüklerin bir parçasıdır. Kişisel verilerin korunması ve siber güvenlik referans standartlarına uyum konusundaki yükümlülükleriniz her zaman göz önünde bulundurulmalıdır.

Güvenlik açığı yönetim prosedürünüz kapsamında log kayıtlarının ve diğer belgelerin tutulması, ayrıca CNA ile iletişimlerinizin geçmişinin saklanması; hem iç denetimler hem de regülasyon denetimleri için kritik öneme sahiptir.

CNA kuralları, CNA’ların çeşitli topluluklardan gelen farklı taleplere uygun zaman çerçevelerinde yanıt vermesini sağlamak için yanıt verme metrikleri belirler. Bu metrikler, CNA’ların CVE Programı standartlarına uygun hareket ettiğini doğrulamak için kullanılır ve üç ayda bir üst seviye CNA’ya raporlanır.