Анализ разрыва между обнаружением и устранением уязвимостей
За последний год команды безопасности на нашей платформе сократили время на устранение критических уязвимостей примерно на 50%. В тот же самый период их бэклог нерешенных критических уязвимостей вырос почти в 29 раз. Эти цифры описывают проблему, с которой предстоит столкнуться каждому ИБ-директору.
Сегодня искусственный интеллект способен тестировать программное обеспечение в масштабах, недоступных для ручного тестирования. Модели анализируют код и сканируют тысячи активов на предмет известных паттернов уязвимостей, выявляя угрозы раньше и быстрее, чем любая команда специалистов. Для бизнеса, пытающегося успеть за постоянно расширяющейся поверхностью атаки, это преимущество является по-настоящему ценным.
Однако ИИ вскрывает слабость, которой уделялось гораздо меньше внимания: большинство организаций не способны валидировать, приоритизировать и устранять находки со скоростью, близкой к той, с которой их генерирует ИИ. По мнению CEO HackerOne, именно этот дисбаланс сейчас определяет всю ситуацию в отрасли. Инвестиции в инструменты обнаружения на базе ИИ сами по себе не делают организацию более защищенной — они лишь увеличивают объем работы. Если оставить эту проблему без внимания, команды безопасности окажутся с огромными бэклогами, уделяя меньше времени тем дефектам, которые действительно создают бизнес-риски.
Решение проблемы через управление угрозами
Для решения этой задачи существует Continuous Threat Exposure Management (CTEM). CTEM предоставляет организациям непрерывный процесс понимания поверхности атаки, поиска слабых мест, доказательства их эксплуатируемости и направления усилий по исправлению на те риски, которые несут наибольшую угрозу для бизнеса. Обнаружение — это лишь один из этапов, а реальное преимущество дает все, что происходит после него.
Разрыв между обнаружением и исправлением увеличивается. Долгое время лидеры ИБ рассматривали обнаружение как проблему пропускной способности: протестировать больше активов, покрыть больше кода, обнаружить слабости раньше. ИИ дает решительный ответ на этот вопрос. Но обнаружение потенциальной уязвимости — это начало работы, а не ее конец. Каждую находку необходимо подтвердить как эксплуатируемую и оценить её критичность в конкретном контексте функционирования технологии. Затем информация должна попасть к соответствующей команде инженеров, выиграть конкуренцию с текущими приоритетами, быть исправленной и повторно протестированной для подтверждения эффективности фикса. ИИ сжимает первый шаг, но почти не затрагивает остальные.
Именно поэтому два начальных показателя могут быть правдивы одновременно: рост количества находок свидетельствует об улучшении покрытия, а ускорение ремонта может сопровождаться растущим бэклогом, если обнаружение опережает темпы исправления, а инженерные мощности не растут пропорционально. Ни одна из этих цифр сама по себе не имеет большого значения. Важен только полный цикл: от первичного детектирования до верифицированного исправления.
Валидация как «бутылочное горлышко»
ИИ также снизил стоимость создания убедительных отчетов по безопасности. Некоторые из них указывают на реальные уязвимости, другие дублируют известные находки, неверно интерпретируют цель или описывают теоретические проблемы с низким уровнем риска. Тем не менее, каждую из них приходится исследовать. Отчет, генерируемый за секунды, может отнимать у опытного аналитика часы времени, прежде чем его можно будет уверенно отбросить.
В масштабах предприятия именно так «закапываются» срочные находки. Достоверно подтвержденная уязвимость с реальным вектором атаки попадает в одну очередь с сотнями заявок, которые звучат правдоподобно, но ведут в никуда. Командам безопасности приходится отделять «золото» ИИ от «мусора» ИИ, решая, какие находки важнее, обладая при этом неизменным объемом инженерных ресурсов.
Владельцам программ нужны четкие стандарты доказательств. От исследователей следует ожидать демонстрации вероятного влияния на бизнес и способа воспроизведения уязвимости, при этом автоматизированные инструменты должны использоваться для повышения качества этих доказательств, а не объема заявок. Постоянный послужной список валидных находок помогает владельцу программы понять, чья работа заслуживает первоочередного внимания. По мере роста числа заявок ценность такого опыта только увеличивается.
Бизнес-контекст как решающий фактор
Техническая критичность — лишь часть данных, необходимых для определения приоритетов. ИИ может сопоставить находку с известными паттернами и проанализировать доступные системы. Однако ему редко доступна полная картина бизнеса: какие сервисы приносят доход, где хранятся регулируемые данные, какие зависимости делают простой наиболее затратным и какие компенсирующие контроли уже существуют.
Более сложная проблема — комбинация угроз. Отдельные находки, выглядящие умеренными, могут сформировать серьезный вектор атаки, если понять взаимодействие систем, злоупотребление правами доступа и сбои контроля на организационных границах. Это человеческая работа. Она эффективнее, когда специалисты подходят к ней разносторонне: один исследователь глубоко изучает контроль доступа, другой — поведение API, третий — способы объединения второстепенных слабостей в цепочки. Такое разнообразие выявляет новые векторы атак, которые пропускает автоматизация и даже продвинутые кибер-модели. Наши данные подтверждают ценность такого подхода.
Экономика и будущее рынка bug bounty в эпоху ИИ
В первом полугодии текущего года исследователи безопасности заработали на платформе H1 более 47 миллионов долларов, что на 25% превышает показатели аналогичного периода прошлого года. Наибольший доход получают те специалисты, которые способны объяснить влияние уязвимости на бизнес и продемонстрировать конкретный механизм ее эксплуатации. Именно здесь эксперты приносят наибольшую пользу программам непрерывного управления воздействием угроз (CTEM): они проверяют, сохраняется ли риск в реальных условиях, и выявляют взаимосвязи между уязвимостями, которые по отдельности могут казаться безобидными.
Однако этот финансовый показатель требует важного уточнения: рост совокупных заработков не означает, что каждый исследователь увеличил свой доход. По мере того как ИИ берет на себя обнаружение рутинных, часто встречающихся уязвимостей, специалисты, которые ранее зарабатывали на таких находках, первыми ощущают изменения. В то же время ценность работы тех, кто умеет выстраивать цепочки уязвимостей, анализировать бизнес-логику и предоставлять убедительные доказательства, растет.
Взаимные обязательства платформ и исследователей
Задача любой серьезной платформы bug bounty — превратить этот процесс в управляемый переход для своего сообщества, а не в непреодолимое препятствие. Это обязательство работает в обе стороны. Если программы требуют от исследователей повышения качества доказательной базы, то исследователи вправе ожидать взамен быстрой и справедливой триажи, возможности оспорить неправомерно отклоненные отчеты, а также открытости к приему новичков, еще не успевших заработать репутацию. Лучшие исследователи все чаще используют ИИ-инструменты сами, и ценность отчета никогда не зависела от того, помог ли инструмент в его создании. Защита экономической модели и принципов справедливости, поощряющих достоверную работу, позволяет сообществу независимых исследователей укрепляться по мере масштабирования ИИ, а не сокращаться.
От обнаружения к реагированию
Значит ли это, что эпоха bug bounty подошла к концу? Отнюдь нет. Стоит исходить из того, что темпы обнаружения уязвимостей будут только ускоряться, поэтому основные усилия следует направить на этапы, следующие за находкой. Увеличение количества обнаружений создает дополнительную нагрузку на этапе проверки отчетов и их передачи инженерам. Без достаточных мощностей для триажи качественно подтвержденные находки простаивают среди «шума», создаваемого автоматизированными системами. Без четкого распределения ответственности подтвержденные риски остаются в «серой зоне» между отделами безопасности и разработки.
Независимая проверка важна и на конечном этапе, особенно когда ИИ-система предлагает исправление и может обладать теми же «слепыми зонами» при оценке эффективности этого решения. Руководству и советам директоров нужны метрики, основанные на снижении рисков, а не на активности. Количество найденных багов — простой показатель, который может расти даже тогда, когда организация становится более защищенной. Реальную картину отражают такие параметры, как подтвержденная возможность эксплуатации, скорость устранения, частота повторного возникновения проблем и объем нерешенного критического бэклога.
Концепция CTEM объединяет эти действия в единый непрерывный процесс, связывая обнаружение, валидацию, приоритизацию и устранение по мере изменения поверхности атаки. Это дает лидерам по безопасности честное представление о том, где они добиваются успехов, а где риски продолжают накапливаться. Следующий этап развития безопасности в эпоху ИИ будет выигран не за счет обнаружения — этот этап уже пройден, так как находки стали массовыми. Он будет выигран за счет реагирования: способности понимать, какие находки представляют реальную угрозу, и оперативно доводить самые опасные из них до подтвержденного исправления.
ИИ обеспечивает масштаб. Независимые исследователи обеспечивают суждение и творческий подход, который пока недоступен нейросетям. Организации, которые выстроят процессы так, чтобы конвертировать оба этих фактора в реальные действия, вырвутся вперед. Те, кто этого не сделает, столкнутся с ростом списка неисправленных уязвимостей.
