15 промтов, которые превращают ИИ в вашего DevSecOps-инженера: аудит, пентест и защита облака

15 промтов, которые превращают ИИ в вашего DevSecOps-инженера: аудит, пентест и защита облака

За последние два года атаки на цепочки поставок ПО и облачные конфигурации стали нормой, а не исключением. По данным отчёта Microsoft Digital Defense Report, число атак с использованием украденных учётных данных растёт год от года, а Verizon DBIR стабильно фиксирует, что значительная доля утечек начинается именно с ошибок конфигурации и человеческого фактора. Специалисту по безопасности приходится одновременно разбирать логи SIEM, проверять IaC-манифесты, писать правила детекции и готовить отчёт для аудита. Вручную это не масштабируется.

Именно здесь LLM дают наибольший выигрыш: не как «замена пентестера», а как ускоритель рутины. Модель отлично справляется с рутинным разбором конфигов, черновиками правил Sigma/YARA и объяснением сложных CVE на понятном языке. Но есть важное правило: ИИ не должен быть единственным источником истины. Любой сгенерированный артефакт нужно валидировать инструментами (Semgrep, Trivy, Checkov, OPA) и здравым смыслом.

Ниже — 15 промтов, которые я использую в реальной работе. Каждый с примером, пояснением задачи и оговоркой о том, где ИИ может ошибиться. Промты написаны так, чтобы их можно было адаптировать под ваш стек: AWS/GCP, Kubernetes, SIEM на базе Elastic или Splunk.

1. Триаж уязвимостей из сканера с приоритизацией по эксплуатируемости

Сканер выдаёт сотни находок, и 80% из них — не критичны. Задача промта — отсеять шум, опираясь на реальные признаки эксплуатации (EPSS, наличие эксплойта, доступность из интернета).

Промт:

Ты — AppSec-инженер. Ниже JSON-выгрузка из Trivy/Grype.
Для каждой уязвимости определи:
1. Вектор атаки (Network/Adjacent/Local) по CVSS.
2. Есть ли публичный эксплойт (если не уверен — напиши "требует проверки").
3. Достижима ли уязвимая функция из внешнего контура.
4. Приоритет: P0 (эксплуатируется сейчас), P1 (высокий риск), P2 (плановое).
Верни таблицу: CVE

| пакет | версия | вектор | P-уровень | обоснование (1 строка).
Не выдумывай CVSS-оценки — бери только из входных данных.

Данные:
{scan_json}

Зачем: ручной триаж 300 CVE занимает часы, а модель за минуту раскладывает их по полочкам. Обязательно сверяйте приоритет с внутренним контекстом — например, если сервис не выходит в интернет, P0 понижается до P2.

2. Разбор diff IaC-манифеста на предмет security-регрессий

Опаснее всего — не явные дыры, а незаметные изменения в Terraform, которые открывают порт или отключают шифрование.

Промт:

Ты — ревьюер Terraform. Ниже git diff.
Найди security-регрессии: открытые security group (0.0.0.0/0),
отключённое шифрование, публичные S3-бакеты, отсутствие логирования.
Для каждой находки укажи файл, строку, риск и исправленный HCL-фрагмент.
Формат: ### Находка N — [название], риск: high/medium/low.

Пример: в diff видно, что aws_s3_bucket_public_access_block удалён. Модель подсветит это и предложит вернуть блок с block_public_acls = true.

3. Генерация правил Sigma для SIEM

Sigma — открытый формат правил для SIEM (проект SigmaHQ). Писать их вручную утомительно, потому что нужно точно попасть в поля логов.

Промт:

Сгенерируй правило Sigma (формат SigmaHQ, актуальная спецификация)
для детекции подозрительного создания пользователя в Linux.
Условия: команда useradd с UID ниже 1000, либо добавление в группу sudo.
Укажи logsource: product linux, service auth.
Добавь falsepositives и level: high.
Не выдумывай поля — используй реальные из syslog/auditd.

Важно: после генерации обязательно прогоните правило через sigma-cli и конвертируйте в бэкенд вашего SIEM. Модель может ошибиться в названии поля — проверяйте маппинг.

4. Написание правил YARA для обнаружения малвари

YARA — стандарт де-факто для сигнатурного поиска (документация: yara.readthedocs.io).

Промт:

Напиши YARA-правило для обнаружения веб-шелла на PHP.
Признаки: вызовы eval/base64_decode/system, обращение к $_POST.
Используй condition с порогом строк (например, 3 из 5).
Проверь синтаксис: meta, strings, condition. Не добавляй несуществующие модификаторы.

Зачем: черновик правила за 30 секунд, дальше — тестирование на выборке файлов через yara -r rule.yar /path.

5. Аудит IAM-политик AWS на принцип наименьших привилегий

Самая частая проблема облака — Action: "*" в IAM-политике.

Промт:

Ты — cloud security architect. Проанализируй IAM-политику ниже.
Найди: wildcard-действия, wildcard-ресурсы, отсутствие условий (Conditions),
избыточные права. Для каждой проблемы предложи минимально необходимую политику.
Выведи в формате JSON-политики, валидном для AWS IAM.

Кейс: типичная политика для Lambda содержала s3:* на *. Модель сузила до s3:GetObject на конкретный ARN бакета — это и есть least privilege.

6. Проверка конфигурации Kubernetes на CIS Benchmark

Промт:

