Индустрия наступательной безопасности столкнулась со странным парадоксом. Инструменты на основе искусственного интеллекта научились читать код за секунды, генерировать payload'ы, объяснять незнакомые API и прогонять рутинные тесты со скоростью, недоступной человеку ещё пару лет назад. Казалось бы, отличная новость для пентестеров и охотников за багами. Но вместе с этим появилась новая проблема: отчётов, которые выглядят как находки, стало кратно больше, а вот находок, которые реально подтверждены, — нет.
Сгенерированный отчёт может быть отполирован до блеска: с оценкой серьёзности, с proof-of-concept, который на первый взгляд выглядит логично. Но ничего из этого не доказывает, что баг существует в реальном развёрнутом окружении, что он эксплуатируем, и что у него есть хоть какое-то практическое влияние. Написать текст, похожий на отчёт об уязвимости, никогда не было сложной задачей. Сложность всегда была в другом — показать, что написанное действительно правда.
Проблема уже не теоретическая. Программы bug bounty и мейнтейнеры open-source проектов захлёбываются потоком низкокачественных отчётов, сгенерированных нейросетями: тонкие доказательства, шаблонные формулировки, минимум реальной проверки. Bugcrowd открыто озвучила эту проблему, изменив политику приёма отчётов, созданных с помощью ИИ. Компания описала ситуацию просто — такие отчёты выглядят опрятно, но создают лишнюю нагрузку на триаж, вместо того чтобы давать полезный сигнал о безопасности. И это не узкая проблема одной платформы для баунти. Это репетиция того, что будет происходить везде, где ИИ генерирует находки без человеческой проверки — а команды безопасности и так завалены выводами сканеров, алертами о зависимостях, проблемами конфигурации облака и результатами compliance-проверок.
Модели неплохо объясняют, почему что-то может быть плохо, но часто упускают условия, которые определяют, важно ли это на самом деле. Пользовательский ввод рядом с SQL-запросом — модель тут же подсказывает SQL-инъекцию. Загрузка URL — сразу SSRF. Опасная функция где-то в цепочке вызовов — готово, RCE. Проблема в том, что реальный тестировщик всё ещё обязан ответить на вопросы, которые ИИ обычно не задаёт: доходит ли контролируемый атакующим ввод до опасной операции, требуется ли аутентификация, проверяется ли авторизация где-то ещё, включена ли уязвимая функция вообще, открывает ли продакшн-конфигурация этот путь выполнения, санитизируется ли payload перед обработкой. Вывод ИИ — это наводка, которую стоит проверить, а не готовый вердикт, который можно пересылать заказчику.
Именно поэтому знания опытных специалистов никуда не делись в цене. Лучшие практики в этой области ценны не потому, что умеют запускать инструменты, а потому, что понимают системы изнутри. История давно знает подобные ситуации: веб-сканер помечает отражающийся параметр, статический анализатор находит опасную функцию, фаззер выдаёт краш — и всё это всегда требовало человеческой интерпретации. Языковая модель, описывающая правдоподобный путь атаки, — просто новая версия того же самого. Старшие исследователи наработали свою экспертизу годами: трассировкой запросов, чтением исходного кода, реверс-инжинирингом бинарников, отладкой крашей, написанием эксплойтов, взломом схем аутентификации. Это формирует память и интуицию — понимание, когда находка настоящая, когда инструмент ошибся, а когда мелкие баги складываются в серьёзную цепочку. Такое знание видно в том, какие вопросы задаёт тестировщик, как он пишет отчёт, может ли объяснить путь эксплуатации без общих фраз — и особенно в том, как он действует, когда первая попытка проваливается.
Существует и обратная сторона: чрезмерная зависимость от ИИ рискует притупить навыки. Речь не об анти-ИИ позиции, а о простом наблюдении за человеческим обучением. Когда инструмент отвечает мгновенно, перестаёшь запоминать детали. Когда он пишет первую версию каждого скрипта, перестаёшь практиковаться. Когда он объясняет каждый путь в коде, каждый payload, каждую ошибку — перестаёшь строить в голове модель системы. А наступательная безопасность вознаграждает именно глубину, распознавание паттернов и техническую память. Самые сложные находки рождаются из способности заметить нарушение границ между разными доменами — связи между парсерами, фреймворками, аллокаторами памяти, провайдерами идентификации и системами авторизации. Суть риска можно сформулировать так: люди позволяют ИИ слишком рано брать на себя мышление, а потом путают беглость формулировок с компетентностью. Промптинг полезен, но он не заменяет суждение.
При этом маркетинг вокруг ИИ в безопасности часто рисует картину какого-то нового типа рассуждений, хотя на практике большинство рабочих процессов остаются классическими: перечислить эндпоинты, изучить параметры, отследить поток данных, сравнить поведение с аутентификацией и без неё, сгенерировать payload'ы, прогнать фаззер, посмотреть на отклик, определить значимые изменения состояния. Реальный вклад ИИ — оркестрация известных техник в масштабе: планирование, выполнение, наблюдение и итерация происходят быстрее. Но проблемы авторизации всё равно требуют анализа связей между объектами, повреждение памяти — оценки достижимости, контекста краша и реальной эксплуатируемости, а слабости API — понимания, какая модель доверия нарушена. Лучшее применение ИИ — снять с тестировщика механическую работу, чтобы он сосредоточился на анализе и проверке, а не на замене процесса принятия решений.
Хорошая проверка находки конкретна, воспроизводима и привязана к реальному влиянию. Здесь важно чёткое разграничение: наводка — это то, что стоит исследовать, а подтверждённая находка — то, что проверено и доказано. Переход от одного к другому требует доказательств, и на практике это сводится к семи вопросам: какое конкретное поведение наблюдалось и где; какой контролируемый атакующим ввод, личность или состояние для этого потребовались; какая граница безопасности была нарушена — аутентификация, авторизация, изоляция арендаторов, доверие, привилегии, безопасность памяти; какие точные шаги воспроизводят поведение в целевом окружении; каково доказанное влияние, а не теоретический худший сценарий; какие доказательства подтверждают, что проблема достижима в развёрнутой конфигурации; и что именно должно измениться при исправлении, чтобы команда могла подтвердить, что фикс сработал.
Человеческая проверка — это не административная формальность, а полноценная техническая работа. Ошибки авторизации требуют анализа бизнес-логики и связей между объектами. Уязвимости API — понимания ролей, арендаторов и взаимодействия ресурсов. Повреждение памяти — анализа состояния краша, контроля над ним, работающих защитных механизмов и примитивов эксплуатации. Облачные находки — понимания модели идентификации, политик доверия и специфического поведения конкретного сервиса. Чем выше потенциальное влияние находки, тем важнее становится человеческая проверка, потому что решения об инженерных приоритетах, доверии клиентов, соблюдении требований и рисках на уровне руководства должны опираться на доказательства, а не на уверенные догадки.
Отдельная беда — завышение серьёзности. Отражённый ввод — не XSS, пока не продемонстрировано выполнение скрипта. Загрузка URL — не значимый SSRF, пока не показан несанкционированный доступ. Опасная функция — не RCE, пока не доказаны достижимость, контроль и фактическое выполнение кода. Известны случаи, когда находке присваивали CVSS 9.8, хотя она вообще могла не быть валидной уязвимостью. Влияние нужно заслужить доказательствами: баг, доступный только администратору, не равен по риску багу, открытому в интернет без аутентификации; краш может быть отказом в обслуживании, путём к выполнению кода или просто безобидной проблемой стабильности — всё зависит от контекста; отсутствующая проверка может быть серьёзной уязвимостью, а может быть прикрыта другим контролем — узнать это можно только через проверку. Компания Tenable недавно поднимала похожие вопросы, указывая на то, что критические комбинации контекста часто упускаются при автоматизированном анализе. Грамотная проверка защищает и от занижения рисков, и от их раздувания.
Итоговый рецепт для команд — не отказ от ИИ, а его использование так, чтобы усиливать специалистов, а не заменять их мышление. Начинающим тестировщикам стоит освоить фундаментальные навыки прежде, чем передавать задачи модели. Опытным — использовать ИИ как усилитель, а не как источник истины в последней инстанции. Руководителям безопасности стоит проверять не количество сгенерированных находок, а способность тестировщика объяснить и воспроизвести каждую из них. Здоровая программа с использованием ИИ вознаграждает подтверждённое влияние, а не объём отчётов, измеряет качество сигнала, сохраняет ручную практику в манипуляции запросами, код-ревью, отладке, разработке эксплойтов и анализе угроз — и использует подсказки модели как повод для обучения: если ИИ предполагает проблему, тестировщик должен спросить себя почему, проверить утверждение и извлечь урок из результата.
ИИ продолжит совершенствоваться — в навигации по коду, в анализе payload'ов, в документации. Но наступательная безопасность не может превратиться в игру на объём, где каждая правдоподобная теория становится чужой проблемой на этапе триажа. Стандарт не изменился: докажи, что баг существует. Докажи, что атакующий может до него дотянуться. Докажи влияние. Докажи бизнес-риск. Докажи, что фикс работает. ИИ лишь повышает важность соблюдения этого стандарта, потому что убедительный, но недоказанный вывод теперь производится легче, чем когда-либо. Лучшие исследователи и команды будущего будут сочетать автоматизацию с техническим суждением, используя машины для ускорения работы, но не отдавая им последнее слово. Знания по-прежнему важны, потому что важна проверка, а в наступательной безопасности проверка — это граница между шумом и истиной.
Эта тема получит развитие в курсе SEC660: Advanced Penetration Testing, Exploit Writing, and Ethical Hacking, обновлённая версия которого будет представлена на SANS Network Security 2026. Программа курса сочетает ручное понимание сложных тем вроде написания эксплойтов с обучением тому, как использовать ИИ для автоматизации отдельных задач.
Сгенерированный отчёт может быть отполирован до блеска: с оценкой серьёзности, с proof-of-concept, который на первый взгляд выглядит логично. Но ничего из этого не доказывает, что баг существует в реальном развёрнутом окружении, что он эксплуатируем, и что у него есть хоть какое-то практическое влияние. Написать текст, похожий на отчёт об уязвимости, никогда не было сложной задачей. Сложность всегда была в другом — показать, что написанное действительно правда.
Проблема уже не теоретическая. Программы bug bounty и мейнтейнеры open-source проектов захлёбываются потоком низкокачественных отчётов, сгенерированных нейросетями: тонкие доказательства, шаблонные формулировки, минимум реальной проверки. Bugcrowd открыто озвучила эту проблему, изменив политику приёма отчётов, созданных с помощью ИИ. Компания описала ситуацию просто — такие отчёты выглядят опрятно, но создают лишнюю нагрузку на триаж, вместо того чтобы давать полезный сигнал о безопасности. И это не узкая проблема одной платформы для баунти. Это репетиция того, что будет происходить везде, где ИИ генерирует находки без человеческой проверки — а команды безопасности и так завалены выводами сканеров, алертами о зависимостях, проблемами конфигурации облака и результатами compliance-проверок.
Модели неплохо объясняют, почему что-то может быть плохо, но часто упускают условия, которые определяют, важно ли это на самом деле. Пользовательский ввод рядом с SQL-запросом — модель тут же подсказывает SQL-инъекцию. Загрузка URL — сразу SSRF. Опасная функция где-то в цепочке вызовов — готово, RCE. Проблема в том, что реальный тестировщик всё ещё обязан ответить на вопросы, которые ИИ обычно не задаёт: доходит ли контролируемый атакующим ввод до опасной операции, требуется ли аутентификация, проверяется ли авторизация где-то ещё, включена ли уязвимая функция вообще, открывает ли продакшн-конфигурация этот путь выполнения, санитизируется ли payload перед обработкой. Вывод ИИ — это наводка, которую стоит проверить, а не готовый вердикт, который можно пересылать заказчику.
Именно поэтому знания опытных специалистов никуда не делись в цене. Лучшие практики в этой области ценны не потому, что умеют запускать инструменты, а потому, что понимают системы изнутри. История давно знает подобные ситуации: веб-сканер помечает отражающийся параметр, статический анализатор находит опасную функцию, фаззер выдаёт краш — и всё это всегда требовало человеческой интерпретации. Языковая модель, описывающая правдоподобный путь атаки, — просто новая версия того же самого. Старшие исследователи наработали свою экспертизу годами: трассировкой запросов, чтением исходного кода, реверс-инжинирингом бинарников, отладкой крашей, написанием эксплойтов, взломом схем аутентификации. Это формирует память и интуицию — понимание, когда находка настоящая, когда инструмент ошибся, а когда мелкие баги складываются в серьёзную цепочку. Такое знание видно в том, какие вопросы задаёт тестировщик, как он пишет отчёт, может ли объяснить путь эксплуатации без общих фраз — и особенно в том, как он действует, когда первая попытка проваливается.
Существует и обратная сторона: чрезмерная зависимость от ИИ рискует притупить навыки. Речь не об анти-ИИ позиции, а о простом наблюдении за человеческим обучением. Когда инструмент отвечает мгновенно, перестаёшь запоминать детали. Когда он пишет первую версию каждого скрипта, перестаёшь практиковаться. Когда он объясняет каждый путь в коде, каждый payload, каждую ошибку — перестаёшь строить в голове модель системы. А наступательная безопасность вознаграждает именно глубину, распознавание паттернов и техническую память. Самые сложные находки рождаются из способности заметить нарушение границ между разными доменами — связи между парсерами, фреймворками, аллокаторами памяти, провайдерами идентификации и системами авторизации. Суть риска можно сформулировать так: люди позволяют ИИ слишком рано брать на себя мышление, а потом путают беглость формулировок с компетентностью. Промптинг полезен, но он не заменяет суждение.
При этом маркетинг вокруг ИИ в безопасности часто рисует картину какого-то нового типа рассуждений, хотя на практике большинство рабочих процессов остаются классическими: перечислить эндпоинты, изучить параметры, отследить поток данных, сравнить поведение с аутентификацией и без неё, сгенерировать payload'ы, прогнать фаззер, посмотреть на отклик, определить значимые изменения состояния. Реальный вклад ИИ — оркестрация известных техник в масштабе: планирование, выполнение, наблюдение и итерация происходят быстрее. Но проблемы авторизации всё равно требуют анализа связей между объектами, повреждение памяти — оценки достижимости, контекста краша и реальной эксплуатируемости, а слабости API — понимания, какая модель доверия нарушена. Лучшее применение ИИ — снять с тестировщика механическую работу, чтобы он сосредоточился на анализе и проверке, а не на замене процесса принятия решений.
Хорошая проверка находки конкретна, воспроизводима и привязана к реальному влиянию. Здесь важно чёткое разграничение: наводка — это то, что стоит исследовать, а подтверждённая находка — то, что проверено и доказано. Переход от одного к другому требует доказательств, и на практике это сводится к семи вопросам: какое конкретное поведение наблюдалось и где; какой контролируемый атакующим ввод, личность или состояние для этого потребовались; какая граница безопасности была нарушена — аутентификация, авторизация, изоляция арендаторов, доверие, привилегии, безопасность памяти; какие точные шаги воспроизводят поведение в целевом окружении; каково доказанное влияние, а не теоретический худший сценарий; какие доказательства подтверждают, что проблема достижима в развёрнутой конфигурации; и что именно должно измениться при исправлении, чтобы команда могла подтвердить, что фикс сработал.
Человеческая проверка — это не административная формальность, а полноценная техническая работа. Ошибки авторизации требуют анализа бизнес-логики и связей между объектами. Уязвимости API — понимания ролей, арендаторов и взаимодействия ресурсов. Повреждение памяти — анализа состояния краша, контроля над ним, работающих защитных механизмов и примитивов эксплуатации. Облачные находки — понимания модели идентификации, политик доверия и специфического поведения конкретного сервиса. Чем выше потенциальное влияние находки, тем важнее становится человеческая проверка, потому что решения об инженерных приоритетах, доверии клиентов, соблюдении требований и рисках на уровне руководства должны опираться на доказательства, а не на уверенные догадки.
Отдельная беда — завышение серьёзности. Отражённый ввод — не XSS, пока не продемонстрировано выполнение скрипта. Загрузка URL — не значимый SSRF, пока не показан несанкционированный доступ. Опасная функция — не RCE, пока не доказаны достижимость, контроль и фактическое выполнение кода. Известны случаи, когда находке присваивали CVSS 9.8, хотя она вообще могла не быть валидной уязвимостью. Влияние нужно заслужить доказательствами: баг, доступный только администратору, не равен по риску багу, открытому в интернет без аутентификации; краш может быть отказом в обслуживании, путём к выполнению кода или просто безобидной проблемой стабильности — всё зависит от контекста; отсутствующая проверка может быть серьёзной уязвимостью, а может быть прикрыта другим контролем — узнать это можно только через проверку. Компания Tenable недавно поднимала похожие вопросы, указывая на то, что критические комбинации контекста часто упускаются при автоматизированном анализе. Грамотная проверка защищает и от занижения рисков, и от их раздувания.
Итоговый рецепт для команд — не отказ от ИИ, а его использование так, чтобы усиливать специалистов, а не заменять их мышление. Начинающим тестировщикам стоит освоить фундаментальные навыки прежде, чем передавать задачи модели. Опытным — использовать ИИ как усилитель, а не как источник истины в последней инстанции. Руководителям безопасности стоит проверять не количество сгенерированных находок, а способность тестировщика объяснить и воспроизвести каждую из них. Здоровая программа с использованием ИИ вознаграждает подтверждённое влияние, а не объём отчётов, измеряет качество сигнала, сохраняет ручную практику в манипуляции запросами, код-ревью, отладке, разработке эксплойтов и анализе угроз — и использует подсказки модели как повод для обучения: если ИИ предполагает проблему, тестировщик должен спросить себя почему, проверить утверждение и извлечь урок из результата.
ИИ продолжит совершенствоваться — в навигации по коду, в анализе payload'ов, в документации. Но наступательная безопасность не может превратиться в игру на объём, где каждая правдоподобная теория становится чужой проблемой на этапе триажа. Стандарт не изменился: докажи, что баг существует. Докажи, что атакующий может до него дотянуться. Докажи влияние. Докажи бизнес-риск. Докажи, что фикс работает. ИИ лишь повышает важность соблюдения этого стандарта, потому что убедительный, но недоказанный вывод теперь производится легче, чем когда-либо. Лучшие исследователи и команды будущего будут сочетать автоматизацию с техническим суждением, используя машины для ускорения работы, но не отдавая им последнее слово. Знания по-прежнему важны, потому что важна проверка, а в наступательной безопасности проверка — это граница между шумом и истиной.
Эта тема получит развитие в курсе SEC660: Advanced Penetration Testing, Exploit Writing, and Ethical Hacking, обновлённая версия которого будет представлена на SANS Network Security 2026. Программа курса сочетает ручное понимание сложных тем вроде написания эксплойтов с обучением тому, как использовать ИИ для автоматизации отдельных задач.