CWE Kavramı ve Yazılım Zafiyetlerinin Sınıflandırılması
CWE nedir sorusu, yazılım güvenlik raporlarını standartlaştırmak isteyen herkesin ilk adımıdır. Güvenlik uzmanları genellikle “SQL enjeksiyonu” veya “yetkisiz erişim” gibi bulgular raporlar. Aslında bu ifadelerin arkasında ortak bir dille adlandırılan kök nedenler yatar. Farklı ekipler aynı zafiyeti tamamen bağımsız isimlerle tarif edebilir. Bu durum, bulguları karşılaştırmayı ve önceliklendirmeyi ciddi anlamda zorlaştırır. Dolayısıyla standart bir dile mutlaka ihtiyaç duyarız. CWE (Common Weakness Enumeration), tam olarak bu karmaşayı ortadan kaldırır. Zafiyet türlerini ortak bir kimlik numarasıyla tanımlayan kapsamlı bir sözlüktür.
Sibertim uzmanları, sızma testi ve kod analizi raporlarında her bulguyu bir CWE numarasıyla eşleştirir. Sonuç olarak bir bulgu “bize göre riskli” olmaktan çıkar. Uluslararası kabul gören bir taksonomi içinde tanımlanmış ve tekrarlanabilir bir kategoriye ait olur.
Sistem, yazılım ve donanımdaki zafiyet türlerini ortak bir kimlik numarasıyla tanımlar. MITRE kurumunun yürüttüğü bu yapı, dört farklı seviyeden oluşan bir hiyerarşiye sahiptir. Ayrıca CISA’nın yıllık yayımladığı CWE Top 25 listesi, en kritik zafiyet türlerini hızla önceliklendirmenizi sağlar.
CWE Kavramı ve Güvenlikteki Önemi
CWE (Common Weakness Enumeration), yazılım ve donanım zafiyet türlerini detaylıca kategorize eder. MITRE kurumu bu sistemi topluluk katkısıyla sürekli genişletir ve yönetir. Detaylı bilgiye MITRE resmi web sitesi üzerinden ulaşabilirsiniz. Bu sistem, spesifik bir zafiyeti değil, arkasındaki genel hata türünü tanımlar. Örneğin CWE-79, belirli bir sitedeki XSS açığını doğrudan ifade etmez. Bunun yerine, “kullanıcı girdisinin hatalı temizlenmesi” kök nedenini açıklar. Uzmanlar her kayda, tanıma, örneklere ve azaltım önerilerine benzersiz bir kimlik numarasıyla (CWE-XX) kolayca erişir.
Bir zafiyeti yalnızca “kritik” diye etiketlemek, hatanın kod içindeki kaynağını asla açıklamaz. Oysa aynı kök nedenin başka noktalarda tekrar edip etmediğini anlamalısınız. Bunun için öncelikle o kök nedeni doğru adlandırmanız gerekir. Ek olarak, CISA her yıl güncel bir CWE Top 25 listesi yayımlar. Bu liste, gerçek CVE kayıtlarından yola çıkarak en tehlikeli zafiyet türlerini gösterir. Böylece kurumlar sınırlı güvenlik bütçelerini nereye harcayacaklarına çok daha rahat karar verir.
CWE Sınıflandırmasının Kullanım Alanları
Yazılım geliştiriciler, kod incelemesi sırasında hangi hata kalıplarından kaçınmaları gerektiğini bu tanımlarla öğrenir. Güvenlik test uzmanları ise sızma testindeki bulguları ilgili kimlikle raporlar. Böylece bulguyu sektörün ortak diline bağlamış olurlar. Ayrıca ürün güvenliği ekipleri, tedarik zincirindeki bileşen risklerini bu sistem üzerinden takip eder. Öte yandan, CVE Numaralandırma Otoriteleri (CNA) yeni kayıtları yayımlarken kök nedeni belirlemek zorundadır. Bu otoriteler, her kaydı en az bir CWE ile titizlikle eşleştirir. Bu sayede veritabanı, kök neden bazında analiz edilebilir güçlü bir veri kümesi hâline gelir.
CWE Çalışma Süreci ve Hiyerarşisi
Sistem tek bir düz listeden oluşmaz. Katmanlı ve yapılandırılmış bir hiyerarşi olarak çalışır. Uzmanlar bir zafiyetin detayını bu hiyerarşideki seviyelere göre belirler:
| Seviye | Açıklama |
|---|---|
| Pillar (Sütun) | En soyut seviyedir. “Yetersiz Yetkilendirme” gibi geniş bir hata tipini tanımlar. Doğrudan bir bulguyla eşleştirmeyiz. |
| Class (Sınıf) | Pillar’dan daha spesifiktir. Hâlâ programlama dilinden veya platformdan bağımsız bir hata kategorisini anlatır. |
| Base (Temel) | Bulguları çoğunlukla bu seviyede eşleştiririz. CWE-79 (XSS) veya CWE-89 (SQL Injection) gibi somut hata türlerini tanımlar. |
| Variant (Varyant) | Base seviyesinin belirli bir teknoloji veya dildeki özel görünümüdür. En dar ve teknik detay seviyesidir. |
Bu hiyerarşinin yanı sıra sistem, farklı ihtiyaçlara göre özel görünümler (views) sunar. Örneğin CWE-1000, araştırma amaçlı tam hiyerarşiyi gösterir. CWE-699 ise geliştiriciler için pratik bir gruplandırma sağlar. Ayrıca CWE-1400, donanım tasarımına özgü zafiyetleri kapsar. CISA’nın yayımladığı CWE Top 25, bu geniş veritabanından süzülen bir özet listedir. En kritik 25 zafiyet türünü net bir şekilde öne çıkarır.
Adım Adım Eşleştirme Süreci
Bulgunun Tespiti
Uzmanlarımız kod incelemesi veya manuel sızma testi sırasında bir zafiyet belirtisi tespit eder.
Kök Nedenin Belirlenmesi
Bulgunun teknik kök nedenini detaylıca analiz ederiz. Ardından bunu en uygun CWE kimliğiyle (tercihen Base seviyesinde) eşleştiririz.
Önceliklendirme ve Raporlama
Eşleştirdiğimiz veriyi CVSS puanı ve Top 25 konumuyla birlikte değerlendiririz. Sonunda geliştirme ekibine önceliklendirilmiş net bir rapor sunarız.
CWE, CVE ve OWASP Top 10 Karşılaştırması
Sektörde bu üç kavram sık sık birbirine karıştırılır. Oysa her biri tamamen farklı bir katmanı temsil eder. CWE bir hata türünü netleştirir. CVE o hata türünün gerçek bir üründeki somut örneğini gösterir. OWASP Top 10 ise web uygulamalarındaki en yaygın risk kategorilerini pratik bir şekilde özetler.
| Kavram | Ne Tanımlar? | Kim Yönetir? |
|---|---|---|
| CWE | Zafiyetin genel kök neden türünü tanımlar. | MITRE |
| CVE | Belirli bir üründeki somut, tekil zafiyet kaydını tutar. | MITRE / CNA topluluğu |
| OWASP Top 10 | Web uygulamalarındaki en yaygın riskleri listeler. | OWASP topluluğu |
Kullanılan Standartlar ve Yaklaşımlar
Bu standart, diğer güvenlik çerçeveleriyle birlikte kullanıldığında asıl değerini kazanır. Örneğin NVD (Ulusal Zafiyet Veritabanı), yayımlanan her CVE kaydına ilgili kimliği ekler. Böylece zafiyetleri kök neden bazında kolayca arayabilirsiniz. CVSS bir zafiyetin teknik şiddetini puanlarken, CWE onun hata ailesini gösterir. Buna ek olarak MITRE ATT&CK, saldırganların bu türleri hangi taktiklerle istismar ettiğini kataloglar. Sonuç olarak teorik tanımları gerçek saldırı senaryolarıyla birleştirir. Sibertim olarak biz, değerlendirmelerimizde bu kaynakları her zaman entegre kullanırız. Bulguları öznel yorumlardan çıkarıp tamamen denetlenebilir bir referansa bağlarız.
Kullanılan Araçlar ve Teknikler
Statik kod analizi (SAST) araçları kaynak kodu derinlemesine tarar. Tespit ettikleri her bulguyu doğrudan ilgili kimlikle etiketler. Dinamik uygulama güvenlik testi (DAST) araçları ise çalışan uygulamayı dışarıdan test eder. Bulduğu zafiyetleri yine bu referanslarla hızlıca raporlar. Fakat otomatik araçların ürettiği eşleştirmeler bazen çok genel veya hatalı çıkabilir. Bu noktada uzmanlarımız bulguyu manuel olarak dikkatlice inceler. Ardından doğru seviyeye yeniden eşleştirir. Bu adım raporun teknik doğruluğu için kesinlikle kritiktir.
Manuel ve Otomatik Yaklaşımların Karşılaştırması
Otomatik tarayıcılar, bilinen kalıplara uyan zafiyetleri hızlıca eşleştirir. Ancak iş mantığı hatalarının karşılığını bulmak çoğu zaman insan analizini gerektirir. Çünkü aynı belirti birden fazla farklı kök nedenden kaynaklanabilir. Sibertim, otomatik araçların hızını manuel doğrulamanın hassasiyetiyle harmanlar. Böylece her bulguyu doğru seviyede ve gerçek risk bağlamında raporlarız.
Gerçek Hayat Senaryosu
Bir lojistik firmasının iç portalında yetkilendirme testi gerçekleştirdik. Kullanıcıların yalnızca kendi taleplerini görüntüleyebildiği varsayılıyordu. Değerlendirme sırasında, talep numarasını URL üzerinden değiştirerek başka kullanıcılara eriştik. Uzmanlarımız bu bulguyu CWE-639 (Kullanıcı Kontrollü Anahtar Üzerinden Yetki Aşımı) ile eşleştirdi. Bu işlem sayesinde geliştirme ekibi sorunun sadece o ekranla sınırlı kalmadığını gördü. Aynı erişim kontrolü desenini kullanan tüm modülleri hızla gözden geçirdiler.
Düzenli Takip Gereksinimi
İlgili listeler asla sabit kalmaz. Topluluk, her yıl güncel CVE verileriyle tehlike puanlarını yeniden hesaplar. Yeni öne çıkan zafiyet türlerini listeye hemen yansıtır. Geçmişte standartlara uygun bir test yaptırmış olmanız, bugünkü riskleri kesinlikle garanti etmez. Uygulamanız büyüdükçe ve yeni bağımlılıklar eklendikçe öne çıkan risk kategorileri de değişir. Bu nedenle testleri mutlaka düzenli periyotlarla tekrarlamalısınız.
Süreçte Karşılaşılan Temel Hatalar
Sektörde en sık görülen hata, bulguları çok genel (Pillar veya Class) bir seviyeyle eşleştirmektir. Bu durum raporun teknik değerini ciddi oranda düşürür. Çünkü geliştirici hatanın gerçek kaynağını tam olarak göremez. Bir diğer hata ise otomatik araçların önerilerini hiç sorgulamadan kabul etmektir. Ayrıca benzer kategorideki bulguları tek tek ele alıp büyük resmi kaçırmak da devasa bir eksikliktir. Aynı hatanın sürekli tekrar etmesi, genellikle kod tabanında sistemik bir tasarım sorununa işaret eder. Zafiyeti sadece kapatmakla, kök nedenini adlandırıp sistemi onarmak arasında büyük bir kalite farkı vardır.
Sibertim İle Harekete Geçin
Uygulamanızdaki zafiyetlerin hangi kök nedenlerden kaynaklandığını tahmin etmek büyük bir risktir. Bunun yerine standartlara uygun bir sızma testiyle durumu net biçimde görmek isterseniz Sibertim ekibiyle iletişime geçebilirsiniz. Kapsamı birlikte belirleyip hangi kategorilerden başlamanın mantıklı olduğunu anında netleştiririz.
Sık Sorulan Sorular
CWE bir zafiyet mi, bir zafiyet türü mü?
Sistem tekil bir zafiyet olayını değil, o olayın arkasındaki genel hata kalıbını tanımlar. Bu nedenle net olarak bir zafiyet türüdür. Somut ve spesifik olayları ise her zaman CVE kimlikleriyle kayıt altına alırız.
CWE Top 25 listesine nasıl girilir?
Top 25 listesi, o yıl yayımlanan CVE kayıtlarının kök nedenleri analiz edilerek hazırlanır. Her CWE’nin görülme sıklığı ve ortalama CVSS şiddeti üzerinden hesaplanan özel bir tehlike puanıyla sıralama belirlenir.
Küçük ölçekli bir yazılım projesinin bu yapıya ihtiyacı var mı?
Eşleştirme işlemi işletme ölçeğinden tamamen bağımsızdır. Küçük projelerde dahi bulunan her hatanın kök nedenini netleştirir. Benzer hataların kod tabanının başka yerlerinde tekrar edip etmediğini hızlıca sorgulamanızı sağlar.
CWE ile CVSS arasındaki temel fark nedir?
CVSS bir zafiyetin teknik şiddetini sayısal olarak puanlar. CWE ise o zafiyetin hangi hata ailesine ait olduğunu net bir şekilde tanımlar. İkisi birbirini kusursuzca tamamlar, birbirinin yerine asla geçmez.
Eşleştirme her zaman Base seviyesinde mi yapılmalıdır?
Eşleştirmeleri mümkün olduğunca Base seviyesinde yapmanızı şiddetle öneririz. Çünkü Base seviyesi en somut ve aksiyona dönüştürülebilir bilgiyi taşır. Ancak bu seviyede yeterli detay yoksa Variant seviyesine ineriz, durum çok genel kaldığında ise Class seviyesine çıkarız.
Sibertim değerlendirmelerinde süreci nasıl yönetiyor?
Değerlendirme sırasında tespit ettiğimiz her bulguyu ilgili kimlikle eşleştiririz. Böylece size sunduğumuz rapor yalnızca bir gözlem listesi olmaz. Sektörün ortak diline dayanan, önceliklendirilmiş ve tekrarlanabilir bir aksiyon planına dönüşür.