Проверь манифест Pod ниже на соответствие CIS Kubernetes Benchmark.
Обрати внимание: privileged, hostNetwork, hostPID, runAsRoot,
отсутствие readOnlyRootFilesystem, capabilities.
Выведи список нарушений с номером раздела CIS и исправленным YAML.

Дополнительно прогоняйте через kube-score и kubesec — они дают машинную валидацию.

7. Анализ логов SIEM и построение таймлайна инцидента

Промт:

Ты — SOC-аналитик. Ниже выгрузка событий (JSON: timestamp, user, src_ip, action).
Построй таймлайн атаки: начальный доступ, lateral movement, persistence, exfiltration.
Для каждого этапа укажи MITRE ATT&CK technique ID (реальные, из attack.mitre.org).
Отметь аномалии: смена геолокации, нетипичное время, всплеск неудачных логинов.

Оговорка: модель хорошо структурирует данные, но не заменяет корреляцию в SIEM. Используйте её для черновика отчёта, а не как источник детекции.

8. Генерация чек-листа реакции на инцидент

Промт:

Составь playbook реагирования на компрометацию API-ключа AWS.
Этапы: обнаружение, сдерживание, eradication, recovery, post-mortem.
Для каждого шага — конкретные CLI-команды (aws iam ...),
не выдумывай несуществующие подкоманды.
Добавь критерии эскалации и контакты ролей (без выдуманных имён).

9. Проверка Dockerfile и образа на уязвимости конфигурации

Промт:

Проанализируй Dockerfile. Найди: использование latest-тега,
запуск от root, секреты в ENV/ARG, лишние пакеты, отсутствие multi-stage.
Предложи исправленный Dockerfile с non-root user и distroless-базовым образом.

10. Маппинг находок на требования OWASP Top 10 и ASVS

Промт:

Ниже список уязвимостей из отчёта пентеста.
Сопоставь каждую с категорией OWASP Top 10 (2021) и пунктом ASVS 4.0.3.
Для несоответствий ASVS укажи уровень (L1/L2/L3) и рекомендацию по устранению.
Не выдумывай номера пунктов — если не уверен, помечай "требует проверки".

11. Генерация тест-кейсов для проверки авторизации (IDOR/BOLA)

BOLA (Broken Object Level Authorization) — топ-риск по OWASP API Security Top 10.

Промт:

Сгенерируй тест-кейсы для проверки BOLA в REST API.
Эндпоинты: GET /api/v1/users/{id}, PUT /api/v1/orders/{id}.
Для каждого: сценарий с чужого аккаунта, ожидаемый код 403/404,
шаги воспроизведения с curl. Только реальные HTTP-методы.

Пример curl:

curl -X GET https://api.example.com/api/v1/users/123 \
  -H "Authorization: Bearer $ATTACKER_TOKEN"

12. Проверка секретов и ключей в репозитории

Промт:

Проверь фрагмент кода/конфига на наличие секретов:
API-ключи, пароли, приватные ключи, токены.
Для каждой находки укажи тип, риск и способ ротации.
Напиши pre-commit hook на базе gitleaks для предотвращения утечек.

Инструмент: gitleaks — реальный open-source сканер, работает в CI/CD.

13. Аудит GCP: сравнение с лучшими практиками

Промт:

Проанализируй конфигурацию GCP-проекта (JSON-экспорт).
Найди: публичные бакеты, overly permissive IAM (roles/owner),
отсутствие VPC Service Controls, незашифрованные диски.
Сопоставь с CIS GCP Benchmark и предложи исправления через gcloud CLI.

14. Генерация отчёта о соответствии требованиям

Промт:

Составь раздел отчёта о соответствии ISO/IEC 27001:2022 по контролю A.8.8
(управление техническими уязвимостями).
Опиши: политику, процедуру сканирования, сроки устранения по критичности,
метрики. Формат: цель контроля, реализация, доказательства, ответственный.

15. Объяснение сложной CVE для нетехнических стейкхолдеров

Промт:

Объясни CVE-XXXX-YYYY для менеджера без технического бэкграунда.
Структура: что за компонент, как эксплуатируется, что грозит бизнесу,
что делаем сейчас, когда закроем. Без жаргона, 5-7 предложений.

Зачем: коммуникация — половина работы безопасника. Модель делает черновик за минуту, вы правите под контекст компании.

Таблица: какой промт под какую задачу

Чего не стоит ждать от ИИ в безопасности

Модель не выполняет сканирование, не имеет доступа к вашей инфраструктуре и не несёт ответственности. Она — генератор черновиков и структуратор. Ключевые ограничения:

• Галлюцинации в CVE и CWE. Модель может назвать несуществующий номер уязвимости. Всегда сверяйте с NVD и MITRE.
• Устаревшие данные. Обучение закончилось в прошлом — новые CVE и техники атак модель может не знать.
• Отсутствие контекста вашей сети. Модель не знает, что у вас за периметром, какие активы критичны и какие компенсирующие меры уже есть.

Правильный паттерн работы: ИИ генерирует → инструмент проверяет → человек принимает решение. Это не снижает требования к экспертизе, а смещает фокус с рутины на анализ.

Если вы только начинаете в DevSecOps — начните с промтов №1, №2 и №5. Они дают быстрый видимый эффект и не требуют сложной интеграции. Дальше добавляйте SIEM-правила и автоматизацию в CI/CD. Безопасность — это процесс, а не разовая проверка, и ИИ здесь просто ускоряет цикл обратной связи.