Промты для пентеста и защиты: 12 сценариев, которые превращают LLM в аудитора безопасности кода, инфраструктуры и облака
Пентест больше не начинается с nmap -sV. В 2026 году он начинается с правильно сформулированного промта. LLM не заменяет Burp Suite и не нажимает кнопки в Metasploit, но она отлично справляется с тем, на что у security-инженера вечно не хватает часов: чтением чужого кода, разбором конфигов и переводом CVE-описаний в конкретные действия. По данным GitHub Octoverse, доля AI-сгенерированного кода в репозиториях растёт, и вместе с ней растёт поверхность атаки — а значит, аудит безопасности кода становится рутиной, которую надо автоматизировать.
Проблема в том, что «проверь код на уязвимости» даёт мусорный ответ. Модели нужен контекст: язык, фреймворк, модель угроз, формат вывода. Ниже — 12 готовых промтов для DevSecOps-задач, от статического анализа до моделирования угроз. Копируйте, подставляйте свои данные, проверяйте результат руками. Ни один из этих промтов не заменяет ручную верификацию — LLM склонна к false positives и галлюцинациям, поэтому относитесь к её выводам как к тикету от младшего аналитика: полезно, но требует ревью.
Промты для аудита безопасности кода
1. Поиск SQLi, XSS и SSRF в конкретном файле
Задача: быстро просканировать контроллер или API-роут на классические инъекции.
Ты — senior AppSec-инженер. Проведи статический анализ фрагмента кода ниже на уязвимости из OWASP Top 10: SQL Injection, XSS, SSRF, небезопасную десериализацию.
Контекст: язык Python 3.12, фреймворк Flask, ORM — SQLAlchemy 2.0.
Для каждой находки верни таблицу: строка
| тип уязвимости | CWE-ID | почему это уязвимо | исправленный вариант кода.
Если уязвимостей нет — так и напиши. Не выдумывай проблемы.
КОД:
<вставьте код>
Пример: вставляете функцию, которая собирает query = f"SELECT * FROM users WHERE id = {request.args['id']}" — модель помечает это как CWE-89 (SQL Injection) и предлагает параметризованный запрос через text() и bind-параметры. CWE-ID берётся из официального каталога MITRE.
2. Промт для проверки авторизации (IDOR/BOLA)
Задача: найти broken object-level authorization — самую частую уязвимость в API.
Проанализируй эндпоинты ниже на предмет IDOR/BOLA (CWE-639).
Для каждого эндпоинта ответь: (1) проверяется ли, что объект принадлежит текущему пользователю, (2) где именно должна быть эта проверка, (3) покажи уязвимый и безопасный вариант.
Формат: JSON-массив с полями endpoint, vulnerable (bool), fix.
ЭНДПОИНТЫ:
<вставьте роуты или код>
Пример: эндпоинт GET /api/invoices/{id} без проверки invoice.owner_id == current_user.id — модель вернёт vulnerable: true и предложит добавить фильтр в запрос к БД.
3. Разбор IaC: Terraform на публичные S3 и открытые security groups
Задача: аудит конфигураций инфраструктуры как кода перед terraform apply.
Ты — cloud security-аудитор. Проверь Terraform-конфигурацию ниже на:
- публичный доступ к S3 (acl public-read, отсутствие block_public_acls);
- security groups с 0.0.0.0/0 на порты 22, 3389, 3306;
- незашифрованные EBS и RDS;
- IAM-политики с Action: "*" и Resource: "*".
Выведи таблицу: ресурс
| риск | severity (Critical/High/Medium) | ссылка на CIS Benchmark или документацию AWS.
КОД:
<вставьте .tf>
Пример: aws_security_group с cidr_blocks = ["0.0.0.0/0"] и from_port = 22 — модель помечает как Critical и ссылается на рекомендацию AWS по ограничению SSH.
4. Аудит Dockerfile и docker-compose
Задача: проверить контейнеры на запуск от root, секреты в слоях, устаревшие базовые образы.
Проверь Dockerfile и docker-compose.yml ниже по чек-листу:
1. USER root по умолчанию?
2. Секреты в ENV/ARG или в слоях образа?
3. Базовый образ без фиксированной версии (latest)?
4. Привилегированный режим, cap_add, монтирование docker.sock?
5. Отсутствие HEALTHCHECK?
Для каждого пункта: есть проблема / нет проблемы + строка + как исправить.
ФАЙЛЫ:
<вставьте Dockerfile и compose>
Пример: FROM node:latest + ENV DB_PASSWORD=secret — модель укажет на оба риска и предложит multi-stage build и Docker secrets.
5. Промт для Kubernetes-манифестов и RBAC
Задача: найти privilege escalation в кластере до деплоя.
Ты — Kubernetes security-инженер. Проанализируй манифесты на:
- privileged: true, hostNetwork, hostPID;
- ClusterRoleBinding с cluster-admin для ServiceAccount;
- отсутствие securityContext (runAsNonRoot, readOnlyRootFilesystem);
- secrets в plain text в ConfigMap.
Выведи: объект
| нарушение | рекомендация. Сверяйся с рекомендациями CIS Kubernetes Benchmark и документацией Pod Security Standards.
МАНИФЕСТЫ:
<вставьте YAML>
Пример: Deployment без securityContext.runAsNonRoot: true — модель отметит как нарушение уровня restricted в Pod Security Standards.
6. Разбор логов и подозрительной активности
Задача: превратить сырые логи в гипотезы об атаке.
Ты — SOC-аналитик. Вот фрагмент логов веб-сервера (nginx access.log).
Найди признаки: SQLi-пейлоадов, path traversal, сканирования (много 404 с разных путей), brute-force на /login.
Выведи: временное окно
| IP | тип атаки | evidence (строка лога) | рекомендация (fail2ban, WAF-правило).
ЛОГИ:
<вставьте 50–200 строк>
7. Перевод CVE в план действий
Задача: быстро понять, насколько критична уязвимость в вашем стеке.
Объясни CVE-2024-XXXX простым языком для DevOps-инженера.
Формат: (1) что уязвимо, (2) условия эксплуатации, (3) CVSS и вектор, (4) затронутые версии, (5) команды для проверки версии в системе, (6) план патча.
Если не уверен в деталях — скажи, что нужно проверить в NVD.
Пример: CVE в OpenSSH — модель выдаёт ssh -V для проверки версии и рекомендацию обновиться до патченного релиза, ссылаясь на NVD.
8. Моделирование угроз по STRIDE
Задача: составить threat model для нового сервиса до написания кода.
Проведи threat modeling по STRIDE для сервиса: <описание архитектуры>.
Для каждой категории (Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege) перечисли 2–3 угрозы, вероятность, влияние, контрмеры.
Выведи таблицу и топ-3 риска, которые надо закрыть первыми.
9. Чек-лист по OWASP Top 10 для ревью
Задача: подготовить ревью-гайд для команды.
Составь чек-лист код-ревью по OWASP Top 10 (2021) для стека <язык/фреймворк>.
Для каждой категории — 3–4 конкретных вопроса-проверки, на которые ревьюер отвечает «да/нет».
Формат: Markdown-чеклист с чекбоксами.
10. Генерация правил для Semgrep
Задача: автоматизировать найденную уязвимость в CI.
Напиши правило Semgrep (YAML), которое находит использование f-strings в SQL-запросах в Python.
Дай: правило, тестовый уязвимый пример, тестовый безопасный пример, команду запуска semgrep --config.
11. Подготовка к SOC 2: маппинг контролей
Задача: связать технические меры с требованиями аудита.
Составь маппинг между нашими мерами безопасности и Trust Services Criteria SOC 2 (CC6, CC7).
Меры: <список: логирование, MFA, change management, бэкапы>.
Выведи таблицу: критерий SOC 2
| наша мера | evidence (что покажем аудитору) | пробел.
12. Промт для разбора API на массовое присвоение (Mass Assignment)
Задача: найти поля, которые пользователь не должен менять.
Проверь модели и DTO ниже на Mass Assignment (CWE-915).
Найди поля вроде is_admin, role, balance, которые могут прийти из запроса и попасть в БД без фильтрации.
Выведи: модель
| опасное поле | как защититься (allowlist полей, отдельный DTO).
Как использовать это на практике
| Сценарий | Промт | Что проверять руками |
|---|---|---|
| Новый PR | №1, №2 | false positives, контекст бизнес-логики |
Перед terraform apply |
№3 | реальные IAM-политики |
| Деплой в K8s | №4, №5 | admission controllers |
| Инцидент | №6 | корреляция с SIEM |
| Патч-менеджмент | №7 | актуальность версии в NVD |
Главное правило DevSecOps с LLM: модель генерирует гипотезы, инженер подтверждает их инструментами. Промты №10 и №6 особенно хорошо ложатся в CI: первый превращает находку в автоматическое правило, второй экономит часы при разборе инцидента.
Начните с двух промтов — статического анализа кода и аудита IaC — и встройте их в ревью-процесс. Security-промты работают лучше всего, когда у вас есть чёткий формат вывода и вы не ленитесь сверять CWE-ID с MITRE и версии — с NVD. Безопасность не терпит галлюцинаций: доверяйте модели черновик, а финальное слово оставляйте за инструментами и человеком.
Комментарии