Sahte CVE’ler, Yapay Zekâyla Oluşturulan Raporlar ve Doğrulama Gerekliliği

İkna edici güvenlik açığı raporları oluşturmak giderek ucuzluyor; bu da yazılımı sürdürenler ve güvenlik ekipleri açısından sonuçları ağırlaştırıyor. Temmuz 2026’da SQLite için altı Yaygın Güvenlik Açığı ve Maruziyeti (CVE) kaydı yayımlandı; bunlardan ikisine 9,8 önem derecesi verildi. Raporlar meşru görünüyordu; bellek güvenliği hatalarını açıklıyor, teknik izahlar ve kavram kanıtlama kodları içeriyordu.

Ancak JFrog araştırmacıları, bu raporlarda atıfta bulunulan bazı işlevlerin etkilenen sürümlerde yer almadığını ortaya çıkardı. Üstelik kavram kanıtlarının (PoC’lerin) hiçbiri iddia edilen güvenlik açıklarını yeniden oluşturamadı. SQLite’ın kendi CVE sayfasında şu anda bu altı raporun hata olmadığı belirtiliyor; CVE kayıtları daha sonra reddedildi.

Sorun SQLite’la sınırlı değil. curl’ün bakımını yapan Daniel Stenberg, geçen yıl gelen güvenlik raporlarının yaklaşık %20’sinin yapay zekâ çöplüğü olduğunu tahmin etti. GitHub’ın CVE Numaralandırma Yetkilisi (CNA), Mayıs 2026’da yaklaşık 4.000 CVE başvurusu aldı; bu, yıllık bazda başvuru hacminin yaklaşık 10 katına çıkması demek. GitHub bu artışı yapay zekâya bağlamadı veya başvuruların kalitesinde düşüş olduğuna işaret etmedi; ancak hacimdeki büyük artış, güvenlik açıklarını bildirme sürecinin üzerindeki baskıyı gözler önüne seriyor.

Yapay zekâ, ayrıntılı güvenlik açığı iddiaları oluşturmayı kolaylaştırıyor; bu iddiaların meşru olup olmadığını belirlemek ise zaman alıyor. Ayrıca bir CVE güvenlik akışlarına ve kamuya açık veritabanlarına girdikten sonra, ilk kaydın düzeltilmesi her kopyanın da otomatik olarak düzeltileceği anlamına gelmiyor. Bu durum, bildirilen bir güvenlik açığıyla teknik olarak doğrulanmış bir güvenlik açığını birbirinden ayırt etme ihtiyacını giderek artırıyor.

“Sahte” CVE nedir?

İnsanlar, muhtemelen yanlış bildirilmiş bir CVE’yi anlatmak için “sahte CVE” terimini sıkça kullanıyor. Ancak sahte olması, kasıtlı olarak yanıltıcı olduğu anlamına gelmiyor. Bu durum, bir doğrulama kontrolünü gözden kaçıran statik analizden veya girdiyi saldırganın kontrolünde sanan yanlış bir yorumdan kaynaklanabilir. Bir rapor gerçek bir işlevi ayrıntılı biçimde açıklarken geçersiz bir saldırı yolu öne sürebilir. Bildirilen koşul gerçekte bir güvenlik açığı değilse bir tanımlayıcı (CVE kimliği) atanabilir ve daha sonra iptal edilebilir. Bu, kasıtlı olarak uydurulmuş bir rapordan farklıdır.

Bir anlaşmazlık da sahte CVE anlamına gelmez. Bir tedarikçi; istismar edilebilirlik, tehdit sınırları veya bir işlevin güvenilmeyen girdileri işlemek üzere tasarlanıp tasarlanmadığı konusunda araştırmacının bulgularına itiraz edebilir. Ancak itiraz edilmesi, araştırmacının hata yaptığının kanıtı değildir. Bir CVE’nin reddedilmesi de mutlaka uydurma olduğu anlamına gelmez; kayıt, yinelenen bir bildirim olduğu veya idari nedenler yüzünden reddedilmiş olabilir. Bir CVE tanımlayıcısı bağımsız bir teknik doğrulama niteliği taşımasa da sektörün gerçek raporları ciddiye alması gerekir.

Sahte CVE’ler neden sorun yaratıyor?

Karşılaştığımız sorunlardan biri, insanların bulguları gerektiği gibi doğrulamadan güvenlik açığı raporları oluşturmak için yapay zekâ kullanması. Bu raporlar ayrıntılı teknik açıklamalar, kod referansları ve hatta PoC’ler içerebilir; bu da onları meşru gösterebilir. Ancak SQLite CVE’lerinde gördüğümüz gibi, atıfta bulunulan bazı işlevler etkilenen sürümlerde hiç yoktu.

GitHub, 2026’da güvenlik açığı bildirimlerinde önemli bir artış olduğunu bildirdi; ancak bu artışı yapay zekâya bağlamadı veya başvuru kalitesinde düşüş olduğunu belirtmedi. Endişe şu: Rapor sayısı arttıkça, bulgular gerçek olsun ya da olmasın, bunları incelemek için gereken iş miktarı da artıyor.

