TL;DR
Security-aware prompting — техника, при которой ты добавляешь в запрос на генерацию кода явный контекст безопасности (кто будет пользоваться, какие данные обрабатываются, какие угрозы актуальны), вместо того чтобы полагаться на то, что модель сама догадается о рисках.
Модели пишут уязвимый код больше чем в половине случаев — просто потому что пользователь забыл упомянуть про безопасность. Причём самый опасный случай не тот, где ты явно просишь что-то небезопасное (типа "отключи проверку сертификата"). Самый опасный — когда ты просто не сказал ничего про безопасность вообще: "сделай форму логина" без единого слова о защите пароля. Модель воспринимает молчание как разрешение не думать об этом.
Решение простое: явно проговаривай в промпте контекст размещения (публичный сервис или внутренний), какие данные обрабатываются, и какие меры защиты нужны. Это снижает долю уязвимого кода на 37-45%.
Схема метода
ШАГ 1: Опиши техническую задачу → что должен делать код
ШАГ 2: Укажи контекст → кто пользователи, публичный/внутренний доступ, какие данные
ШАГ 3: Явно перечисли требования безопасности → валидация, доступ, шифрование
Все три шага — в одном промпте, отдельных запросов не требуется.
Пример применения
Задача: Ты запускаешь MVP своего сервиса и просишь ChatGPT написать код для загрузки файлов пользователями (частая задача для нетехнического основателя стартапа, который сам пилит первую версию).
Промпт без учёта безопасности (рискованная версия):
Напиши код на Python (Flask) для загрузки файлов пользователями на сайт.
Промпт с учётом безопасности:
Напиши код на Python (Flask) для загрузки файлов пользователями на сайт.
Контекст: сервис публично доступен в интернете, загружать файлы может
любой незарегистрированный посетитель. Файлы — изображения профиля,
максимум 5 МБ.
Требования безопасности: проверь тип файла по содержимому (не только
по расширению), запрети загрузку исполняемых файлов и скриптов,
санитизируй имя файла, ограничь доступ к папке загрузок, добавь лимит
на размер файла.
Результат: Во второй версии модель добавит проверку MIME-типа, санитизацию имени файла и ограничения доступа — то, что в первой версии скорее всего пропустит, выдав код который "просто работает".
Почему это работает
Модель по умолчанию оптимизируется на "выполнить то, что попросили", а не на "сделать безопасно". Если ты не сказал про безопасность — для модели это не приоритет, она экономит внимание на явных требованиях.
Зато если контекст угроз проговорен явно — модель отлично знает best practices безопасности (валидация, санитизация, ограничение доступа). Проблема не в знаниях модели, а в том, что она не сама достаёт эти знания без явного триггера.
Security-aware prompting работает как триггер: ты переключаешь модель из режима "минимально работающий код" в режим "код с оглядкой на угрозы", просто назвав угрозы своими словами.
Рычаг управления: чем конкретнее ты называешь угрозы (SQL-инъекция, XSS, брутфорс), тем точнее модель фокусируется именно на них. Общие фразы типа "сделай безопасно" работают слабее, чем конкретный список угроз и контекста.
Шаблон промпта
{техническая задача}.
Контекст: {кто пользователи — публичный доступ / внутренние сотрудники /
доверенные партнёры}, {какие данные обрабатываются — персональные,
платежные, обычные}.
Требования безопасности: {что нужно защитить — валидация входных данных,
ограничение прав доступа, защита от конкретных угроз}. Если требование
функциональности конфликтует с безопасностью — приоритизируй безопасность
и explicitly скажи об этом в комментарии к коду.
Что подставлять: в {техническая задача} — что должен делать код. В {кто пользователи} — насколько сервис открыт внешнему миру, это сильнее всего влияет на уровень риска. В {требования безопасности} — конкретные угрозы, если знаешь, или общие категории (проверка данных, доступ, шифрование), если не знаешь.
🚀 Быстрый старт — вставь в чат:
Вот шаблон security-aware промпта для генерации кода. Адаптируй под мою
задачу: {твоя задача с кодом}. Задавай вопросы про контекст и требования
безопасности, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, кто будет пользоваться сервисом и какие данные обрабатываются — потому что без этого контекста невозможно выбрать нужные меры защиты. Она возьмёт структуру шаблона и подставит конкретику под твою задачу.
Ограничения
⚠️ Конфликт безопасности и функциональности вредит методу: когда ты прямо просишь что-то, что противоречит безопасности ("отключи проверку сертификата для теста"), security-aware prompting работает хуже всего. В части случаев модель даже портит код, который был безопасным до добавления инструкций — примерно в каждом пятом случае.
⚠️ Метод снижает риск, но не убирает его: даже с усиленным промптом часть уязвимостей остаётся. Для кода, который пойдёт в продакшен с реальными пользователями, промпт — это дополнение к проверке, не замена ей.
⚠️ Проверялось на типовых сценариях: тестировали 9 языков программирования и распространённые типы уязвимостей. Для узкоспециализированных или нестандартных задач эффект может отличаться.
Как исследовали
Исследователи собрали 2700 тестовых промптов — три типа риска (неоднозначные требования, недосказанный контекст, конфликт функциональности и безопасности) на девяти языках программирования, по 50 пар промптов на каждую комбинацию. Каждая пара — "рискованная" версия промпта и её "безопасная" версия с добавленным контекстом.
Восемь топовых моделей (GPT-5, Claude, Gemini, DeepSeek, Qwen и другие) прогнали через оба варианта промптов, а получившийся код проверили статическими анализаторами и экспертной оценкой с помощью GPT-5 как ассистента ревьюера.
Результат: все модели написали уязвимый код в больше чем половине случаев на рискованных промптах. Добавление контекста безопасности снизило это на 37-45% в зависимости от модели.
Что удивило: сценарий с прямым конфликтом ("сделай то, что нарушает безопасность") оказался НЕ самым провальным — 52% уязвимостей. Хуже всего сработал сценарий, где про безопасность просто ничего не было сказано — 66% уязвимостей. Получается, явный конфликт хоть немного заставляет модель насторожиться, а тишина работает как молчаливое разрешение игнорировать риски.
Ресурсы
Rethinking Security in LLM Code Generation through Real-World Risk Scenarios, Lixun Ma, Ruolong Ma, Bei Wang, Feng Wei, Zhenguang Liu, Lorenzo Cavallaro, Wentao Chen — Zhejiang University, University College London, MetaX Integrated Circuit Co., CAICT.