ИИ находит уязвимости в коде. Прорыв или очередной хайп?
В феврале Anthropic объявила, что её Claude теперь умеет сканировать кодовые базы на уязвимости и предлагать исправления. Новость тогда немедленно уронила акции компаний, специализирующихся на кибербезопасности — CrowdStrike, Okta, Zscaler просели на 5–9%, IBM вообще потерял 13%. Рынок отреагировал паникой, и это довольно показательно, особенно если внимательно прочитать исходный анонс. Я паниковать не стал, хотя руковожу компанией, основной профиль которой — именно информационная безопасность. Сейчас объясню, почему.
Что произошло на самом деле, а что — медийный шум
В официальном сообщении написано буквально: «Claude Code Security, a new capability built into Claude Code on the web, is now available in a limited research preview» («Функция Claude Code Security, встроенная в веб-версию Claude Code, теперь доступна в ограниченной предварительной версии для разработчиков»). То есть это всего-то бета-тест нового функционала, а не полноценный релиз. Мой опыт говорит о том, что между «мы это показали» и «это работает в продакшене» — дистанция огромного размера, но рынок, судя по всему, эту разницу проигнорировало.
Да, модель нашла более 500 старых и известных уязвимостей в тестовых проектах — звучит впечатляюще. Но вообще-то специализированные инструменты для статического анализа кода (SAST) существуют давно, и среди них есть в том числе и сильные отечественные решения. Например, Application Inspector от Positive Technologies делает то же самое без огромной языковой модели под капотом, с меньшими ресурсами и вполне сопоставимым результатом. Я был бы рад сравнить эти два инструмента на одном тестовом проекте — и мне почему-то кажется, что потенциальный разрыв окажется куда скромнее, чем рисует его маркетинг от Anthropic.
Почему разговор о «прорыве» преждевременен
У LLM есть фундаментальное ограничение — размер контекстного окна. На больших проектах это довольно критично, потому что модель физически не может «удержать в голове» весь код и чаще всего оперирует только двумя-тремя файлами одновременно. Отсюда главная болезнь вайб-кодинга — спагетти-код, слабая связность, отсутствие единой архитектуры. Искать уязвимости в таком коде небесполезно, но называть это системным решением не стоит.
Есть и экономический аспект. Работа с большим контекстом требует серьезных вычислительных мощностей — не компьютера с игровой видеокартой за 300–400 тысяч рублей, а мощного сервера стоимостью в десятки миллионов рублей. Использование ИИ-инструментария в разработке уже сегодня поднимает ее стоимость примерно на 30%, так что для среднего бизнеса это совсем не очевидная инвестиция и пока неоправданная.
Положа руку на сердце, вайб-кодинг сам по себе — это на сегодняшний день «уязвимость как сервис». Инструмент, который генерирует код с дырами, а потом ищет в нем дыры — это не прорыв, это попытка решить проблему, которую он сам же и создает.
Что будет с людьми
Здесь я расхожусь во мнениях с теми, кто рисует апокалиптические сценарии. Полностью заменить разработчиков и специалистов по разработке в области ИБ в ближайшие два года точно не получится — это я могу утверждать с полной уверенностью. Но кое-что все-таки изменится очень быстро, и это важно для отрасли.
ИИ-инструменты для анализа кода снизят порог входа в DevSecOps. Те, кто раньше вообще не думал о безопасности приложений — небольшие независимые команды, стартапы, разработчики нишевых продуктов — начнут использовать автоматизированный аудит хотя бы на базовом уровне. Это реальная польза, и она измерима.
Другой вопрос — что будет с джуниорами. Исправление простых уязвимостей, рефакторинг, первичная отладка — все это ИИ уже делает быстрее и дешевле начинающего специалиста, и рынок труда для входящих в профессию людей объективно сужается. Это не страшилка для СМИ, а уже наблюдаемый факт, который надо принимать во внимание и обдумать заранее. Разумной реакцией на изменившуюся реальность должны стать менторство и переключение джуниоров на задачи, которые машине пока не по зубам: разметку данных, работу с архитектурой, управление рисками.
Что касается серьезных проектов, то сложные контекстные уязвимости, архитектурные решения, ответственность за результат — это никак не автоматизируется нажатием на кнопку, здесь все остается за человеком и останется еще долго.
Регуляторика
Текущие стандарты безопасной разработки всегда сфокусированы на результате, то есть на надлежащем уровне защищенности, а не на средствах его достижения. Поэтому формально ничего менять не нужно. Неважно, проверяли вы код вручную или с помощью ИИ, ответственное лицо остается ответственным лицом.
Но это сегодня. Завтра регуляторы неизбежно захотят понять, каким инструментам можно доверять, как верифицировать их работу и что считать надлежащей проверкой с ИИ-ассистентом — особенно в контексте госзаказа и КИИ, где уже вовсю разворачивается история с требованиями к «суверенным» моделям. Пока ни одна российская разработка этим требованиям не удовлетворяет, так что у отечественных игроков есть одновременно и окно возможностей, и жесткий дедлайн по их реализации.
Что имеем в итоге
Claude Code Security — это хороший и заметный шаг в давно идущей гонке инструментов для анализа кода, но пока не революция, которая в одночасье изменит всю расстановку сил на рынке. Реальные изменения будут, но только постепенные: снижение порога входа в организацию базовой защиты приложений и сервисов, трансформация роли джуниоров и неизбежное движение регуляторов в сторону регламентации использования ИИ для процессов разработки. Следить за этим очень интересно, но паниковать, как некоторые — незачем.
Пока этот текст готовился к публикации, произошел еще ряд примечательных событий, связанных с возможностями LLM от Anthropic, в том числе по поиску уязвимостей, и мы сочли возможным тоже об этом высказаться. Но даже такие новости смысла сказанного выше по большому счету не меняют.
