Google hata ödülünü daralttı; AI raporlarının çoğu geçersiz çıktı

Google’ın güncel OSS VRP kuralları, 1 Ekim 2026’dan itibaren yeni ürün açığı başvurularının durduğunu, daha önce gönderilen dosyaların etkilenmediğini ve 2027’nin ilk çeyreğinde programın bu kısmına ilişkin güncelleme yapılacağını belirtiyor. Tedarik zinciri bildirimleri kabul edilmeye devam ediyor. Değişiklik, Google’ın açık kaynak yazılımlarındaki güvenlik araştırmasını ödüllendiren programda yeni ürün kusuru raporları için kullanılan yolu daraltıyor.

Google, BleepingComputer’ın aktardığı açıklamasında gerekçeyi “This pause is due to a significant rise in automated submissions, the vast majority of which are not valid” sözleriyle anlatıyor. TechCrunch’ın haberi duraklamayı AI destekli başvurulardaki artış bağlamında ele alıyor. Şirketin kullandığı ifade “otomatik başvurular”; yayımlanan açıklama, geçersiz raporların kesin oranını veya tamamının yapay zekâ ile üretildiğini söylemiyor.

Durdurulan başvuru tam olarak hangisi?

Kısıt, OSS VRP’ye yeni gönderilen ürün açığı raporları için geçerli. Bu sınıf, Google’ın açık kaynak kodundaki tasarım veya uygulama kusurunun yazılımı kullanan ürünlerde güvenlik etkisi doğurmasına ilişkin. Bellek bozulması, yol geçişi, temizleme işlevinin korumayı sağlamaması ve güvensiz varsayılanlar, program metninde bu tür kusurlar için verilen örnekler arasında. Böyle bir bulgu, duraklama sürerken yeni bir OSS VRP ürün açığı dosyası olarak ödül incelemesine gönderilemiyor.

Önceden gönderilmiş bir dosya aynı durumda değil. Duraklama, teslim edilmiş ürün açığı raporlarını geriye dönük olarak kapsam dışına çıkarmıyor; bu dosyalar mevcut inceleme süreçlerinde kalıyor. Bunun ödeme garantisi olduğu sonucu da çıkmıyor: ödül kararı, raporun güvenlik etkisi ve programın değerlendirmesine bağlı. Ayrım, hâlihazırda yanıt bekleyen araştırmacılar açısından belirleyici.

Program metninde ürün açıklarına ait örnekler ve kabul ölçütleri görünmeye devam ediyor. Bunlar güncel duraklamayı kaldırmıyor. Dolayısıyla raporun güçlü bir teknik açıklama içermesi, yeni ürün açığı kategorisindeki kabul kısıtını tek başına aşmıyor; aynı kusuru farklı bir başlık altında sunmak da bulgunun niteliğini değiştirmiyor.

Hangi bildirim yolu açık?

Açık kalan yol, raporun Google’ın açık kaynak deposunu, kaynak kodunu veya kullanıcılara dağıtılan derleme çıktısını nasıl etkilediğine bağlı. Tedarik zinciri açığında belirleyici mesele, saldırganın kodun ya da paketin bütünlüğünü bakımcının olağan onayını aşarak değiştirebilmesi. Bir ürünün kendi çalışma davranışındaki kusur ise bu etki gösterilmedikçe tedarik zinciri açığı sayılmıyor.

• Yeni OSS VRP ürün açığı: Bu kategoride yeni rapor kabul edilmiyor.
• Daha önce gönderilmiş ürün açığı: Dosya duraklamadan etkilenmeden incelenmeye devam edebiliyor.
• OSS VRP tedarik zinciri bulgusu: Kaynak, derleme veya dağıtım bütünlüğünü etkileyen ve istismar edilebilirliği gösterilen raporlar kabul ediliyor.
• Diğer güvenlik sorunları: Teknik ürün açığı olmayan, ancak proje güvenliğini etkileyen uygun bildirimler kurallarda ayrı bir sınıf olarak yer alıyor.
• Patch Rewards: Google’ın açık kaynak projelerine yapılan güvenlik iyileştirmelerini ödüllendiren ayrı yol sürüyor.

Bulgu, Google Cloud ürününü etkileyen bir açık kaynak depodan kaynaklanıyorsa Cloud VRP bazı ürün açığı raporlarını kabul edebiliyor. Cloud ile veya bir AI ürünüyle yakından bağlantılı açık kaynak projeleri için ilgili Cloud VRP ya da AI VRP’ye yönlendirme bulunuyor. Bu kanalların her biri kendi ürün kapsamına sahip; yalnızca deponun Google’a ait olması veya raporda AI geçmesi otomatik uygunluk sağlamıyor.

Patch Rewards farklı bir katkıyı ödüllendiriyor: açık kaynak projeye kazandırılan güvenlik iyileştirmesini. Bu nedenle yeni bir ürün açığı raporunun adını yama önerisi olarak değiştirmek, OSS VRP’de durdurulan başvuru yolunu yeniden açmıyor. Başvurunun uygunluğu, bulgunun etkilediği ürüne, gösterilen saldırı yoluna ve varsa yapılan düzeltmeye bağlı.

Geçerli bir rapor için ne gösterilmeli?

Otomatik araç bir kod parçasını şüpheli bulabilir; inceleme açısından önemli olan, bu parçanın gerçek projede erişilebilir ve istismar edilebilir bir güvenlik etkisi üretmesidir. Aynı kod örüntüsünün birçok raporda tekrarlanması, açığın ilgili sürümde çalıştığını kanıtlamaz. Geçersiz başvuru sorunu bu ayrımda somutlaşıyor: bulgu iddiası ile gösterilmiş etki aynı şey değil.

OSS VRP rapor standardında yakın tarihli bir derlemeye karşı hazırlanmış derlenebilir kavram kanıtı, mümkünse çökme dökümü, yeniden üretim adımları, etkilenen yazılım sürümü ve saldırı senaryosu isteniyor. Tedarik zinciri raporunda kaynak kodunu, derleme çıktısını veya yayımlanan paketi gerçekten değiştirebilecek yolun gösterilmesi gerekiyor. Örneğin bir dış katkıcının değişikliği ancak bakımcı onayından sonra çalışabiliyorsa, bu durum onayı aşan bir saldırı yoluyla aynı kapsamda değerlendirilmiyor.

Yapay zekâ yardımıyla hazırlanmış raporlar için de ölçüt, metnin akıcılığı veya olası kusurları listeleme hızı değil, somut kanıt. Araç bir hipotez üretebilir; raporun değeri ilgili sürümde davranışın yeniden üretilebilmesine ve kullanıcı ya da yazılım tedarik zinciri üzerindeki etkisinin gösterilmesine bağlı. Mevcut duraklama otomasyonun her kullanımına yasak getirmiyor; belirli bir yeni başvuru kategorisini askıya alıyor.

Sonraki karar ne zaman?

Programın ürün açığı bölümüne ilişkin açıklanmış sonraki adım, gelecek yılın ilk çeyreğinde yapılması beklenen güncelleme. Bu, aynı dönemde başvuruların yeniden açılacağı taahhüdü anlamına gelmiyor. İnceleme ölçütlerinin nasıl değişeceği ve yeni ürün açığı dosyalarının hangi koşullarda tekrar alınacağı, bu duyuruyla netleşecek.

Ayrıca okuyun:

• OpenAI ajanları denetim alanından çıktı: Hugging Face raporundaki zincir
• Marka sınıfını yanlış seçmeyin: Eksik ücret başvuruyu daraltabilir
• Claude AI’ye başlarken yapılan hata: Belirsiz komutla yetinmek