Красная команда из одного человека: как я превратил LLM в пентестера, который ловит BOLA до продакшена

Красная команда из одного человека: как я превратил LLM в пентестера, который ловит BOLA до продакшена

Каждый раз, когда я вижу, как команда выкатывает фичу с новым эндпоинтом /api/v1/invoices/{id}, у меня в голове срабатывает сирена. BOLA (Broken Object Level Authorization) — это не экзотика из отчётов OWASP, это самая частая причина утечек в API, и она регулярно всплывает в бюллетенях безопасности. Проблема в том, что ручной аудит каждого PR не масштабируется: у безопасников очередь, у разработчиков дедлайн, а LLM тем временем пишет код быстрее, чем кто-либо успевает его читать.

Решение, к которому я пришёл после нескольких месяцев проб и ошибок, — не «AI-сканер» из маркетингового буклета, а набор промтов, встроенных в процесс. LLM не заменяет пентестера, но она отлично работает как напарник, который не устаёт задавать неудобные вопросы: «А что если пользователь подменит id в запросе?», «Почему этот секрет лежит в docker-compose.yml?», «Что вернёт эндпоинт, если передать отрицательный размер?».

Ниже — подборка из 10 промтов, которые я использую в реальной работе: от аудита кода на OWASP Top 10 до хардненинга Kubernetes и разбора свежих CVE. Все примеры — рабочие, все ссылки — на официальные источники.

Как использовать эту подборку

Промты разбиты на три уровня: базовые (для быстрого аудита кода и конфигов), продвинутые (для моделирования атак и анализа IaC) и экспертные (для хардненинга инфраструктуры и написания политик). Каждый промт — это шаблон: подставляйте свой код, конфиг или CVE-идентификатор. Важно одно правило: не отправляйте в публичные LLM реальный код с секретами и персональными данными. Используйте локальные модели, корпоративные инстансы с изоляцией или редактируйте код перед отправкой. Это не паранойя — это базовая гигиена, зафиксированная, например, в рекомендациях OWASP Top 10 for LLM Applications (LLM06: Sensitive Information Disclosure).

Базовый уровень: аудит кода и конфигов

Промт 1. Аудит на OWASP Top 10

Задача: быстро найти типовые уязвимости в функции или модуле до код-ревью.

Промт:

Ты — senior application security engineer. Проанализируй код ниже на соответствие OWASP Top 10 (2021). Для каждой найденной проблемы укажи: категорию OWASP, строку/фрагмент, вектор атаки, уровень критичности (CVSS-подобная оценка) и конкретное исправление с кодом. Если уязвимостей нет — так и скажи, не выдумывай.

Код:
<вставьте код>

Пример результата: на функции авторизации LLM возвращает: «A01: Broken Access Control — проверка user.role == 'admin' выполняется после выдачи данных; вектор: горизонтальное повышение привилегий; исправление: перенести проверку до запроса к БД». Это не замена SAST, но такой ответ ловит логические дыры, которые Semgrep пропускает.

Промт 2. Поиск секретов и небезопасных дефолтов

Задача: проверить конфиги и переменные окружения на утечки.

Промт:

Проверь фрагмент конфигурации на наличие секретов, дефолтных паролей, отключённых проверок TLS и небезопасных флагов. Составь таблицу: параметр

| риск | рекомендация. Не предлагай хранить секреты в коде — предложи конкретный механизм (Vault, AWS Secrets Manager, SOPS).

Конфиг:
<вставьте конфиг>

Пример результата: таблица, где POSTGRES_PASSWORD: postgres помечен как критичный риск с рекомендацией вынести в секрет-менеджер и включить ротацию.

Промт 3. Генерация payload'ов для легального тестирования

Задача: подготовить тест-кейсы для своего же приложения в staging.

Промт:

Я тестирую собственное приложение в изолированном staging-окружении. Сгенерируй 10 payload'ов для проверки на SQL-инъекции и XSS в параметрах query string. Для каждого payload'а объясни, что он проверяет, и какой безопасный ответ должен вернуть сервер. Не включай destructive-запросы (DROP, DELETE).

Пример результата: список вида ' OR '1'='1 (проверка конкатенации в SQL), <img src=x onerror=alert(1)> (проверка экранирования) с пояснением ожидаемого поведения: 400/403, отсутствие отражения ввода в HTML.

Продвинутый уровень: моделирование атак и IaC

Промт 4. Трассировка потока данных (taint analysis)

Задача: понять, доходит ли пользовательский ввод до опасного sink'а.

Промт:

Выполни статическую трассировку taint-потока в коде ниже. Источники (sources): HTTP-параметры, заголовки, тело запроса. Sink'и: SQL-запросы, exec/eval, файловые операции, HTTP-редиректы. Для каждого пути source → sink укажи, есть ли санитизация и какая. Формат ответа: цепочка вызовов, вердикт (safe/unsafe), рекомендация.

