Claude и безопасность ИИ-кода в продакшене
Когда код пишется с помощью ИИ, скорость растёт, но вместе с ней растут и риски. Разбираем, где AI-ассистенты вроде Claude помогают, а где могут незаметно протащить уязвимости в продакшен.
Почему «код работает» — ещё не значит, что он безопасен
Статья разбирает не саму идею ИИ в разработке, а те места, где обычная спешка начинает вредить. Автор отдельно оговаривает границы: речь идёт о коде, который пишут с AI-ассистентами и потом выкатывают в прод, а также об агентах, которые работают рядом с разработчиком. Тема LLM-функций внутри продукта — например, чат-ботов и RAG по данным клиентов — здесь затронута лишь поверхностно.
Смысл простой: ИИ хорошо помогает получить рабочий черновик, но почти не думает о безопасности, если его об этом не попросили. Поэтому код выглядит аккуратно, тесты могут проходить, а опасные вещи вроде выполнения чужого кода, утечки данных или небезопасной обработки ввода остаются незамеченными.
Что показали исследования и отчёты по уязвимостям
Автор приводит исследование Стэнфорда «Do Users Write More Insecure Code with AI Assistants?». В нём 47 участников — от студентов до разработчиков из индустрии — решали задачи с ассистентом и без него. Итог оказался не очень приятным: с AI люди в среднем писали менее безопасный код, но при этом чаще были уверены, что всё в порядке.
Ещё один важный ориентир — отчёт Veracode GenAI Code Security Report за июль 2025 года. Там более 100 моделей решали 80 задач на Java, Python, C# и JavaScript. Уязвимости нашли в 45% случаев, а если у модели был выбор, она почти в половине ситуаций выбирала небезопасный вариант. Особенно плохо выглядел Java, а среди частых проблем оказались log injection и XSS.
Какие ошибки встречаются чаще всего и как их исправлять
Пример с log injection показывает, как опасно писать в логи пользовательский ввод без обработки: злоумышленник может подделать запись и запутать мониторинг. Исправление — экранировать переводы строк или перейти на структурированные JSON-логи, где каждое событие хранится отдельно. Это полезно для тех, кто отвечает за поддержку, расследование инцидентов и наблюдаемость системы.
Во втором примере речь о XSS: если вставить имя пользователя в HTML без экранирования, в браузере может выполниться чужой скрипт. На практике это лечится шаблонами с автоэкранированием или явным экранированием данных. Общий вывод автора такой: код от ИИ нужно считать черновиком, а в прод он должен попадать только после ревью.
Что это значит для команды и повседневной работы
Самая полезная мысль статьи — не расслабляться из-за того, что код кажется «умным» и быстро запускается. AI-ассистент похож на очень старательного стажёра, которому дали слишком много доступа: он быстро пишет, но без контроля может принести вместе с пользой и новые проблемы.
Для разработчиков это напоминание о базовых практиках: проверять чужие зависимости, смотреть на обработку ввода, не доверять логам и тестам вслепую, держать ревью обязательным шагом. Для тимлидов — повод добавить простые чек-листы и правила, чтобы команда не потеряла контроль, когда скорость разработки растёт.