Промты, которые заменяют пентест-отдел: как LLM ищет уязвимости там, где SAST молчит

Промты, которые заменяют пентест-отдел: как LLM ищет уязвимости там, где SAST молчит

Классический SAST-сканер работает по сигнатурам и правилам: он найдёт eval() в Python, но не поймёт, что бизнес-логика в вашем API позволяет любому пользователю читать чужие инвойсы. Именно эта прослойка — «сканер чист, а уязвимость есть» — годами была зоной ответственности живого пентестера. В 2026 году LLM с правильно построенным промтом закрывает значительную часть этой работы: разбирает код в контексте, объясняет CVE на языке вашего стека и генерирует security-тесты.

Ниже — подборка готовых промтов, которые я использую в цикле DevSecOps: от аудита отдельного файла до встраивания проверок в CI/CD. Каждый промт — копипаст-готовый, с пояснением задачи и примером. Важно понимать ограничение: LLM не заменяет динамический анализ и не видит рантайм — он усиливает ревью и триаж, но не отменяет semgrep, trivy и zap.

1. Аудит файла на уязвимости с привязкой к CWE

Задача: быстрый ручной ревью подозрительного файла перед мержем. Промт заставляет модель не «лить воду», а выдавать находки с идентификатором CWE (Common Weakness Enumeration, каталог типов слабостей).

Ты — senior AppSec-инженер. Проанализируй код ниже на уязвимости.
Для каждой находки укажи: CWE-ID, строку, вектор атаки, серьёзность (CVSS-вектор), исправленный фрагмент.
Не выдумывай уязвимости: если код безопасен — так и скажи.
Стек: Python 3.12, Flask.

