Güvenlik açığı raporları neden artık 'özel' değil: bug bounty ekosisteminin sahte alarm sorunu

Filippo Valsorda — Go programlama dilinin eski güvenlik şefi ve şimdi bağımsız güvenlik araştırmacısı — Pazartesi yayımladığı blog yazısında modern bug bounty ekosisteminin temel bir sorununu özetledi: güvenlik açığı raporları artık "özel" değil, ve bu durum açık kaynak yöneticileri için ciddi bir zorluğa dönüşmüş durumda. Yazı, Hacker News'in zirvesinde gün boyunca tartışıldı.

Valsorda'nın savunması basit: 2010'larda bir güvenlik açığı raporu, bir projenin ekibi için göreceli olarak nadir, dikkat çekici bir olaydı. Genellikle deneyimli bir araştırmacıdan gelen, ayrıntılı kanıt ve önerilerle dolu bir e-posta olurdu. 2026'da, otomatize edilmiş tarayıcılar ve AI üretilmiş raporların geldiği bir ortamda bu yapı değişti.

Yazıdaki ana iddia, raporların hacminin artışıyla birlikte sinyalin gürültü oranının düştüğü. Valsorda, bir açık kaynak yöneticisinin haftada onlarca "buldum" raporuyla karşılaşabileceğini, ancak bunların ezici çoğunluğunun ya yanlış pozitif (sorun yok), ya kötü tanımlanmış (eksik kanıt), ya da bilinen bir konunun yeniden bildirimi olduğunu söylüyor.

Valsorda'nın yazısında özellikle vurgulanan bir noktayı şöyle özetledi: « Bug bounty programları, bir saldırı yüzeyi azaltma aracı olarak tasarlandı; ancak yöneticiler için bir spam yönetim sistemi haline geldi ». Yazı, bu durumun gönüllü açık kaynak yöneticilerinin daha hızlı tükenmesine yol açtığını öne sürüyor.

Valsorda, sorunun birkaç kaynağı olduğunu belirtti. İlki: AI üretilmiş raporlar. Hem büyük dil modelleri (LLM) hem de otomatize edilmiş statik analiz araçları, gerçek olmayan ya da abartılı bulguları rapor üretiyor. İkincisi: bug bounty platformlarının (HackerOne, Bugcrowd) ödül teşvikleri, niceliksel rapor sayısını ödüllendirmeye eğilimli.

Yazıda, açık kaynak ekosisteminin (örneğin Linux Kernel, OpenSSL, FFmpeg gibi projeler) bu yapıdan en çok zarar gören kesim olduğunu vurguladı. Bu projelerin yöneticileri, raporlama ekosisteminin değişimine yetişebilecek personel kaynaklarına sahip değil. CVE numarası alma süreçleri, MITRE'nin sınırlı kapasitesine bağlı olarak zaten gecikmeli.

Google'ın Project Zero ekibi de geçen yıl bir blog yazısında benzer bir mesaj verdi: « otomatize taramalar bizim için anlamlı bir sinyal değil, çoğu zaman gürültü ». Project Zero, kendi araştırmalarında yalnızca araştırmacının el-elemesiyle doğrulanmış bulguları kabul ediyor.

Valsorda'nın önerdiği çözümlerin merkezinde, raporlama sürecinin yeniden tasarlanması yer alıyor. Önerileri arasında: (1) öncelik sırası belirleyen otomatize doğrulama katmanı, (2) CVE numarası verme yetkisinin daha geniş dağıtımı, (3) bug bounty programlarının ödül yapısını tek bir rapor yerine tekrarlanan, kaliteli kanıt sağlayanlara yöneltilmesi, ve (4) AI üretilmiş raporların ayrı sınıflandırılması.

GitHub Security Lab müdürü Bas Alberts, Hacker News tartışmasında bir yorumla katıldı: « Valsorda'nın savı, GitHub'da gördüklerimizle uyumlu. AI üretilmiş raporların kabul edilebilir bir kalite eşiğini geçmesi için çok daha sıkı doğrulama gerek ». Alberts, GitHub'ın bu yıl içinde rapor doğrulama yapısını yenileyeceğini ekledi.

Valsorda'nın yazısı, daha geniş bir sektör tartışmasının parçası: güvenlik araştırmacılığının ekonomik teşvikleri nasıl yeniden dengelenmeli? Ödüller niceliksel raporları teşvik ediyorsa, sektör doğal olarak gürültü üretir. Yeniden tasarım gerek ya da, Valsorda'nın da belirttiği gibi, açık kaynak ekosistemin korunmasını için yeni bir mali yapı.