Автор: Алексей Гришин, директор по развитию сервисов кибербезопасности Бастиона
Программы баг-баунти не заменяют полноценный аудит или стресс-тестирование. Это открытая форма взаимодействия с исследователями, в рамках которой охотник выполняет задачи, описанные в правилах конкретной программы баг-баунти. Зачастую уязвимость нулевого дня может быть найдена случайно – как побочный результат поиска более сложных или редких багов (например, RCE, SSRF или IDOR), но даже в таком случае это, скорее, исключение.
На практике все часто происходит наоборот: исследователь сначала изучает популярную информационную систему вне программы, находит потенциальный вектор атаки, который может включать в себя уязвимость нулевого дня, и только потом воспроизводит его в рамках баг-баунти. Это позволяет привлечь внимание к незащищенности системы, особенно если вендор ранее ее игнорировал.
Если программа баг-баунти не получает отчетов, это не всегда свидетельствует о высокой защищенности системы. Чаще это связано с низкой привлекательностью проекта для ИБ-специалистов.
Например, поиск отдельных классов уязвимостей (вроде RCE или SSRF) может быть слишком трудоемким по сравнению с потенциальным объемом вознаграждения. Иногда тестирование ограничено, так как требуются регистрация, подтверждение личности или работа через специальные каналы доступа к информационной системе. В других случаях охотников просто не интересует набор целей для тестирования: система обновляется редко, отчеты игнорируются, интерес угасает.
Отсутствие активности – еще не сигнал безопасности. Это повод пересмотреть условия участия и подход к взаимодействию с сообществом исследователей ИБ.
Одна из сильных сторон программ баг-баунти – возможность выявлять ошибки, недоступные традиционным сканерам. Машина ищет сигнатуры и шаблоны, а исследователь работает с логикой: тестирует поведение системы в конкретном контексте. Именно такие сценарии чаще всего приводят к обходу механизмов защиты.
По статистике [2] платформ, около 10% отчетов содержат уязвимости средней и высокой критичности, которые требуют оплаты, реакции и исправления. До 40% включают менее опасные ошибки, а более половины отчетов оказываются нерелевантными.
Там, где автоматизация не видит проблем, человеческая внимательность может дать результат.
Даже зрелые компании могут столкнуться с тем, что эксплойт проходит сквозь действующие механизмы защиты. В таких случаях особенно важна быстрая и системная реакция с фокусом на улучшение. Стоит придерживаться такого порядка действий:
Такой подход позволяет усилить всю систему и укрепить доверие к компании как к зрелому игроку в ИБ.
Баг-баунти действует в рамках заранее установленных правил, поэтому демонстрация уязвимости 0-day внутри программы проходит легально при условии, что действия исследователя соответствуют параметрам участия и не выходят за рамки допустимого тестирования. Этичный исследователь всегда рассчитывает на вознаграждение, повышение репутации и безопасное раскрытие проблемы, поэтому нарушения с его стороны крайне маловероятны – его мотивация напрямую завязана на корректное поведение.
Вендоры часто ограничивают выплаты за 1-day – те, что уже известны, но еще не закрыты. Часто такие уязвимости приравниваются к 0-day: формально о баге известно, но патч еще не выпущен, и защита системы остается условной. Это создает конфликт: исследователь находит проблему и рассчитывает на вознаграждение, но вендор может отказать, сославшись на регламент.
Чтобы избежать таких конфликтов, важно заранее описывать в правилах, какие уязвимости будут признаваться новыми, как рассчитывается срок давности 1-day, и какие случаи считаются спорными. Чем понятнее правила, тем меньше разногласий между вендором и исследователем.
Полный отказ от принятия 0-day отчетов – стратегическая ошибка. Даже если система построена на сторонних решениях, ответственность за ее безопасность остается на владельце.
Некоторые уязвимости на ранних этапах могут напоминать 0-day, особенно если речь идет о доступе к критическим функциям без аутентификации или об обходе бизнес-логики. Такие баги требуют повышенного внимания: они не всегда распознаются сразу как критичные, но несут риски сопоставимые с "нулевым днем".
Наиболее характерные типы уязвимостей, имитирующие поведение 0-day:
Программы баг-баунти не заменяют традиционные инструменты ИБ, но хорошо дополняют их, особенно там, где важно учитывать бизнес-логику, нестандартные сценарии использования и человеческий фактор.
Поиск уязвимостей 0-day – побочный, но ценный результат.
Кроме того, баг-баунти нужно рассматривать и как инструмент обратной связи, и как стресс-тестирование организационных процессов: насколько быстро мы реагируем, как взаимодействуем с исследователями, что можем улучшить после инцидента.
В центре внимания – повышение устойчивости всей системы, поэтому мы стремимся к открытому диалогу с исследовательским сообществом и прозрачным условиям взаимодействия. Это делает баг-баунти частью зрелой модели информационной безопасности.
1-day: уязвимость, которую все знают и все равно эксплуатируют
Информационная безопасность чаще всего говорит о крайностях. С одной стороны – "нулевой день": таинственные 0-day, о которых никто еще не знает. С другой – заплатка, патч, инцидент закрыт. Между ними – промежуточная, почти не обсуждаемая зона: 1-day.
1-day – это уязвимость, о которой уже стало известно, но защита еще не реализована. Патч только анонсирован, CVE присвоен, обсуждения начались – но системы по-прежнему уязвимы. Это не домыслы, не "возможно где-то в теории" – это публично доступная информация и рабочий эксплойт. Он уже в сети и его уже кто-то проверяет на применимость в реальных атаках.
Парадокс в том, что именно такие уязвимости сегодня чаще всего эксплуатируются. Не нулевые, не экзотические, а те, что всем известны. Вендор заявил, но не выпустил обновление. Обновление вышло, но не установлено. Установлено – но только на части серверов. Этим живут 1-day.
И именно они – зеркало зрелости процессов безопасности. Если 0-day – вызов технологии, то 1-day – вызов организации. Это тест на управление: как быстро компания способна выявить, классифицировать, приоритизировать и устранить уже известную угрозу. В этой ситуации нужны не дорогостоящие исследования, а дисциплина.
Вред от 1-day легко недооценить. Кажется, что раз баг уже опубликован, значит, его уже учли. Но факт публикации – это только начало. Настоящая угроза возникает в тот момент, когда появляется PoC. С этого момента у атакующих есть инструмент, а для заказчиков пошел отсчет времени. Кто быстрее: скрипт или процесс обновления?
Отношение к 1-day уязвимостям показывает, насколько компания ориентирована не только на реагирование, но и на устойчивость. Именно поэтому зрелые команды автоматизируют обработку CVE, интегрируют базы угроз в CMDB, ставят контрольные точки на инвентаризацию, отслеживают не только патчи, но и признаки эксплуатации.
Иногда мы тратим ресурсы на поиски несуществующих уязвимостей, не замечая, что давно раскрытые – все еще в активе у злоумышленников. 1-day – это не техническая ошибка, это организационная слепота. И пока она сохраняется, никакая SIEM, никакой SOC не закроют то, что уже открыто.