Google suspendă bug bounty-ul open source: prea multe rapoarte IA

📌 Evoluții ulterioare: Chrome: lanț de 250.000 de dolari construit cu IA în șase zile (14 octombrie 2026) · Chrome VRP: Google majorează recompensele, dar doar parțial (13 octombrie 2026)

Google a suspendat până în 2027 o parte din programul său de recompense pentru vulnerabilitățile din proiectele open source, Open Source Vulnerability Rewards Program (OSS VRP). Motivul, în cuvintele companiei, este o creștere puternică a trimiterilor automate, în marea lor majoritate invalide.

Nu există CVE de corectat și nici produse de actualizat. Știrea îl privește totuși pe oricine gestionează vulnerabilități: inteligența artificială face ieftină producerea unor rapoarte convingătoare, în timp ce verificarea lor cere în continuare timpul unui tehnician.

Ce s-a întâmplat

Potrivit Infosecurity Magazine, anunțul a venit pe 1 octombrie 2026, printr-un mesaj publicat de Google pe rețelele sociale. The Hacker News și CSO Online precizează că pauza privește raportările de vulnerabilități de produs din OSS VRP: Infosecurity Magazine vorbește mai general despre suspendarea programului, dar confirmă două excepții:

• raportările privind lanțul de aprovizionare (supply chain) din OSS VRP sunt acceptate în continuare;
• rapoartele deja trimise nu sunt afectate de suspendare.

Google vrea să reorganizeze programul și estimează că va oferi noutăți în primul trimestru din 2027. Până atunci, îi încurajează pe cercetători să caute vulnerabilități în celelalte programe de recompense ale sale sau să participe la Patch Rewards Program.

Programul OSS VRP

OSS VRP a fost lansat în august 2022 și îi recompensează pe cei care găsesc vulnerabilități în proiectele open source ale Google. Acoperă ultimele versiuni ale software-ului găzduit în depozitele publice ale Google pe GitHub și în unele depozite de pe alte platforme, inclusiv configurația lor: workflow-urile GitHub Actions, regulile de acces, configurațiile aplicațiilor GitHub. Recompensele variază între 100 și 31.337 de dolari, în funcție de gravitate și de importanța proiectului.

Vulnerabilitățile din proiectele legate de Google Cloud sau de produsele de IA trec în schimb prin programe dedicate, Cloud VRP și AI VRP.

Semnalele din lunile anterioare

Potrivit CSO Online, suspendarea vine după alte încercări de a ține problema sub control. În martie, Google înăsprise deja regulile OSS VRP după o creștere bruscă a rapoartelor generate cu IA: unele descriau greșit cum se declanșează vulnerabilitatea, altele semnalau defecte de cod cu un impact minim asupra securității. Pentru anumite clase de vulnerabilități, Google a început să ceară dovezi mai solide, cum ar fi rezultate reproductibile sau patch-uri acceptate, iar ulterior a încetat să recompenseze unele raportări de produs de nivel mai scăzut.

Tabloul tehnic: verificarea este gâtul de sticlă

Sursele nu descriu atacuri, malware sau indicatori: nu există un lanț de atac de mapat pe MITRE ATT&CK. Punctul tehnic este altul: cine primește un raport trebuie să stabilească dacă acel cod există, dacă traseul de atac poate fi atins și dacă impactul este real. Un raport credibil se generează în câteva minute; verificarea lui poate cere unui inginer să urmărească codul și să reproducă condițiile declarate.

Un volum mare de trimiteri nu înseamnă neapărat calitate slabă. CSO Online citează două exemple:

• Vercel a primit 1.285 de rapoarte în două săptămâni, în timpul unei provocări de securitate pe mediul său Sandbox, a automatizat o parte din triaj și în final a validat câteva zeci;
• o vulnerabilitate critică în Rejetto HTTP File Server, găsită cu ajutorul unui model de IA, a fost apoi ținta unor încercări de exploatare.

Experții consultați de CSO Online semnalează două riscuri pentru cei care se apără:

1. triajul ca țintă: un canal de raportare fără filtre ar putea permite unui atacator să consume resursele echipei de securitate fără să compromită vreun sistem, de exemplu trimițând variante ale aceluiași raport către mai multe servicii. Sursele precizează că nu există elemente care să arate că Google a fost ținta unei astfel de campanii;
2. prompt injection în rapoarte: dacă triajul este încredințat unui agent de IA, un raport malițios poate conține instrucțiuni menite să-i manipuleze evaluarea sau să-l facă să execute acțiuni prin instrumentele conectate.

Impactul pentru companiile europene și italiene

Suspendarea privește programul Google, dar același dezechilibru între descoperire și verificare poate apărea și în compania ta: în rapoartele care vin din exterior și în rezultatele instrumentelor de analiză asistate de IA folosite intern. Un rezultat care ajunge la responsabilul unei aplicații înainte de a fi evaluat poate irosi ore de muncă, chiar și atunci când versiunea afectată nu este instalată sau codul vulnerabil nu poate fi atins.

Pentru entitățile NIS2, gestionarea și divulgarea vulnerabilităților fac parte din măsurile de gestionare a riscurilor cerute de directivă: un proces de triaj care rezistă doar la volume mici este un punct slab de luat în calcul.

Ce trebuie să faci acum

1. Cere dovezi reproductibile celor care raportează o vulnerabilitate prin canalele tale, grupează rapoartele duplicate și limitează trimiterile când apar tipare de abuz.
2. Verifică mai întâi prezența și accesibilitatea: versiunea afectată este instalată? Serviciul este expus? Abia apoi raportul devine o prioritate.
3. Tratează fiecare rezultat al unui scanner ca pe o ipoteză, nu ca pe dovada unei vulnerabilități exploatabile.
4. Stabilește prioritățile după context: un sistem expus și critic sau o vulnerabilitate deja exploatată contează mai mult decât simplul scor de gravitate.
5. Consideră textul și codul din rapoarte drept intrare nesigură: dacă folosești IA pentru triaj, ține testele departe de sistemele de producție și pune o persoană să verifice acțiunile importante.
6. Măsoară efortul de verificare și vechimea vulnerabilităților cu risc ridicat confirmate, nu numărul de rezultate produse de instrumente. Dacă echipa petrece tot mai mult timp respingând rapoarte slabe, în timp ce problemele confirmate rămân deschise, procesul trebuie revizuit.

Cum ajută ARXDOME

ARX Shield arată vulnerabilitățile deschise pe mașină și pe pachet, cu vechimea lor și cu cele deja exploatate de atacatori evidențiate: te ajută să vezi imediat dacă un software raportat este cu adevărat instalat în sistemele tale. ARX Expose adaugă perspectiva din exterior, cu vulnerabilitățile cunoscute ale serviciilor publice, ca să deosebești ce este expus de ce nu este.

Ultima actualizare: 6 octombrie 2026