Считано от 27 юли 2026 г., GitHub ще намали изплащанията по публичната си програма за откриване на бъгове (bug bounty) с поне наполовина за всяко ниво на сериозност. Наградите за критични открития ще спаднат от 20 000 – 30 000+ долара до фиксираните 10 000 долара, докато постоянното VIP ниво, достъпно само с покани, ще изплаща 30 000 долара или повече.

Докладите, подадени преди тази дата, включително тези, които вече са в нарастващата опашка за триаж на GitHub, ще запазят предишните условия за плащане.

От GitHub заявиха, че промените имат за цел да намалят излишния шум, като същевременно предоставят на утвърдените изследователи по-бързи отговори, по-високи награди и по-близък достъп до техния екип по инженерна сигурност.

„Не печелите повече, като изпращате повече“, заявяват от компанията. „Печелите повече, като изпращате по-добри доклади.“

Публичната програма преминава от гъвкави диапазони към фиксирани плащания:

  • Ниско: $250 (намалено от $617 – $2 000)
  • Средно: $2 000 (намалено от $4 000 – $10 000)
  • Високо: $5 000 (намалено от $10 000 – $20 000)
  • Критично: $10 000 (намалено от $20 000 – $30 000+)

Според изчисления на The Hacker News новите публични тарифи са с 50% по-ниски за средни, високи и критични констатации и с около 59% по-ниски за доклади с ниска сериозност спрямо долната граница на предишните диапазони на GitHub.

От GitHub посочиха, че фиксираните плащания трябва да премахнат несигурността и административното натоварване при триажа, въпреки че все пак могат да присъждат дискреционни бонуси за изключителна работа.

Схемата за VIP нивото определя плащания от $1 000 за констатации с ниска сериозност, $7 500 за средна, $20 000 за висока и $30 000 или повече за критични уязвимости.

Изследователите могат да се класират за частната VIP програма, като докладват поне една критична, две с висока сериозност, четири средни или седем уязвимости с ниска сериозност. В съобщението не се уточнява времеви прозорец за покриване на тези прагове, нито дали класирането гарантира покана. От GitHub заявиха, че по-подробни критерии ще се появят на тяхната публична страница в платформата HackerOne.

GitHub не разкрива прага за HackerOne Signal, който ще налага. Компанията споделя, че изследователите под този праг ще имат ограничение до четири първоначални подавания.

Отделно, общите правила на HackerOne дават на новите изследователи четири пробни доклада на програма в рамките на плаващ 30-дневен прозорец.

Когато вашият собствен изкуствен интелект намери уязвимостта първи

Контролът върху докладите от страна на GitHub идва в момент, когато изкуственият интелект прави генерирането на потенциални констатации по-евтино, а прегледа на код – по-лесен за повтаряне. Повече изследователи могат да генерират потенциални уязвимости, докато вътрешните екипи могат да сканират код, да валидират проблеми и да внедряват корекции за сигурност в потоците за пускане на версии и комити, преди да пристигне външен доклад.

Ден преди съобщението на GitHub, Google представи Gemini 3.5 Flash Cyber – олекотен модел, фино настроен да открива, валидира и отстранява софтуерни уязвимости. От Google съобщиха, че моделът първоначално ще бъде достъпен изключително за правителства и доверени партньори чрез CodeMender, техния агент за сигурност на кода, като част от ограничен пилотен проект.

Google сподели, че моделът може да бъде извикван многократно, за да изследва повече пътища на кода, без да се налага използването на по-голям водещ модел за всеки опит. Компанията го позиционира за чести сканирания на хранилища, критични по отношение на времето прегледи преди стартиране на софтуер и потоци за сканиране на комити.

При тестове, проведени от Google, Gemini 3.5 Flash Cyber е открил 55 уникални потвърдени проблема в енджина V8, в сравнение с 47 за стандартния Gemini 3.5 Flash и 36 за Claude Opus 4.6.

Отделно от Google споделиха, че техният екип за изследване на уязвимости в облака (Cloud Vulnerability Research) е използвал модела, за да открие пропуски за отдалечено изпълнение на код (RCE) в публични API интерфейси и грешка, свързана с повреда на паметта в критична производствена услуга, в рамките на два часа. След това моделът е генерирал това, което Google описва като 100% надежден RCE експлойт, който заобикаля защитите ASLR и W^X. Данните от бенчмарковете и резултатите от експлойта в реална среда са докладвани от Google и не са независимо проверени.

Вътрешен екип за сигурност може да предостави на даден AI агент контекста на хранилището, специфичен за проекта модел на заплахите и среда за валидиране, съобразена с работещата система. Системи като Codex Security на OpenAI могат след това да тестват констатациите, да генерират работещи доказателства за концепцията (PoC) и да предлагат корекции за сигурност, които вземат предвид целта на системата и околното поведение.

Тази работа може да се извършва по време на разработката и при всеки съответен комит, вместо да се чака планирана оценка или външен доклад. Изкуственият интелект не замества изцяло тестовете за проникване (пенетрейшън тестове), но прегледът на изходния код, генерирането на тестове и първоначалната валидация стават все по-лесни за автоматизиране.

Човешките тестери запазват по-голяма стойност там, където работата изисква свързване на слабости в рамките на различни граници на доверие, разпознаване на логически грешки в бизнес процесите, моделиране на реалистични пътища за атака и доказване на реалното въздействие.

Поддържащият проекта curl Даниел Стенберг прекрати паричните награди за откриване на бъгове в края на януари 2026 г., след като процентът на потвърдените уязвимости спадна под 5% на фона на увеличението на доклади с ниско качество, генерирани от изкуствен интелект.

До април, след като curl прекрати паричните награди и се върна към HackerOne, докладите пристигаха с около два пъти по-висока скорост спрямо 2025 г., като 15-16% от тях бяха потвърдени като уязвимости. Стенберг отбеляза, че почти всеки доклад изглежда е бил изготвен с помощта на AI, но сега повечето са с високо качество.

Взети заедно, контролът върху докладите от GitHub, многократните извиквания на модели от Google и нарастващият обем на подадените доклади в curl сочат към една и съща промяна. Изкуственият интелект може да залее поддържащите софтуера с некачествени доклади, но той също така променя изцяло динамиката на сигурността.