Güvenlik açığı raporlarını önceliklendirip incelemiş olanlar, işin pratikte ne kadar zor olduğunu kolayca anlayabilir. Bir yapay zekâ modeli şüpheli bir API çağrısını belirleyebilir, olası bir istismar senaryosunun kaba taslağını çıkarabilir ve profesyonel görünen bir raporu hızla oluşturabilir. Senaryonun uygulanabilir olup olmadığını belirlemek için tam sürümü kontrol etmek, kontrol akışını izlemek, verilerin işleve nasıl ulaştığını öğrenmek, bir test ortamı kurmak ve iddia edilen istismarı çalıştırmak gerekebilir. Rapor doğru olsun ya da olmasın aynı süreç izlenir ve bu süreç pahalıya mal olabilir.

Sahte CVE’ler itibar kaybına da yol açabilir. Bir güvenlik açığı duyurusu tarayıcı akışlarında, güvenlik veritabanlarında ve arama sonuçlarında hızla yayılabilir. Ancak sonrasında yapılan düzeltme aynı ölçüde yayılmayabilir. Bir rapora itiraz edilmiş veya rapor reddedilmiş olsa bile, ilk raporu gören müşteriler karşısında kendilerini savunmak zorunda kalanlar tedarikçiler olabilir.

Ekiplerin yanlış raporları incelemek için zaman harcaması, gerçek güvenlik açıklarının gözden kaçırılması veya incelenmesinin gecikmesi riskini de beraberinde getiriyor. Yazılımı sürdürenlerin ve güvenlik ekiplerinin kaynakları kısıtlı olduğunda, hatalı bir pozitif bulguyu çürütmek için harcanan her saat, gerçek bir güvenlik sorununu araştırmaya ayrılabilecek zamandan eksiliyor.

Otomasyonla mücadele

Pek çok araştırmacı, yeni rapor selini ele almak için hâlâ manuel önceliklendirme ve inceleme yöntemlerini kullanıyor; ancak bu sürdürülebilir değil. Otomasyon, bir güvenlik açığı iddiasını gerçekten etkilenen sürüm ve yapılandırma üzerinden doğrulamaya büyük katkı sağlıyor. Sorulması gereken beş soru şunlar:

• Yapılandırma ve izinler de dâhil olmak üzere saldırı için gereken ön koşullar gerçekçi mi?
• İddiaya konu olan işlev etkilenen sürümde mevcut mu?
• Saldırgan savunmasız koda ulaşabilir mi? İlgili kodun etkilenen koşullarda çalıştırılıp çalıştırılamayacağını ve saldırganın bu koda ulaşan bir girdi sağlayıp sağlayamayacağını belirleyin.
• Test uzmanları davranışı kontrollü bir testte veya bir PoC ile yeniden üretebilir mi?
• Gözlemlenen davranış, güvenlik uyarısında açıklanan güvenlik etkisini gösteriyor mu?

Ajan tabanlı araçlar test ortamları oluşturabilir, kod yollarını analiz edebilir, PoC’ler üretebilir ve incelenmek üzere çalıştırma kanıtlarını kaydedebilir. Ancak her iddiayı otomatik olarak doğrulayamazlar. Bir güvenlik açığı gerçek olsa bile ortam eksikse veya tetikleyici yanlışsa PoC başarısız olabilir. Test uzmanları, iddia edilen istismar edilebilirliği kanıtlamadan da bir çökme durumunu yeniden üretebilir. İnsan muhakemesinin hâlâ kritik önem taşımasının nedeni bu çekincelerdir. Yine de bu araçlar, bir rapor mühendislik, güvenlik açığı yönetimi ve müşteri desteği ekiplerinin daha fazla zamanını almadan önce ekiplerin yeniden üretilebilir bir yanıta ulaşmasına yardımcı olabilir.

CVE Ekosistemindeki Aşırı Yükün Üstesinden Gelmek

Hiçbir kısa politika, sahte CVE sorununu sihirli bir şekilde çözemez. Ancak başvurular için daha güçlü kanıtlar sunulmasını zorunlu kılmak ve yeniden üretim durumunu daha açık biçimde belirtmek yardımcı olur. İhtilaflı kayıtların daha net ele alınması ve sonraki sistemlere aktarılan verilerin daha hızlı düzeltilmesi de fayda sağlar. Araştırmacılar, yapay zekâ destekli bulgularını başvuru öncesinde doğrulamaya teşvik edilmelidir.

Güvenlik ekipleri ve tedarikçiler, kanıtları incelemeye odaklanmalıdır. Kritik bir CVE puanı, savunmasız kod yoluna kendi ortamlarında erişilip erişilemediğini göstermez. Bir PoC’nin başarısız olması, her şeyin yolunda olduğu anlamına gelmez. Ayrıca bir CVE kimliği almak, ekipleri sorunu anlamak için gereken teknik çalışmayı yapma yükümlülüğünden kurtarmaz.

Yapay zekâ, güvenlik açıklarını keşfetme becerisini geliştirirken ikna edici görünen ancak yanlış iddiaların oluşturulmasını da mümkün kılıyor. Raporların giderek çoğaldığı bir dünyada kuruluşların doğrulamaya yatırım yapması gerekiyor. Bu; testler oluşturmayı, sonuçları yeniden üretmeyi, varsayımları denetlemeyi ve kanıtların değerlendirilmesini kolaylaştırmayı kapsıyor. Ajan tabanlı güvenlik testleri bu alanda önemli bir rol oynayabilir.