Российский рынок багбаунти за несколько лет прошел путь от узкоспециализированного инструмента до одного из основных элементов зрелой кибербезопасности. Растет число компаний-заказчиков, а вместе с этим увеличивается число исследователей и меняются подходы к поиску уязвимостей. Руководитель продукта BI.ZONE Bug Bounty Андрей Лёвкин рассказал, как развивается рынок, какую роль в нем играет ИИ и что организациям необходимо сделать перед запуском багбаунти.
Как развивается рынок багбаунти в России
Платформа BI.ZONE Bug Bounty была запущена в 2022 году, и за время работы ее специалисты выявили несколько тенденций, связанных с организациями и исследователями.
Во-первых, многие компании в России имеют достаточно зрелую кибербезопасность, чтобы запускать программы, развивать эту сферу и участвовать в жизни комьюнити. На платформу приходят вендоры из разных отраслей, но, конечно, больше всего из бигтеха, финтеха и ИТ. В ряде отраслей внедрение таких программ происходит медленнее из-за особенностей регулирования и специфики взаимодействия с независимыми исследователями. При этом багбаунти становится более понятным, проверенным и доступным для рынка.
Во-вторых, меняется и сообщество независимых исследователей. Оно постепенно растет — и количественно, и с точки зрения экспертного опыта. За последний год количество исследователей на BI.ZONE Bug Bounty увеличилось на четверть. Традиционно эта сфера привлекает молодых специалистов, но сейчас средний возраст участников комьюнити растет.
Интересно, что многие бывшие багхантеры теперь выступают с другой стороны: запускают программы в компаниях и выстраивают внутренние процессы работы с исследователями.
Что чаще всего находят багхантеры
По статистике BI.ZONE и по данным зарубежных платформ, перечень уязвимостей, которые находят в рамках багбаунти, из года в год меняется незначительно. Этот набор примерно соответствует OWASP Top 10, отражая общие тенденции в безопасности веб-приложений.
При этом по количеству среди обнаруженных багов есть заметный перекос в сторону уязвимостей бизнес-логики, а не технических проблем вроде SQL-инъекций, RCE или SSTI. Это связано с тем, что типовые технические уязвимости выявляются еще на этапах разработки и тестирования, тогда как ошибки бизнес-логики менее формализуемые, поэтому требуют ручного анализа. Тенденция характерна не только для российского рынка, но и для мировой практики.
Некоторые типы уязвимостей можно обнаружить реже из-за устаревания технологий. Например, XXE с каждым годом встречается все реже, потому что формат XML постепенно остается только в легаси-системах. В современных решениях его практически не используют: большинство компаний перешло на JSON или Protobuf.
Какой путь проходит найденная уязвимость
После получения отчета специалисты компании-заказчика проверяют, не является ли находка дубликатом и не была ли эта уязвимость известна ранее. Они оценивают, действительно ли она создает бизнес-риски, а не представляет собой ожидаемое поведение системы. То есть определяют, действительно ли это уязвимость, а не особенность реализации. После этого уязвимость включают в план исправления.
Затем начинается другой важный этап — проверка, не затрагивает ли проблема другие продукты. Большинство компаний используют одинаковые компоненты и внутренние разработки в нескольких сервисах. Поэтому, если уязвимость обнаружена в одном компоненте, велика вероятность, что аналогичная проблема есть и в других продуктах.
Исследователь обычно не видит этой работы: для него процесс заканчивается назначением вознаграждения. Но для компании работа продолжается и дальше. Необходимо убедиться, что уязвимость действительно устранена и проблема не возникает повторно. Иногда для этого снова привлекают самого исследователя и просят подтвердить корректность исправления.
Почему меняется оценка критичности бага
Типичная ситуация — когда оценка критичности уязвимостей меняется после более глубокого анализа. Исследователь может обнаружить проблему, но не понять ее реальную ценность. У него нет полного представления о внутреннем устройстве сервиса, используемых технологиях и особенностях инфраструктуры. А внутренняя команда хорошо понимает архитектуру продукта и может глубже исследовать найденную уязвимость.
Например, исследователь обнаружил возможность получить токен, но не смог определить, для чего он используется, как применить его на практике. Внутренняя команда выяснила, что это токен с административными привилегиями, который подходит для доступа к большинству сервисов компании и представляет собой критически важный элемент инфраструктуры.
Если бы таким токеном завладели злоумышленники, они могли бы выполнить множество потенциально опасных действий. Так что уровень критичности уязвимости был пересмотрен: изначальная оценка была повышена, а вместе с ней выросло и вознаграждение исследователя. Он нашел настоящее золото, хотя сам этого не осознавал.
Как искусственный интеллект трансформирует багбаунти
Тренд последних пары лет — AI-assisted-разработка. Нейросети стали достаточно умными, чтобы работать с большим объемом контекста и понимать, что именно нужно сделать. Но пока неясно, как изменилось из-за этого количество уязвимостей.
Многие компании стремятся к модели, в которой разработчик не пишет код вручную, а использует ИИ-ассистента. Предполагается, что такой ассистент уже учитывает требования к защите и помогает сразу генерировать более безопасный код. Параллельно развивается и другое направление — интеграция ИИ в CI/CD-процессы на протяжении всего жизненного цикла разработки и релиза.
Нейросети начали использовать и для поиска уязвимостей. Это приводит к тому, что в багбаунти приходят неподготовленные люди, которые считают, что с помощью ИИ можно быстро найти уязвимость и заработать. Не понимая основ кибербезопасности и контекста, они отправляют десятки бесполезных отчетов.
Это лишь увеличивает нагрузку на команды триажа, которым приходится тратить время на проверку нерелевантных находок. Для борьбы с этим платформы внедряют автоматическую фильтрацию дубликатов и нерелевантных отчетов.
Опытные исследователи используют ИИ иначе. Они могут самостоятельно находить уязвимости или вручную проверять находки, предложенные нейросетью. А затем с помощью ИИ оформлять отчет. Такой подход помогает эффективнее искать уязвимости и экономит время на оформление отчетов.
По каким показателям оценивается рынок и платформа
BI.ZONE оценивает развитие платформы по нескольким ключевым метрикам. В первую очередь это количество полученных и оплаченных отчетов, общий объем выплат, проведенных через платформу, а также количество заказчиков. Если эти показатели стабильно растут из года в год, значит, платформа развивается в правильном направлении.
Еще одна значимая метрика — количество исследователей. Важно отслеживать число активных багхантеров за определенный период. Ведь 20% самых сильных исследователей находят примерно 80% уязвимостей и получают основную часть выплат на платформе.
Постепенно багбаунти становится такой же привычной практикой, как CI/CD или код-ревью. По крайней мере, среди крупных компаний. Важно понимать, что использование багбаунти — это закономерный этап развития кибербезопасности в компании. Но прежде чем запускать программу, необходимо выстроить множество внутренних процессов кибербезопасности. Нужны специалисты, которые смогут анализировать и устранять найденные уязвимости, грамотно ставить задачи разработчикам, приоритизировать работу с багами и организовывать весь процесс работы с находками. Если этого нет, выходить на багбаунти бессмысленно.
Для дальнейшего развития практики багбаунти важно, чтобы платформами пользовалось как можно больше организаций из разных отраслей, включая государственный сектор. В последние годы программы начали запускать отдельные государственные организации и субъекты РФ, что подтверждает растущий интерес к такому формату поиска уязвимостей.
Дальнейшее развитие этого направления во многом будет зависеть от формирования комплексной нормативно-правовой базы, которая позволит расширять практику взаимодействия с независимыми исследователями с учетом требований к информационной безопасности.