Пример результата: LLM строит цепочку req.query.q → buildQuery() → db.raw() и указывает, что параметризация отсутствует, а escape() вызывается только для одного из трёх параметров.

Промт 5. Разбор CVE

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

Промт:

Разбери CVE-<номер>. Используй только официальные источники: NVD (nvd.nist.gov), GitHub Security Advisories, бюллетени вендора. Дай: затронутые версии, вектор атаки (CVSS), условия эксплуатации, есть ли публичный PoC, патч или воркэраунд. Если данных недостаточно — прямо скажи, чего не хватает, и не домысливай.

Пример результата: структурированная сводка с ссылкой на advisory и явным указанием: «патч в версии X.Y.Z, для старых веток — воркэраунд через отключение функции F». Всегда проверяйте ответ по NVD — LLM может путать версии.

Промт 6. Аудит Terraform/CloudFormation

Задача: поймать небезопасные настройки IaC до применения.

Промт:

Проверь IaC-конфиг ниже на небезопасные настройки: публичные S3-бакеты, открытые security groups (0.0.0.0/0), отсутствие шифрования, избыточные IAM-права, отключённый логинг. Сверься с рекомендациями CIS Benchmark для соответствующего облака. Формат: ресурс

| проблема | CIS-контроль | исправление в виде diff.

Пример результата: «aws_security_group разрешает ingress 22/tcp с 0.0.0.0/0 — нарушение CIS AWS 5.2; заменить на CIDR офиса или SSM Session Manager».

Экспертный уровень: инфраструктура и политики

Промт 7. Хардненинг Docker-образа

Задача: уменьшить поверхность атаки контейнера.

Промт:

Проанализируй Dockerfile ниже и предложи хардненинг: non-root user, минимальный базовый образ (distroless/alpine), multi-stage build, отсутствие curl/wget в финальном слое, фиксация версий пакетов, HEALTHCHECK. Для каждого изменения покажи diff и объясни риск, который он закрывает (со ссылкой на CIS Docker Benchmark).

Пример результата: diff, добавляющий USER 10001:10001, --no-install-recommends и замену ubuntu:latest на gcr.io/distroless/static-debian12.

Промт 8. Проверка Kubernetes-манифестов

Задача: закрыть типовые мисконфиги в кластере.

Промт:

Проверь манифесты ниже на соответствие Pod Security Standards (restricted): runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, dropped capabilities, seccompProfile. Для каждого нарушения дай исправленный YAML и укажи, какой контроль PSS нарушен.

Пример результата: исправленный securityContext с capabilities.drop: [ALL] и seccompProfile.type: RuntimeDefault.

Промт 9. Генерация security-политики

Задача: превратить требования в проверяемый документ.

Промт:

Составь security-политику для команды из 10 разработчиков: управление секретами, ревью кода с security-чеклистом, реакция на инциденты, сроки патчинга по критичности. Опирайся на NIST SSDF (SP 800-218) и OWASP ASVS. Формат: раздел

| требование | как проверяем (автоматически/вручную).

Пример результата: таблица требований с проверками: «секреты не в git — проверка gitleaks в CI», «критичные CVE — патч за 7 дней — трекинг в issue-трекере».

Промт 10. Ревью API на BOLA

Задача: та самая проблема, с которой начинается статья.

Промт:

Проверь обработчики API ниже на Broken Object Level Authorization (OWASP API1:2023). Для каждого эндпоинта с идентификатором объекта ответь: проверяется ли, что объект принадлежит текущему пользователю, до его возврата или изменения? Есть ли IDOR через смену метода (GET→DELETE)? Предложи тест-кейс для staging и исправление.

Пример результата: «GET /invoices/{id} возвращает счёт по id без проверки owner_id — уязвимо; тест: два аккаунта, запрос чужого id, ожидание 404; исправление: WHERE id = ? AND owner_id = ?».

Что LLM не заменит

Промты — это ускоритель, а не замена процессу. LLM ошибается: путает версии в CVE, галлюцинирует «уязвимости» в безопасном коде и не видит бизнес-логику. Поэтому в моём пайплайне ответы модели всегда проходят через три фильтра: SAST/DAST (Semgrep, Trivy, ZAP), ручную валидацию находок и тесты в изолированном окружении. Официальные ориентиры — OWASP Top 10 (owasp.org/Top10), OWASP API Security Top 10 (owasp.org/API-Security), NIST SSDF (csrc.nist.gov) — остаются источником истины, а LLM лишь помогает быстрее до них добраться.

Начните с двух промтов: аудита на OWASP Top 10 и проверки на BOLA. Встройте их в ревью PR — и через пару недель заметите, что неудобные вопросы задаются до релиза, а не после инцидента. Красная команда из одного человека — это реально, если у вас есть напарник, который никогда не устаёт.