- Сообщения
- 7.800
- Реакции
- 10.685
Разговор о «кодере‑ИИ», который ускорит команду в разы, уже давно превратился в производственную практику: автодополнение, генерация тестов, шаблоны сервисов, миграции между фреймворками. Но чем шире становится применение, тем громче вопрос безопасности. Парадокс очевиден: модели уверенно производят рабочий, компилируемый, часто элегантный код, а совокупная уязвимость такого кода остаётся высокой. Летние отчёты и свежие академические работы 2024–2025 годов сходятся в диапазоне «около сорока–пятидесяти процентов» небезопасных решений в реальных задачах. Это не апокалипсис и не повод отменять инструменты, но сильный аргумент за пересборку пайплайна разработки: от постановки задачи и промптинга до ревью, тестов и поставки.
В августе 2025 года на широкую аудиторию вышла сводка Help Net Security по свежему отчёту Veracode: исследователи прогнали более ста языковых моделей по восьмидесяти практическим заданиям и получили 45 процентов решений с уязвимостями. Детализация неприятна, но полезна: Java оказалась самой рискованной, с отказоустойчивостью ниже семидесяти процентов, Python, C# и JavaScript колебались в районе сорока процентов провалов. Наизнанку вывернулись «банальные» классы слабостей: XSS и log‑injection модели «проваливали» в подавляющем большинстве кейсов, а между «функционирует» и «безопасно» зияла привычная пропасть производственника. В параллельных публикациях отраслевой прессы те же числа интерпретировались как системная особенность текущего поколения моделей: они стремятся оптимизировать правдоподобие решения и время до ответа, а не безопасность, и потому в двусмысленных контекстах выбирают небезопасные тропинки.
Ещё в 2021–2022 годах команда Пирса в работе «Asleep at the Keyboard?» системно прогоняла GitHub Copilot через задачи по CWE Top‑25 и получила около сорока процентов уязвимого кода. Позднее другие группы показывали, что использование ассистентов без дисциплины контекстов и подсказок приводит к росту доли небезопасных решений по сравнению с ручным кодом. В 2024 году появились систематические обзоры по теме: они фиксируют двойственность эффекта. Те же модели, которые легко пропускают XSS или неправильное экранирование логов, в других задачах способны находить и править уязвимости быстрее junior‑разработчиков. В 2025‑м выходит волна эмпирики про «итеративное ухудшение»: если бесконечно «улучшать» сгенерированный код без внешней проверки, часть моделей постепенно уводит решение в более хрупкие варианты, что важно для команд, выращивающих фичи через многократные запросы к ИИ.
Что стоит за этими цифрами технически.
Модели обучены на смеси открытого кода, документации и текстов, где безопасность — лишь один из многих признаков «правильности». Структура обучения не выделяет по умолчанию «безопасность» как приоритет: она оценивает правдоподобие следующего токена. Отсюда узнаваемые симптомы. Во‑первых, модели уверенно воспроизводят паттерны, которые в истории интернета встречались чаще, чем правильные практики: сырой HTML с инъекциями, логирование пользовательского ввода без нормализации, небезопасные шифровальные примитивы. Во‑вторых, в длинных промптах модели концентрируются на бизнес‑логике и пропускают «скобки безопасности»: проверку границ, валидацию схем, фронтиры авторизации. В‑третьих, при итеративных правках без внешнего оракула возникает эффект дрейфа: одно исправление ломает другую защиту, и система «съедает» её в поиске короткого пути к компилируемому результату.
Риск не одинаков для всех языков и задач.
Версия 2025 года от Veracode отмечает особенно частые провалы в Java, где строгая типизация не спасает от ошибок безопасности на уровне фреймворков и конфигураций: небезопасные шаблоны сериализации, устаревшие «советы» по криптографии, дефолтные разрешения. В JavaScript и Python основная боль — инъекции и работа с внешними данными. C# зачастую страдает на уровне логирования, параметризации запросов и доступа к секретам в конфигурации. Но ключ не в языках, а в «костях» задач: всё, что связано с пользовательским вводом, шаблонами, логированием, сетевыми вызовами и доступом к файловой системе, требует повышенного недоверия к ответам модели.
В сентябре 2025 года в медиа разошлась работа CrowdStrike о том, что одна из китайских моделей даёт заметно более плохие результаты по «чувствительным» темам и запросам. Речь не о спецназадуманных бэкдорах, а о статистике ошибок, отказов в ответе и «небрежных» паттернах, когда промпт касается тем, нелюбимых цензурой. Для практиков это сигнал простой: оценка доверия к ИИ должна включать не только точность и скорость, но и предсказуемость поведения по тематикам, важным для вашей предметной области. Если модель «переключает режим» или заметно меняет уровень качества в зависимости от контента, это может стать источником скрытых уязвимостей.
Что со спасительными «подсказками».
Индустрия активно экспериментирует с настроенными промптами: просить «думать как AppSec‑инженер», ссылаться на OWASP, требовать тесты, делать чек‑лист в конце ответа. Это помогает, но не отменяет проблему. Исследования 2024–2025 годов показывают, что хороший системный промпт и «security‑style» подсказки сокращают долю уязвимостей, но эффект нестабилен между задачами и моделями. Иногда изменение формулировки возвращает всё к исходным 40–45 процентам. Сильнее всего работает связка: ограничение модели строго заданным каркасом и автопроверка результата. Когда ИИ генерирует код внутри шаблона, где функции безопасности уже встроены, а затем код проходит автоматическое статическое и динамическое тестирование с «красными командами» из фреймворков SAST/DAST/IAST, итог заметно лучше, чем при «свободном плавании».
Простой «копипаст» из чата в репозиторий - худшая практика. Безопасный контур для ИИ‑кода выглядит иначе. Сначала формализуем задание и явно указываем требования безопасности: политика логирования, запрет на использование устаревших криптоалгоритмов, необходимость параметризации запросов, правила хранения секретов. Затем удерживаем модель в границах: предоставляем библиотеку внутренних шаблонов, слои абстракции для безопасного ввода‑вывода, заготовки модульных тестов. После генерации включаем автоматические проверки: SCA на зависимости, SAST на паттерны CWE, юнит‑ и property‑based‑тесты на инварианты, fuzzing для граничных случаев. Наконец, проводим ревью с фокусом на угрозы и запускаем среду в песочнице с телеметрией. Это звучит длинно, но большая часть шагов автоматизируется и включается в CI.
Сегодня есть и позитивная линия исследований: как заставить те же модели не только не ломать защиту, но и чинить её. В 2025‑м публикуются работы про «patch‑модели», которые обучают на диффах коммитов и учат фокусироваться на исправлениях. Параллельно академические группы и корпорации пробуют «двойное» использование ИИ: одна модель пишет код, другая атакует его, третья предлагает патч, а затем всё это проходит через правила линтинга и гейтов в репозитории. На практике такие «оркестровки» пока дороги и нестабильны, но в них видна траектория: безопасность станет не внешним ревью после факта, а частью самих инструментов генерации и доставки. Есть важный организационный вывод. Команда, которая «подключила ИИ», но не изменила процесс, почти гарантированно увеличит поверхность уязвимостей. Команда, которая перестроила процесс, обычно выигрывает в производительности без резкого роста риска. Вторая команда по‑новому распределяет роли: промпт‑инженер формализует требования и превращает нефункциональные ограничения в часть задач, разработчики «заворачивают» модель в безопасные каркасы, AppSec автоматизирует проверки и вводит «контракты безопасности», а релиз‑менеджер добавляет гейты, которые не пропускают сборку без прохождения тестов угроз. Так «интегратор ИИ» превращается в инженерную компетенцию, а не в магию автодополнения.
И последнее - про культуру.
Иллюзия компетентности здесь особенно сильна: модель уверенно пишет ответ и излагает его тоном авторитета. Люди склонны верить уверенным системам и копируют код без должного скепсиса. Защититься от этого можно не только линтерами. Помогает практика «обратного ревью»: автор промпта обязан написать короткую записку угроз (какие входы, какие инъекции, какие секреты), а ревьюер - проверить именно соответствие этой записке. Полезны внутренние каталоги безопасных рецептов на типовые задачи, подключение внутренней документации и SDL‑гайдов прямо в контекст модели, чтобы она «видела» ваш стандарт, а не только общеисторические паттерны из интернета. Важна и политика источников: если вы используете внешнюю модель, убедитесь, что вам понятны её ограничения, политика фильтрации контента и предсказуемость поведения в чувствительных темах.
Тезис в одну строку звучит так: ИИ умеет писать код, но безопасность - это не побочный эффект интеллекта, а отдельная инженерная цель. Пока исследовательская кривая не выровняла разрыв «функционально правильно = безопасно», ответственность за этот мост лежит на процессе разработки. И это, на самом деле, хорошая новость: у нас в руках есть инструменты, чтобы сделать ИИ полезным без лишней наивности.
Ссылки открываются на момент публикации. Там, где возможны региональные ограничения доступа, указан альтернативный источник/зеркало. Материал носит исследовательский характер и не заменяет внутренние стандарты SDL и политики безопасности вашей организации. Эта статья была создана с использованием нескольких редакционных инструментов, включая искусственный интеллект, как часть процесса. Редакторы-люди проверяли этот контент перед публикацией. Нажимай на изображение, там ты найдешь все информационные ресурсы A&N
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
В августе 2025 года на широкую аудиторию вышла сводка Help Net Security по свежему отчёту Veracode: исследователи прогнали более ста языковых моделей по восьмидесяти практическим заданиям и получили 45 процентов решений с уязвимостями. Детализация неприятна, но полезна: Java оказалась самой рискованной, с отказоустойчивостью ниже семидесяти процентов, Python, C# и JavaScript колебались в районе сорока процентов провалов. Наизнанку вывернулись «банальные» классы слабостей: XSS и log‑injection модели «проваливали» в подавляющем большинстве кейсов, а между «функционирует» и «безопасно» зияла привычная пропасть производственника. В параллельных публикациях отраслевой прессы те же числа интерпретировались как системная особенность текущего поколения моделей: они стремятся оптимизировать правдоподобие решения и время до ответа, а не безопасность, и потому в двусмысленных контекстах выбирают небезопасные тропинки.
Ещё в 2021–2022 годах команда Пирса в работе «Asleep at the Keyboard?» системно прогоняла GitHub Copilot через задачи по CWE Top‑25 и получила около сорока процентов уязвимого кода. Позднее другие группы показывали, что использование ассистентов без дисциплины контекстов и подсказок приводит к росту доли небезопасных решений по сравнению с ручным кодом. В 2024 году появились систематические обзоры по теме: они фиксируют двойственность эффекта. Те же модели, которые легко пропускают XSS или неправильное экранирование логов, в других задачах способны находить и править уязвимости быстрее junior‑разработчиков. В 2025‑м выходит волна эмпирики про «итеративное ухудшение»: если бесконечно «улучшать» сгенерированный код без внешней проверки, часть моделей постепенно уводит решение в более хрупкие варианты, что важно для команд, выращивающих фичи через многократные запросы к ИИ.
Что стоит за этими цифрами технически.
Модели обучены на смеси открытого кода, документации и текстов, где безопасность — лишь один из многих признаков «правильности». Структура обучения не выделяет по умолчанию «безопасность» как приоритет: она оценивает правдоподобие следующего токена. Отсюда узнаваемые симптомы. Во‑первых, модели уверенно воспроизводят паттерны, которые в истории интернета встречались чаще, чем правильные практики: сырой HTML с инъекциями, логирование пользовательского ввода без нормализации, небезопасные шифровальные примитивы. Во‑вторых, в длинных промптах модели концентрируются на бизнес‑логике и пропускают «скобки безопасности»: проверку границ, валидацию схем, фронтиры авторизации. В‑третьих, при итеративных правках без внешнего оракула возникает эффект дрейфа: одно исправление ломает другую защиту, и система «съедает» её в поиске короткого пути к компилируемому результату.
Риск не одинаков для всех языков и задач.
Версия 2025 года от Veracode отмечает особенно частые провалы в Java, где строгая типизация не спасает от ошибок безопасности на уровне фреймворков и конфигураций: небезопасные шаблоны сериализации, устаревшие «советы» по криптографии, дефолтные разрешения. В JavaScript и Python основная боль — инъекции и работа с внешними данными. C# зачастую страдает на уровне логирования, параметризации запросов и доступа к секретам в конфигурации. Но ключ не в языках, а в «костях» задач: всё, что связано с пользовательским вводом, шаблонами, логированием, сетевыми вызовами и доступом к файловой системе, требует повышенного недоверия к ответам модели.
В сентябре 2025 года в медиа разошлась работа CrowdStrike о том, что одна из китайских моделей даёт заметно более плохие результаты по «чувствительным» темам и запросам. Речь не о спецназадуманных бэкдорах, а о статистике ошибок, отказов в ответе и «небрежных» паттернах, когда промпт касается тем, нелюбимых цензурой. Для практиков это сигнал простой: оценка доверия к ИИ должна включать не только точность и скорость, но и предсказуемость поведения по тематикам, важным для вашей предметной области. Если модель «переключает режим» или заметно меняет уровень качества в зависимости от контента, это может стать источником скрытых уязвимостей.
Что со спасительными «подсказками».
Индустрия активно экспериментирует с настроенными промптами: просить «думать как AppSec‑инженер», ссылаться на OWASP, требовать тесты, делать чек‑лист в конце ответа. Это помогает, но не отменяет проблему. Исследования 2024–2025 годов показывают, что хороший системный промпт и «security‑style» подсказки сокращают долю уязвимостей, но эффект нестабилен между задачами и моделями. Иногда изменение формулировки возвращает всё к исходным 40–45 процентам. Сильнее всего работает связка: ограничение модели строго заданным каркасом и автопроверка результата. Когда ИИ генерирует код внутри шаблона, где функции безопасности уже встроены, а затем код проходит автоматическое статическое и динамическое тестирование с «красными командами» из фреймворков SAST/DAST/IAST, итог заметно лучше, чем при «свободном плавании».
Простой «копипаст» из чата в репозиторий - худшая практика. Безопасный контур для ИИ‑кода выглядит иначе. Сначала формализуем задание и явно указываем требования безопасности: политика логирования, запрет на использование устаревших криптоалгоритмов, необходимость параметризации запросов, правила хранения секретов. Затем удерживаем модель в границах: предоставляем библиотеку внутренних шаблонов, слои абстракции для безопасного ввода‑вывода, заготовки модульных тестов. После генерации включаем автоматические проверки: SCA на зависимости, SAST на паттерны CWE, юнит‑ и property‑based‑тесты на инварианты, fuzzing для граничных случаев. Наконец, проводим ревью с фокусом на угрозы и запускаем среду в песочнице с телеметрией. Это звучит длинно, но большая часть шагов автоматизируется и включается в CI.
Сегодня есть и позитивная линия исследований: как заставить те же модели не только не ломать защиту, но и чинить её. В 2025‑м публикуются работы про «patch‑модели», которые обучают на диффах коммитов и учат фокусироваться на исправлениях. Параллельно академические группы и корпорации пробуют «двойное» использование ИИ: одна модель пишет код, другая атакует его, третья предлагает патч, а затем всё это проходит через правила линтинга и гейтов в репозитории. На практике такие «оркестровки» пока дороги и нестабильны, но в них видна траектория: безопасность станет не внешним ревью после факта, а частью самих инструментов генерации и доставки. Есть важный организационный вывод. Команда, которая «подключила ИИ», но не изменила процесс, почти гарантированно увеличит поверхность уязвимостей. Команда, которая перестроила процесс, обычно выигрывает в производительности без резкого роста риска. Вторая команда по‑новому распределяет роли: промпт‑инженер формализует требования и превращает нефункциональные ограничения в часть задач, разработчики «заворачивают» модель в безопасные каркасы, AppSec автоматизирует проверки и вводит «контракты безопасности», а релиз‑менеджер добавляет гейты, которые не пропускают сборку без прохождения тестов угроз. Так «интегратор ИИ» превращается в инженерную компетенцию, а не в магию автодополнения.
И последнее - про культуру.
Иллюзия компетентности здесь особенно сильна: модель уверенно пишет ответ и излагает его тоном авторитета. Люди склонны верить уверенным системам и копируют код без должного скепсиса. Защититься от этого можно не только линтерами. Помогает практика «обратного ревью»: автор промпта обязан написать короткую записку угроз (какие входы, какие инъекции, какие секреты), а ревьюер - проверить именно соответствие этой записке. Полезны внутренние каталоги безопасных рецептов на типовые задачи, подключение внутренней документации и SDL‑гайдов прямо в контекст модели, чтобы она «видела» ваш стандарт, а не только общеисторические паттерны из интернета. Важна и политика источников: если вы используете внешнюю модель, убедитесь, что вам понятны её ограничения, политика фильтрации контента и предсказуемость поведения в чувствительных темах.
Тезис в одну строку звучит так: ИИ умеет писать код, но безопасность - это не побочный эффект интеллекта, а отдельная инженерная цель. Пока исследовательская кривая не выровняла разрыв «функционально правильно = безопасно», ответственность за этот мост лежит на процессе разработки. И это, на самом деле, хорошая новость: у нас в руках есть инструменты, чтобы сделать ИИ полезным без лишней наивности.
Help Net Security по отчёту Veracode 2025: «AI can write your code, but nearly half of it may be insecure» —
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— SD Times о тех же результатах Veracode:
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— Security Today: сводка по языкам и классам CWE из отчёта —
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— Veracode, аналитика и рекомендации 2025:
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— Pearce H. et al., «Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions» (2021): arXiv —
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
(PDF-версии см. также:
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
)— Systematic Literature Review по безопасности кода из LLM (2024):
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— Empirical Study on LLM‑Driven Secure Code Generation (2025):
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— Security Degradation in Iterative AI Code Generation (2025):
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— CSET, Georgetown: «Cybersecurity Risks of AI‑Generated Code» (обзор рисков и системных эффектов):
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— Endor Labs: «The Most Common Security Vulnerabilities in AI‑Generated Code» (2025):
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— Политики проектов, ограничивающих ИИ‑код, как индикатор качества: пример Cloud Hypervisor и обсуждение в отраслевой прессе —
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
— Контекст «геополитической предвзятости» и качества кода: обзор CrowdStrike и медиапокрытие — Washington Post:
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
; Tom’s Hardware:
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
Ссылки открываются на момент публикации. Там, где возможны региональные ограничения доступа, указан альтернативный источник/зеркало. Материал носит исследовательский характер и не заменяет внутренние стандарты SDL и политики безопасности вашей организации. Эта статья была создана с использованием нескольких редакционных инструментов, включая искусственный интеллект, как часть процесса. Редакторы-люди проверяли этот контент перед публикацией. Нажимай на изображение, там ты найдешь все информационные ресурсы A&N
Пожалуйста Войдите или Зарегистрируйтесь чтобы видеть скрытые ссылки.
