Что на самом деле изменилось за двадцать пять лет
ILOVEYOU и его последователи научили индустрию простой вещи: масштаб атаки определяется не сложностью эксплойта, а готовностью человека кликнуть по вложению. Сегодняшние AI-инструменты для «безопасного кодинга» решают другую задачу — они ищут уязвимости в исходном коде быстрее, чем это делают классические сканеры, и предлагают исправления до того, как код попадёт в продакшн. Ли формулирует это осторожно: он надеется, что ИИ облегчит написание безопасного кода и устранение уязвимостей до релиза, но прямо признаёт, что не ждёт от ИИ помощи в формулировании правильных требований и уж тем более — в защите пользователей от манипуляций. Это разграничение задаёт всю логику дальнейшего разбора: ускорение анализа кода и снижение реального риска — вещи связанные, но не тождественные.
Показательно, что сам Ли сравнивает нынешнее поколение AI-агентов с ранним интернетом — «грубым и несовершенным наброском будущего». Это честная формулировка, но она же и предупреждение: ранний интернет тоже казался технологией, которая автоматически сделает мир лучше, а вместо этого принёс мемы, дезинформацию и промышленный спам. История повторяет не конкретные угрозы, а структуру завышенных ожиданий.
Threat hunting: усилитель, а не подмена гигиены
Параллельно с разговором о коде стоит вспомнить другую линию защиты — охоту за угрозами, threat hunting. Ли описывает её точной метафорой: команды threat hunting — это «летучий отряд» кибербезопасности, аналог оперативной полиции, которую вызывают, когда обычные патрули уже не справляются. Ключевая оговорка здесь важнее самой метафоры: большинство организаций получили бы наибольший прирост защищённости, просто устранив базовые слабости, и только после достижения определённой зрелости имеет смысл держать отдельную команду для выявления следов самых изощрённых атакующих.
Иными словами, threat hunting не заменяет патчи, управление доступом и мониторинг журналов — он компенсирует то, что остаётся незамеченным после того, как базовая гигиена уже выполнена. И даже здесь автоматизация работает не как замена человека, а как его усилитель: алгоритмы просеивают огромные объёмы данных, чтобы найти аномалии, а решение о том, что с этой аномалией делать, по-прежнему требует человеческой интуиции и понимания более широкой картины. Эта же логика — «машины масштабируют, люди понимают контекст» — почти дословно повторяется двадцать лет спустя в спорах вокруг AI-детекции уязвимостей.
AI ищет уязвимости иначе, но не одинаково хорошо во всём
Современные AI-инструменты анализа кода действительно расширяют охват по сравнению с классическими сканерами на фиксированных правилах: они работают с семантическими представлениями кода, а не только с синтаксическими шаблонами, и поэтому способны отслеживать связи между функциями и файлами, которые обычный статический анализатор попросту не видит. Но независимые сравнения показывают устойчивый компромисс: языковые модели чаще повышают полноту обнаружения (recall), тогда как детерминированные инструменты лучше сдерживают число ложных срабатываний. При этом результаты, показанные на «причёсанных» тестовых наборах, заметно проседают на более реалистичных бенчмарках и в реальном коде — разрыв между демонстрацией и продакшном остаётся системной проблемой, а не курьёзом.
Важно и то, что надёжность AI-детекции сильно различается по классам уязвимостей. Там, где сигналы явные — инъекции, некорректное использование криптографии — автоматический анализ работает уверенно. А там, где нужно понимать замысел бизнес-логики или границы полномочий — например, в случаях нарушенного контроля доступа или CSRF, — даже профильные источники по AI-безопасности признают ограниченную эффективность автоматического анализа. Это прямо возражает соблазнительному, но неточному тезису «ИИ теперь ловит всё одинаково хорошо»: возможности инструмента определяются не общей мощностью модели, а тем, насколько формализуемы признаки конкретного класса ошибки.
| Направление | Что было раньше | Что меняет ИИ | Что остаётся прежним |
|---|---|---|---|
| Поиск уязвимостей в коде | Правила и сигнатуры, ручное ревью | Быстрее находит семантические связи между файлами | Точность зависит от архитектурного контекста и класса уязвимости |
| Threat hunting | Редкая экспертная практика | Алгоритмы просеивают больше данных за меньшее время | Решение о реагировании остаётся за аналитиком |
| Реагирование на инциденты | Ручное расследование логов | Ускоряет сбор контекста и корреляцию событий | Скорость атакующих тоже растёт вместе со скоростью защиты |
| Человеческая ошибка | Клик по вложению, слабый пароль | Не решается моделью анализа кода | Пользователь остаётся главной точкой входа |
| Требования и архитектура | Ошибки закладываются на этапе проектирования | Модель не формулирует требования за команду | Неверно поставленная задача даёт уязвимый результат при любом инструменте |
Где безопасность реально теряется сегодня
Свежие данные по реагированию на инциденты подтверждают, что фокус атак сместился туда, где код вообще не главный герой. По оценке одного из крупных отчётов индустрии, слабости, связанные с идентификацией и доступом, сыграли существенную роль почти в 90% расследованных инцидентов, а большая часть первоначального доступа достигается через кражу учётных данных, а не через эксплуатацию уязвимого кода. Параллельно растёт доля инцидентов, связанных с SaaS-интеграциями и цепочками поставок: доверенные подключения через OAuth и API оказываются удобным путём для атакующего именно потому, что выглядят как обычная автоматизация. Более 90% нарушений, по тем же данным, были связаны не с изощрённостью атакующих, а с предотвратимыми пробелами — недостаточной видимостью, непоследовательно применяемыми контролями, избыточным доверием к идентификаторам. AI при этом действует на обеих сторонах: он ускоряет уже знакомые техники атаки не менее охотно, чем ускоряет защиту.
Схема одна, точки вмешательства разные
Полезно представить путь от уязвимого кода до инцидента как последовательность стадий — тогда видно, что автоматизация помогает не везде одинаково.
flowchart TD A[Написание кода] --> B[Ревью и CI/CD] B --> C[Продакшн] C --> D[Мониторинг] D --> E[Расследование] E --> F[Реагирование] F --> G[Обучение и правила]
ИИ заметно ускоряет ранние и поздние этапы — поиск подозрительного паттерна при ревью и сопоставление сигналов при расследовании. Но между продакшном и мониторингом лежит зона, которую ни один алгоритм не закрывает сам: правильно ли сформулированы требования, не доверяет ли система лишнего стороннему сервису, не откроет ли сотрудник фишинговое письмо. Эти разрывы — не следствие незрелости конкретного инструмента, а структурная особенность любой системы, где решения принимают люди.
Что из этого следует
Главный сдвиг, который стоит признать честно: кибербезопасность не стала принципиально надёжнее — она стала быстрее и сложнее одновременно. AI-ассистенты действительно расширяют охват анализа кода и ускоряют реагирование, threat hunting действительно ловит то, что пропускают автоматические фильтры. Но ни один из этих инструментов не отменяет старую формулу, которую двадцать лет назад открыл для себя вчерашний исследователь жизни, а сегодня — эксперт по угрозам: сложнее всего в защите не написать код, а верно понять, что именно нужно защитить, и не дать человеку ошибиться. Пока это так, самая честная оценка любого нового AI-инструмента безопасности — не «заменяет ли он специалистов», а «на сколько шагов вперёд он позволяет им действовать быстрее людей, которые всё равно должны проверить результат».
