Google приостановил Open Source Software Vulnerability Rewards Program с 1 октября, заявив о «значительном росте автоматических отчётов, подавляющее большинство из которых не валидны». Программа возобновит работу не ранее первого квартала 2027 года — компания пообещала подробное обновление к тому времени. Параллельно Google рекомендует исследователям обратиться к другим программам вознаграждения компании.
За этим шагом стоит вполне осязаемая проблема: исследователи и разработчики открытого ПО были буквально завалены отчётами от AI-инструментов, которые либо вообще не содержали реальных уязвимостей, либо выдумывали проблемы на основе галлюцинаций. Это не новость — ещё год назад киберэксперты предупреждали, что обилие AI-generated контента станет кошмаром для bug bounty программ. Google просто первый крупный игрок, кто решил на это честно ответить, вместо того чтобы молча борозды свои пахать.
Проблема здесь реальная и напрямую связана с текущим состоянием инструментов AI-безопасности. Когда любой может скинуть сгенерированный чатботом отчёт об уязвимости в надежде получить награду, сигнал тонет в шуме. Исследователи тратят время на разбор откровенного мусора вместо того чтобы разбираться с реальными проблемами. Это как получить тысячу писем от спама вместо десятка реальных багов — только ещё более обидно, потому что там действительно были люди (пусть и опирающиеся на AI), которые надеялись что-то заработать.
То, что именно Google потребовалось заморозить программу, а не просто улучшить фильтры, говорит о масштабе проблемы. Речь не об отдельных случаях, а о системном наводнении. Судя по всему, текущие технологии отсеивания автоматических отчётов просто не срабатывают: либо слишком много ложноположительных, либо слишком много ложноотрицательных, либо человеческая модерация не тянет объём.
Для российского бизнеса, который строит собственные security-программы или полагается на краудсорсинг уязвимостей, это хороший сигнал к тому, что нужно уже сейчас думать о фильтрации AI-generated отчётов. Если вы работаете с открытым кодом, стоит либо ужесточить требования к отчётам (требовать PoC, четкий воспроизведение), либо внедрить инструменты автоматической валидации, которые проверяют отчёт перед тем как он попадёт к разработчикам. Можно применить подход, похожий на фильтрацию спама — но это требует достаточных ресурсов.
В долгосрочной перспективе это может подтолкнуть к более аккуратному использованию AI в security-тулингу в целом. Нужны инструменты, которые находят реальные уязвимости, а не выдумывают их. На этом фоне любые заявления компаний о «революционном AI для поиска багов» стоит встречать со здоровым скептицизмом и требованием конкретных доказательств эффективности.