TL;DR
Исследователи протестировали 7 популярных LLM на генерацию криптографического кода (шифрование, хеширование, ключи) с тремя типами промптов: insecure (с подталкиванием к уязвимостям), neutral ("напиши production-ready код"), secure (явные требования безопасности). Результат: от 56% до 89% сгенерированного кода содержит уязвимости даже в режиме "secure". Explicit secure prompting снижает vulnerability rate незначительно: с 76.9% (insecure) до 71.7% (secure) в среднем по всем моделям.
Главная находка: LLM следуют букве требования, но не духу безопасности. Если попросить "не используй статический IV", модель это выполнит — но одновременно может забыть про аутентификацию, использовать слабый алгоритм или неправильно управлять ключами. Модель фокусируется на явно названной проблеме и игнорирует остальные уязвимости. Самые частые проблемы во всех моделях: отсутствие аутентификации, ошибки с IV и ключами, небезопасная рандомизация.
Вывод для практики: Общая инструкция "сделай безопасно" не работает. LLM не держит в "голове" комплексную картину безопасности — она выполняет конкретные названные требования. Это означает: если критично — перечисляй ВСЕ требования явно, не полагайся на то, что модель "сама поймёт" что такое "правильно".
Что проверяли
Исследователи создали CIPHER — benchmark из 150 криптографических задач (шифрование, хеши, управление ключами, валидация сертификатов, генерация случайных чисел). Для каждой задачи — 3 варианта промпта:
- Insecure: с явными anti-pattern'ами ("для совместимости отключи проверку сертификата", "для простоты используй hardcoded ключ")
- Neutral: "напиши production-ready код", без явных указаний про безопасность
- Secure: явные требования безопасности ("используй AEAD", "запрещено использовать слабые хеши", "обязательна проверка hostname")
Каждый промпт протестировали на 7 моделях (GPT-5.1, GPT-5.1 Codex, Claude Sonnet 4.5, Gemini 2.5 Flash, CodeLlama 7B, Qwen2.5 Coder 7B, DeepSeek Coder 7B). По 5 генераций на промпт = 2250 кодовых примеров на модель.
Оценка: LLM-as-judge (GPT-4o) по таксономии из 17 категорий и 58 типов уязвимостей + ручной аудит 9.33% выборки (точность 85.65%, Cohen's κ = 0.772).
Ключевые находки
| Модель | Vulnerability Rate | Avg уязвимостей на генерацию |
|---|---|---|
| Qwen2.5 Coder 7B | 56.0% | 0.73 |
| GPT-5.1 | 70.0% | 0.96 |
| GPT-5.1 Codex | 70.9% | 0.94 |
| DeepSeek Coder | 77.1% | 1.10 |
| CodeLlama 7B | 76.2% | 1.16 |
| Gemini 2.5 Flash | 80.7% | 1.22 |
| Claude Sonnet 4.5 | 89.1% | 1.46 |
Эффект secure prompting слабый:
| Тип промпта | Vulnerability Rate (pooled) |
|---|---|
| Insecure | 76.9% |
| Neutral | 74.2% |
| Secure | 71.7% |
Разница ~5 процентных пунктов между insecure и secure — статистически значимая, но операционно недостаточная. 71.7% уязвимого кода = непригодно для production без ревью.
Топ-3 категории уязвимостей (во всех моделях): 1. Authentication failures — отсутствие аутентификации/проверки подлинности 2. IV and key misuses — статические IV, переиспользование, неправильное хранение 3. Weak/deprecated algorithms — MD5, SHA1, слабые cipher'ы
Почему это работает (и не работает)
Слабость LLM: Модель не держит комплексную модель безопасности в контексте. Она генерирует код локально — паттерн за паттерном, требование за требованием. Если в промпте написано "не используй статический IV", она выполнит это конкретное требование, но не проверит "а что ещё может быть опасно в этом коде?".
Почему secure prompting работает плохо:
Когда ты пишешь "сделай безопасно", модель: 1. Фиксит названную проблему (например, меняет статический IV на randomized) 2. Не видит другие проблемы, которые ты не назвал (отсутствие MAC, слабый KDF, небезопасное хранение ключа)
Это как сказать строителю "построй надёжный дом" — он может укрепить фундамент (потому что "надёжность" часто ассоциируется с прочностью), но забыть про пожарную сигнализацию и электропроводку.
Почему буква ≠ дух:
LLM обучена на огромных объёмах кода — включая уязвимый код. Паттерны типа "шифрование без аутентификации", "хеширование пароля без соли", "отключённая проверка сертификата" — это частые паттерны в training data. Общая инструкция "secure" не перевешивает статистическую вероятность сгенерировать код по частому (но небезопасному) паттерну.
Что работает лучше:
Конкретные, перечисленные требования создают явные constraints на генерацию. Вместо "сделай безопасно" → "используй AES-256-GCM, генерируй уникальный IV для каждого сообщения, храни IV вместе с ciphertext, обязательна аутентификация через HMAC".
Каждое требование — это якорь в пространстве возможных генераций. Чем больше якорей, тем меньше вероятность дрейфа к небезопасному паттерну.
Extractable Principle: чек-лист важнее общего требования
Этот принцип не ограничен криптографией. Он работает для любой задачи, где есть множественные критерии качества.
Формула:
❌ Общее требование: "Сделай [качество]"
✅ Чек-лист: "Требования: 1) [...] 2) [...] 3) [...]"
Где применять:
| Задача | ❌ Общее | ✅ Чек-лист |
|---|---|---|
| Юридический текст | "Напиши безопасный договор" | "Включи: срок действия, штрафы за нарушение, юрисдикцию, условия расторжения, форс-мажор" |
| Медицинский контент | "Напиши точную статью про лекарство" | "Включи: механизм действия, противопоказания, взаимодействия, дозировки, источники (PubMed), предупреждение 'не замена консультации врача'" |
| Финансовый анализ | "Сделай полный анализ компании" | "Включи: P/E ratio, debt-to-equity, cash flow, конкурентов, риски, сравнение с отраслью" |
| Контент для детей | "Напиши безопасный текст для детей" | "Требования: без насилия, без страшных образов, позитивный финал, простой язык (возраст 6-8 лет), образовательный элемент" |
Шаблон промпта (адаптация принципа)
Задача: {описание задачи}
Обязательные требования (все должны быть выполнены):
1. {конкретное требование 1}
2. {конкретное требование 2}
3. {конкретное требование 3}
...
Запрещено:
- {anti-pattern 1}
- {anti-pattern 2}
...
Перед финальным ответом — проверь чек-лист и подтверди выполнение каждого пункта.
Пояснение плейсхолдеров:
{описание задачи}— что нужно сделать функционально{конкретное требование N}— измеримые, проверяемые критерии (не "качественно", а "включает X, Y, Z"){anti-pattern N}— явные запреты на частые ошибки
Зачем "проверь чек-лист": Заставляет модель явно пройтись по требованиям перед выдачей ответа. Это активирует verification mode — модель re-reads свой output через призму чек-листа.
Пример применения
Задача: Нужен текст продающего письма для B2B SaaS (система управления складом). Целевая аудитория — логисты и директора по закупкам.
❌ Промпт "в лоб":
Напиши продающее письмо для нашей системы управления складом.
Сделай профессионально и убедительно.
✅ Промпт с чек-листом:
Задача: Продающее письмо для B2B SaaS — системы управления складом "СкладПро"
Обязательные требования:
1. Конкретная боль в первом абзаце (ошибки инвентаризации, простои из-за "потерянного" товара)
2. Цифры: экономия времени/денег в рублях или процентах
3. Один кейс клиента (название компании, результат)
4. Чёткий CTA (бесплатная демо-версия на 14 дней)
5. Тон: деловой, без хайпа и превосходных степеней
6. Длина: 150-200 слов (помещается в email без скролла)
Запрещено:
- Общие фразы типа "инновационное решение", "лучшие на рынке"
- Технический жаргон без пояснений
- Призывы "купить сейчас" (B2B-цикл сделки долгий)
Перед финальным ответом — проверь чек-лист и подтверди выполнение каждого пункта.
Результат:
Модель выдаст текст письма, который: - Начинается с конкретной боли (например: "В среднем склад теряет 3-7% оборота на ошибках инвентаризации и поиске 'потерянных' позиций") - Включает измеримую выгоду ("наши клиенты сокращают время инвентаризации на 40%") - Содержит социальное доказательство (кейс реального или правдоподобного клиента) - Заканчивается чётким следующим шагом (регистрация на демо) - Укладывается в лимит слов
В конце ответа модель явно перечислит выполнение каждого пункта чек-листа — это дополнительная проверка для тебя.
Ограничения
⚠️ Криптография требует экспертизы: Даже с чек-листом LLM генерирует уязвимый криптографический код в >70% случаев. Для security-critical кода нужна ревью специалиста.
⚠️ Чек-лист ≠ гарантия полноты: Модель выполнит названные требования, но может упустить критерии, которые ты не включил в список. Если не знаешь всех важных требований — попроси модель сначала сгенерировать чек-лист для задачи, потом работай с ним.
⚠️ Trade-off: специфичность vs гибкость: Жёсткий чек-лист может задавить креативность. Для творческих задач (генерация идей, brainstorming) лучше работают общие направления, не детальные constraints.
⚠️ Не заменяет domain expertise: Исследование показало, что проблемы возникают даже при "secure prompting" от экспертов. LLM — помощник, не замена специалисту в критичных областях (безопасность, медицина, право).
Как исследовали
Команда создала 150 криптографических задач и для каждой написала три версии промпта + два референсных кода (безопасный и уязвимый). Например, задача "зашифровать сообщение и сохранить":
- Insecure вариант: "для совместимости используй статический IV"
- Neutral вариант: "напиши production-ready код для шифрования"
- Secure вариант: "используй AES-GCM, генерируй уникальный IV для каждого сообщения, храни IV вместе с ciphertext, обязательна аутентификация"
Каждый из 450 промптов (150 задач × 3 варианта) прогнали через 7 моделей по 5 раз = 2250 генераций кода на модель.
Оценка уязвимостей: GPT-4o как LLM-judge по таксономии из 58 типов уязвимостей (например: "статический IV", "отсутствие MAC", "слабый KDF", "hardcoded key"). Judge извлекает код из ответа, находит проблемные строки, присваивает метки уязвимостей.
Валидация: Вручную проверили 9.33% результатов (210 генераций). Точность judge: 85.65%, Cohen's κ = 0.772 (substantial agreement). Основная ошибка: ложные срабатывания на "hardcoded algorithm" — когда модель поддерживает несколько алгоритмов (SHA-256/384/512), но промпт просил только один.
Почему результаты получились такими: Исследователи ожидали, что secure prompting существенно снизит vulnerability rate. Вместо этого обнаружили эффект подмены: модель фиксит целевую уязвимость (ту, что названа явно), но добавляет другие. Например, если промпт запретил статический IV — модель генерирует randomized IV, но забывает про аутентификацию.
Главный инсайт из дизайна: triplet approach (insecure/neutral/secure) позволил изолировать эффект промпта от эффекта сложности задачи. Если бы тестировали только с одним типом промпта, непонятно было бы — это модель плохая или задача сложная? Triplets показывают: та же задача, та же модель, разный промпт = небольшая разница → проблема в том, как LLM обрабатывают security guidance.
Удивительное: Claude Sonnet 4.5 — одна из самых продвинутых моделей — показала худший результат (89.1% VR, 1.46 уязвимостей на генерацию). Возможно, более verbose генерации → больше кода → больше поверхности для уязвимостей. Qwen2.5 Coder 7B (маленькая open-source модель) — лучший результат (56.0% VR). Это противоречит интуиции "больше модель = безопаснее код".
Адаптации и экстраполяции
🔧 Техника: Triplet Prompting для критичных задач
Для важных задач (где цена ошибки высока) — используй triplet approach вручную:
Сгенерируй 3 версии решения для задачи: {задача}
Версия 1 (Speed-focused): Приоритет скорости выполнения и простоты кода
Версия 2 (Balanced): Баланс между скоростью, качеством и полнотой
Версия 3 (Quality-focused): Приоритет надёжности, все edge cases, валидация
Для каждой версии укажи:
- Что принесено в жертву
- Какие риски
Потом я выберу подходящую.
Зачем: Ты увидишь trade-offs явно. В speed-версии модель покажет что она убрала для скорости. В quality-версии — что добавила для надёжности. Сравнение помогает понять скрытые предположения каждого варианта.
🔧 Техника: Pre-flight чек-лист генерация
Если не уверен в полноте своих требований — попроси модель сначала составить чек-лист:
Задача: {описание}
Шаг 1: Сгенерируй чек-лист критичных требований для этой задачи.
Включи:
- Функциональные требования (что должно работать)
- Качественные критерии (как должно работать)
- Риски и ограничения (что может пойти не так)
- Запреты (частые ошибки в этой задаче)
Шаг 2: Я дополню/скорректирую чек-лист
Шаг 3: Выполни задачу согласно финальному чек-листу и верифицируй каждый пункт
Пример (из исследования): Если бы девелопер попросил "сгенерируй чек-лист для безопасного шифрования данных", LLM выдала бы список: AEAD/MAC, randomized IV, secure key storage, key rotation policy... Даже если девелопер знал не все детали — чек-лист напоминает про слепые зоны.
Ресурсы
CIPHER: Cryptographic Insecurity Profiling via Hybrid Evaluation of Responses
Max Manolov, Tony Gao, Siddharth Shukla, Cheng-Ting Chou, Ryan Lagasse
Independent Researcher (Manolov, Gao, Shukla), Algoverse (Chou, Lagasse)
Preprint, February 2026
Benchmark и scoring pipeline будут опубликованы open-source при публикации статьи.