GitHub schimbă Bug Bounty: ce intră în vigoare azi
GitHub a anunțat o restructurare a programului său Bug Bounty, iar raportările trimise începând de astăzi, 27 iulie 2026, intră sub noua structură. Compania spune că urmărește să reducă volumul de raportări cu valoare redusă și să acorde mai mult timp cercetării de calitate și relației cu cercetătorii.
Schimbarea este relevantă pentru echipele de produs, securitate și cercetătorii din România și UE care lucrează cu ecosisteme open source. Nu schimbă regulile juridice privind testarea fără autorizație: cercetarea trebuie făcută numai în limitele programului și ale autorizării explicite.
Ce se schimbă de azi
GitHub păstrează programul public, dar introduce recompense fixe pe severitate: 250 USD pentru Low, 2.000 USD pentru Medium, 5.000 USD pentru High și 10.000 USD pentru Critical. Raportările depuse înainte de 27 iulie sunt păstrate în schema anterioară; pragul nou se aplică numai celor depuse de astăzi înainte.
Compania explică schimbarea prin creșterea cozii de raportări și nevoia de a separa mai bine semnalul de zgomot. Recompensa nu este un substitut pentru impactul demonstrat, reproducerea sigură și respectarea scopului publicat al programului.
Programul VIP și pragul de semnal
GitHub formalizează un program VIP privat, pe bază de invitație, pentru cercetători cu rezultate consecvente și cu impact mare. Tabelul publicat de GitHub indică recompense VIP de la 1.000 USD pentru Low la 30.000 USD sau mai mult pentru Critical, iar criteriile de calificare sunt legate de constatări validate, nu de volum.
Pentru programul public, GitHub spune că aplică un prag de semnal HackerOne. Cercetătorii care nu îl ating au un număr limitat de trimiteri inițiale, pe care GitHub îl descrie ca fiind de până la patru. Ideea este să se păstreze o cale de intrare pentru cercetare autentică, reducând în același timp raportările repetitive sau generate fără validare.
Ce pot învăța organizațiile care au un program de disclosure
- ▸Publică un scope precis: active incluse, sisteme excluse, limite de testare, canale de raportare și comportamente interzise.
- ▸Definește criterii de acceptare care cer impact demonstrat, pași de reproducere minim necesari și dovezi care nu expun datele altor utilizatori.
- ▸Separă trierea de remediere: confirmarea raportului, severitatea, owner-ul tehnic, SLA-ul și comunicarea către cercetător sunt etape distincte.
- ▸Păstrează o evidență a deciziilor și a excepțiilor; aceasta ajută la audit, la învățare după incident și la răspunsuri consecvente.
- ▸Nu promite safe harbor sau recompense pe care nu le poți susține contractual și operațional; textul programului trebuie revizuit juridic pentru jurisdicția organizației.
AI nu elimină nevoia de triere tehnică
GitHub leagă explicit pragul de semnal de creșterea raportărilor cu efort redus și generate cu ajutorul AI. Pentru echipele care primesc disclosure-uri, răspunsul sănătos nu este blocarea automată a cercetătorilor noi, ci un proces care verifică autorizația, duplicarea, impactul, dovezile și riscul de exploatare înainte de alocarea unei investigații costisitoare.
Automatizarea poate ajuta la deduplicare, clasificare și confirmarea contextului activului. Decizia de severitate și de remediere trebuie totuși să rămână trasabilă și revizuită de persoane competente, mai ales când afectează clienți, date personale sau infrastructură critică.
Un flux responsabil după primirea unei raportări
Confirmă rapid primirea, verifică dacă activul este în scope și desemnează un owner. Protejează materialul de raportare, limitează distribuirea dovezilor și notează clar decizia dacă raportarea este duplicat, în afara scopului sau necesită informații suplimentare.
Pentru o vulnerabilitate confirmată, leagă problema de inventar, versiune, expunere, termen de remediere și verificare după deploy. O comunicare responsabilă cu cercetătorul și o cronologie internă păstrată corect reduc atât riscul tehnic, cât și confuzia operațională.
Leagă vulnerabilitatea de activ și de remediere
Awarely Monitor corelează CVE-urile cu produsele urmărite și inventarul de active, astfel încât echipa să poată prioritiza, documenta decizia și verifica remedierea într-un flux auditabil.