```python
@app.route("/download")
def download():
    name = request.args.get("file")
    return send_file(os.path.join("/data", name))

**Что получите:** находку CWE-22 (Path Traversal) с примером эксплуатации `?file=../../etc/passwd` и фиксом через `werkzeug.utils.secure_filename` + проверку `os.path.realpath`. Пример реальный: именно такой паттерн — частая причина утечек в файловых API.

## 2. Разбор CVE под ваш стек

**Задача:** в зависимостях всплыл CVE, и нужно за 5 минут понять, реально ли вы уязвимы. Промт заставляет модель отделить «теоретически затронут» от «эксплуатируемо у нас».

Разбери CVE-2021-44228 (Log4Shell) для нашего стека.
Формат ответа:
1. Суть уязвимости в 2 предложениях.
2. Какие версии затронуты (точные диапазоны).
3. Условия эксплуатации: что должно быть в приложении, чтобы атака сработала.
4. Как проверить наличие уязвимости в нашем коде (grep-паттерны, команды).
5. Временные меры и постоянный фикс.
Наш стек: Java 11, Spring Boot, log4j-core 2.14.1, входящие HTTP-запросы логируются.

**Важно:** всегда сверяйте ответ с официальным NVD (nvd.nist.gov) и advisory вендора — модель может путать диапазоны версий. Промт ускоряет триаж, но финальную проверку делайте по первоисточнику.

## 3. Генерация security-тестов (негативные кейсы)

**Задача:** обычные юнит-тесты проверяют happy path. Этот промт генерирует тесты на атаки.

Напиши pytest-тесты для эндпоинта ниже, покрывающие security-кейсы:
SQL-инъекция, XSS, IDOR (доступ к чужому объекту по id), обход авторизации, огромный payload (DoS).
Каждый тест — с комментарием, какую уязвимость он ловит. Используй pytest + Flask test_client.

@app.get("/api/invoice/<int:invoice_id>")
def get_invoice(invoice_id):
    return jsonify(Invoice.query.get(invoice_id).to_dict())

**Результат:** тест, который создаёт инвойс для user A, логинится как user B и ожидает 403, — ровно та проверка, которая ловит BOLA/IDOR (OWASP API Security Top 10, API1). Такие тесты стоит держать в CI как регрессию.

## 4. Threat-модель по STRIDE

**Задача:** перед запуском фичи нарисовать модель угроз. Промт превращает описание архитектуры в таблицу STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).

Построй threat-модель по STRIDE для системы ниже.
Формат: таблица

| Категория STRIDE | Угроза | Актив | Вероятность | Влияние | Мера защиты |.
После таблицы — топ-3 риска с обоснованием.

Система: REST API на FastAPI, PostgreSQL, JWT-авторизация, загрузка файлов в S3,
вебхуки от платёжного провайдера, админ-панель на отдельном поддомене.

Это отличный черновик для архитектурного ревью: таблицу правит человек, но 80% угроз модель поднимет сама — включая подмену вебхуков и отсутствие rate limiting.

## 5. Настройка SAST-правила под свой код

**Задача:** встроить кастомную проверку в `semgrep`, когда готового правила нет.

Напиши semgrep-правило (YAML) для языка Python, которое ловит вызовы subprocess
с shell=True и конкатенацией пользовательского ввода. Приведи пример кода, который
правило поймает, и который не поймает (false positive).

Модель выдаст правило с `pattern` и `pattern-not`, а также тест-кейсы — это ровно то, что нужно для `semgrep --test`. Официальная документация по синтаксису: semgrep.dev/docs.

## 6. DAST-чеклист для CI/CD

**Задача:** не забыть динамические проверки в пайплайне. Промт собирает чеклист под ваш стек.

Составь чеклист DAST-проверок для CI/CD-пайплайна веб-приложения (Node.js + React, деплой в Docker).
Для каждого пункта: инструмент (OWASP ZAP, Nuclei и т.п.), на каком этапе запускать,
какие проверки, как не блокировать сборку ложными срабатываниями.

В ответе будет, например, запуск ZAP baseline scan (`zap-baseline.py -t $URL`) на staging после деплоя и `nuclei -severity high,critical` по списку эндпоинтов — реальные команды, а не абстракции.

## 7. Триаж ложных срабатываний

**Задача:** сканер выдал 200 алертов, надо отделить шум.

Ниже — вывод Semgrep. Для каждой находки определи: true positive / false positive / needs review.
Обоснуй в одну строку. Если это false positive — объясни, почему сработало правило.

[вставьте JSON-вывод semgrep]

Экономит часы: модель быстро объясняет, что `sqlalchemy.text()` с параметрами — не инъекция, а вот конкатенация строк — да.

## 8. Ревью IaC и Dockerfile

**Задача:** контейнеры и Terraform — частая зона утечек.

Проверь Dockerfile на security-проблемы по CIS Docker Benchmark:
запуск от root, лишние пакеты, отсутствие USER, секреты в слоях, теги latest.
Дай исправленный Dockerfile с комментариями к каждой правке.

Модель укажет на `USER app`, `--no-install-recommends`, пиннинг версий по digest и `.dockerignore` — реальные меры, которые проверяет `trivy config` и `hadolint`.

## 9. Аудит секретов и утечек в репозитории

**Задача:** найти захардкоженные ключи до того, как их найдёт бот.

Просканируй фрагмент кода на признаки секретов (API-ключи, токены, пароли).
Для каждого: тип, риск, как ротировать, как вынести в переменные окружения.
Учти, что паттерны вроде "AKIA..." — это AWS Access Key ID.

[код]

Дополняйте это реальным сканером (`gitleaks detect --source .`) — LLM хорош в объяснении, но детектит хуже специализированного инструмента.

## 10. Промт для пентест-отчёта

**Задача:** превратить сырые находки в отчёт для менеджмента.

Составь пентест-отчёт из списка находок ниже.
Структура: Executive Summary (без технического жаргона), таблица находок
(серьёзность, CVSS, компонент), детали с PoC, рекомендации по приоритетам.
Аудитория: CTO и тимлиды.

[список находок]

Это закрывает разрыв между «технарь нашёл» и «бизнес понял риск» — типичная боль внутренних аудитов.

## 11. Проверка авторизации по матрице ролей

**Задача:** логические баги доступа, которые SAST не видит.

Дан код RBAC-мидлвари и список эндпоинтов. Составь матрицу «роль × эндпоинт»
и найди дыры: где роль получает доступ, которого не должна, где проверка отсутствует.
Выведи таблицу и список проблем с severity.

Именно так ловятся «забыли декоратор `@require_admin`» — класс ошибок, который сканеры пропускают.

## 12. Хардненинг по CIS Benchmark

**Задача:** быстрый чеклист для Linux-сервера.

Составь чеклист хардненинга Ubuntu 24.04 по CIS Benchmark Level 1:
SSH, файрвол, обновления, права на файлы, аудит. Для пункта — команда проверки и команда исправления.

Сверяйтесь с официальным документом CIS (cisecurity.org) — модель даёт черновик, но конкретные номера контролов проверяйте там.

## 13. Аудит зависимостей и SCA-политика

**Задача:** настроить политику для Software Composition Analysis.

Предложи политику SCA для проекта: какие уязвимости блокируют мерж (severity, наличие эксплойта в EPSS),
как обрабатывать транзитивные зависимости, SLA на исправление по severity.
Опиши, как это встроить в GitHub Actions с Dependabot и Trivy.

Опора на EPSS (Exploit Prediction Scoring System, FIRST.org) — практичный сигнал приоритизации: не все CVSS 9.8 эксплуатируются в реальности.

## 14. Разбор инцидента и IoC

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

По логам ниже построй гипотезы атаки (MITRE ATT&CK), выдели IoC,
предложи шаги сдерживания и форензики. Формат: таблица

| Тактика ATT&CK | Техника | Доказательство из логов |.

[логи]

Модель поможет сопоставить паттерны с тактиками (например, T1110 Brute Force) — но валидируйте по документации attack.mitre.org.

## 15. Security-ревью pull request

**Задача:** автоматизировать security-часть код-ревью.

Ты — ревьюер безопасности. Проверь diff ниже: новые внешние вызовы, обработка ввода,
криптография, логирование чувствительных данных. Дай комментарии в формате «строка — проблема — фикс».
Если всё чисто — напиши «LGTM» без воды.

[diff]
```

Хорошо работает как отдельный шаг в CI: LLM комментирует PR, человек принимает решение.

Как это встроить в рабочий процесс

Главное правило: LLM — усилитель ревью и триажа, а не замена динамического тестирования. Все находки с высоким severity подтверждайте вручную или сканером.

Попробуйте начать с двух промтов — аудита файла и разбора CVE: они дают быстрый эффект и не требуют настройки пайплайна. Дальше добавляйте security-тесты и semgrep-правила, пока проверки не станут частью CI. Безопасность без отдельного пентестера — это не магия, а дисциплина плюс правильные промты под рукой.