Google, otomatik raporlar değerlendirme sürecini felç ettiği için açık kaynak hata ödül programını durdurdu

Google açık kaynak hata ödül programında başvuru alımını durdurdu

Google, 1 Ekim 2026'da Open Source Software Vulnerability Rewards Program'a (OSS VRP) ürün zaafiyeti raporu kabulünü durdurdu. dev.to'da yer alan bir yazıya göre şirket, bu değişikliği X'te ve programın kendi kurallar sayfasında duyurdu ve duraklatmayı otomatik başvurulardaki önemli artışa bağladı; bu başvuruların çoğunun geçerli çıkmadığı belirlendi.

Duraklatma, başlığın çağrıştırdığından daha dar kapsamlı. 1 Ekim'den önce gönderilen başvurular işlenmeye devam ediyor, tedarik zinciri raporları kapsam dahilinde kalıyor ve belirli Google Cloud depalarını etkileyen ürün zaafiyetleri hâlâ Cloud VRP üzerinden ödül alabilir. Program geri dönene kadar — Google 2027'nin ilk çeyreğinde bir güncelleme sözü verdi — araştırmacılar diğer ödül programlarına ve Patch Rewards Program'a yönlendiriliyor.

curl ödül programını daha önce kapattı

curl projesi Nisan 2019'dan 31 Ocak 2026'ya kadar bir hata ödül programı yürüttü ve kuyruğun ekonomisi tersine döndükten sonra programı kapattı. Ocak ayında yayımladığı bir yazıda kurucu Daniel Stenberg, programın ömrü boyunca 87 zaafiyeti doğruladığını ve 100.000 Amerikan dolarından fazla ödeme yaptığını, ancak gerçek zaafiyet olarak doğrulanan başvuruların oranının önceki yıllardaki yüzde 15'in üzerindeki seviyeden 2025'ten itibaren yüzde 5'in altına düştüğünü — yirmide birden az — bildirdi.

dev.to yazısında aktarılan ve HackerOne'ın projeye paylaştığı rakamlar, curl'e gelen rapor hacminin dört çeyrek boyunca keskin biçimde artarken, Ruby, Node ve Rails gibi karşılaştırılabilir açık kaynak programlarının düz kaldığını veya gerilediğini gösteriyor. Stenberg'in okuması şu: ödül parası hem gerçek hem de rahatsızlık verici raporları çekiyor ve platformun itibar sistemi ikinci türü elemeye yetmiyordu.

Ne ucuzladı, ne pahalı kaldı

Bir depoya yönlendirilmiş bir dil modeli, bir açıklamaya benzeyen şeyler üretebilir: CVE tarzı bir başlık, makul bir kök neden, bir proof-of-concept bloğu, bir önem derecesi. Sık sık üretemediği şey ise var olan bir hata. Tom's Hardware, Google mühendislerinin ve maintainer'ların binlerce geçersiz ya da sömürülemeyen "halüsinasyon" raporu tarafından bunaltıldığını ve bunları doğrulamakla geçirilen sürenin doğrudan gerçek hataları düzeltme süresinden kesildiğini bildirdi. Stenberg aynı iş yükünü maintainer tarafından şöyle anlattı: çöp başvurularla uğraşmak maintainer'ları tüketiyor ve bunları çürütmek ciddi emek gerektirebiliyor.

Hikâyenin özü bu asimetri. Artık bir rapor yazmak birkaç dakikalık promptlama ve sıfır alan bilgisi tutuyor; bir raporu doğrulamak ise hâlâ kod tabanını bilen, bir reproducer'ı derleyip çalıştırabilen ve sağlam bir olumsuz sonuca varmasına güvenilen bir mühendis tutuyor.

Birkaç program, tek duvar

Google, duraklatmadan önce zaten ayarlama yapıyordu. Mayıs 2026'da standart Chrome ödemelerini düşürdü ve bir hatanın somut olarak varlığını kanıtlayan öz raporları tercih etmeye başladı; aynı zamanda persistence'lı zero-click bir Pixel Titan M exploit'i için en yüksek Android ödülünü 1 milyon dolardan 1,5 milyon dolara çıkardı — otomatik araçların ulaşmasının daha zor olduğu bir kategori. Mart 2026'da HackerOne'ın Internet Bug Bounty'si yeni başvuruları durdurdu ve yapay zekâ destekli keşfin hız ve hacminin topluluğun düzeltme gönderme kapasitesini aştığını söyledi. Tom's Hardware ayrıca bir bakım sonucu daha kaydediyor: Linux çekirdeği, yapay zekâ üretimi sahte hata raporlarındaki artışın ardından eski ağ sürücülerine desteği sonlandırdı.

Hep bir arada düşünüldüğünde, bunlar bir Google sorunu gibi görünmeyi bırakıyor. Keşif, düzeltmeden ucuzladığında kısıt, okuyan, yeniden üreten ve düzelten insanlara kayıyor.

Neden önemli

Açık kaynak güvenliğindeki bağlayıcı kısıt değişti. Ödül bütçelerinin her zaman kıt kaynak olduğu varsayılırdı; 2026'nın olayları kıt kaynağın aslında gözden geçirme kapasitesi olduğunu gösteriyor. Artık herhangi bir açık başvuru kuyruğu — fonlu bir ödül programı ya da sıradan bir güvenlik iletişim adresi — insanların okuyabileceğinden daha hızlı sel altında kalabiliyor ve para bunu çözmüyor.

dev.to yazısı, bir kuyruğu işler tutacak başvuru kuralları öneriyor: tam sürüm, yapılandırma, girdi ve gözlemlenen çıktıyı içeren, yeniden üretilebilir bir proof of concept iste; önce hatanın desteklenen bir sürümde var olup olmadığını kontrol et, çünkü sürüm kontrolü bir kuyruğun büyük kısmını eler; her rapora süre sınırı koy ve yazılı bir gerekçeyle kapat; kuyruğa paylaşılan bir gelen kutusu yerine tek bir isimlendirilmiş sorumlu ver; ve doğrulanan rapor oranını şirket içinde izle, çünkü başvuru sürecinin yalnızca emmek değil gerçekten elemek yapısında olup olmadığını gösteren tek sayı bu. Maintainer'lar ve güvenlik ekipleri için aynı şekilde, bir programın otomatik raporlamayla temasında hayatta kalıp kalmayacağını belirleyen şey bu kurallar — daha büyük ödemeler değil.