GitHub limitează rapoartele de vulnerabilități, dar păstrează lista albă

În anunțul din 1 octombrie 2026, GitHub a introdus limite zilnice pentru rapoartele private noi de vulnerabilitate. Un cont poate trimite un număr limitat de rapoarte către un depozit și pe platformă în ansamblu. Administratorii pot stabili separat un plafon zilnic pentru depozitul lor și pot trece cercetătorii de încredere pe o listă de excepții.

Schimbarea privește depozitele publice care au activată raportarea privată pe GitHub Free, Pro, Team sau Enterprise Cloud. O relatare a DevOps.com arată că valorile limitelor automate pe utilizator nu au fost publicate. Pentru administrator, decizia pe care o poate lua este alegerea plafonului total al depozitului, fără a pierde canalul privat pentru cercetătorii cunoscuți.

Limita contului și plafonul depozitului au roluri diferite

Limita pe utilizator controlează câte rapoarte private noi poate deschide același cont într-o zi. Ea se aplică atât raportărilor către un anumit depozit, cât și activității contului pe GitHub în ansamblu. Când atinge o limită, raportorul primește un mesaj care îi cere să încerce mai târziu. Administratorul unui depozit nu alege aceste praguri ale platformei.

Plafonul depozitului controlează volumul total zilnic de rapoarte private noi primite de proiect, indiferent de numărul conturilor care le trimit. Acesta este reglajul disponibil administratorului. Un plafon mic poate reduce sesizările automate care ajung la triere, dar poate întârzia și o constatare utilă trimisă după atingerea limitei. Plafonul măsoară intrările, nu gravitatea ori calitatea unei vulnerabilități.

Limitele privesc deschiderea rapoartelor noi. Comentariile la avizele de securitate deja existente rămân disponibile, astfel încât analiza unei sesizări începute poate continua. Distincția contează pentru echipele care cer dovezi suplimentare sau clarificări: plafonul de intrare nu oprește conversația dintr-un caz aflat deja în lucru.

Lista de excepții păstrează deschis canalul pentru colaboratorii cunoscuți

Un administrator poate adăuga conturi de cercetători de încredere pe lista de excepții. Acești raportori nu sunt opriți de limitele de raportare, inclusiv când trimit mai multe constatări într-o zi. Excepția este utilă pentru o colaborare de securitate deja stabilită, dar depinde de identificarea contului căruia i se acordă; un cercetător nou rămâne supus limitelor obișnuite.

Reglajele se găsesc în Settings → Advanced Security → Settings, lângă „Private vulnerability reporting”. Raportarea privată trebuie activată pentru depozitul public înainte ca cercetătorii să poată folosi acest canal. Ei trimit atunci detaliile către cei care întrețin proiectul prin formularul de vulnerabilitate, fără a le publica imediat într-un issue obișnuit.

Lista de excepții și plafonul răspund unor situații diferite. Prima protejează accesul unor raportori cunoscuți; al doilea stabilește cât volum nou poate primi proiectul în restul zilei. O listă restrânsă, revizuită când se schimbă colaboratorii, este o alegere de administrare, nu o cerință numerică impusă de platformă. Ea nu înlocuiește analiza tehnică a rapoartelor trimise de conturile exceptate.

Formularul stabilește ce poate fi evaluat la triere

Documentația GitHub despre configurare precizează că formularul implicit cere un rezumat, detalii, dovada conceptului și impactul posibil. Răspunsurile oferă echipei un punct de plecare pentru evaluare. Formularul poate fi personalizat prin fișierul .github/VULNERABILITY_REPORT.yml sau prin varianta cu extensia .yaml.

Într-un formular personalizat, administratorul poate cere, de exemplu, componenta și versiunea afectată, pașii de reproducere și impactul observat. Acestea sunt propuneri de triere: câmpurile utile depind de produsul întreținut și de informațiile pe care raportorul le poate obține. Formularul acceptă câmpuri obligatorii și o lungime minimă pentru anumite răspunsuri. Dacă structura personalizată nu poate fi validată, raportorii văd formularul implicit.

Există și raportare prin REST API. Pentru un depozit cu formular personalizat, descrierea trimisă prin API trebuie să includă secțiunile și răspunsurile obligatorii ale acelui formular; formularul implicit nu este impus trimiterilor prin API. Această diferență contează dacă proiectul primește sesizări de la instrumente sau cercetători care folosesc integrarea API. Separat, administratorul poate cere asocierea unei categorii CWE cu un raport nou, inclusiv pentru trimiterile prin API.

Două moduri de a alege plafonul zilnic

Pentru un proiect mic, cu puține persoane care pot examina sesizările, un model orientativ este să înceapă cu formularul implicit și cu un plafon apropiat de volumul pe care echipa îl poate analiza într-o zi. Conturile cercetătorilor cu care proiectul colaborează deja pot primi excepție. Alegerea plafonului trebuie raportată la capacitatea reală de triere: o valoare redusă ajută puțin dacă echipa nu poate cerceta nici rapoartele acceptate.

Pentru un proiect care primește frecvent constatări de la persoane diferite, un plafon mai permisiv poate păstra accesul noilor raportori. Un formular personalizat poate cere informații care separă o problemă reproductibilă de o descriere vagă, fără să impună date imposibil de cunoscut din afara proiectului. Cercetătorii cunoscuți pot rămâne pe lista de excepții atunci când raportează mai multe probleme distincte. Acesta este tot un model orientativ, nu o valoare recomandată sau testată public de GitHub.

În ambele situații, plafonul și formularul influențează etape diferite: primul decide câte rapoarte noi intră, iar al doilea ce informații conțin cele acceptate. Dacă rapoartele utile ajung după atingerea plafonului, administratorul poate ajusta limita depozitului; dacă intră multe sesizări greu de verificat, poate schimba cerințele formularului. Lista de excepții oferă cercetătorilor de încredere o cale de raportare chiar și atunci când volumul general trebuie ținut sub control.

Citește și:

• UiPath și BDO mută auditul spre agenți AI, dar omul păstrează controlul
• Canva sau Adobe Express: interfețe similare, limite AI foarte diferite
• UiPath leagă Snowflake fără copii de date, dar accesul rămâne critic