Промты для кибербезопасности: 12 сценариев от аудита кода до разбора инцидентов
Искусственный интеллект уже не просто помощник в написании кода — он становится полноценным участником Secure SDLC. По данным опроса GitLab 2024 года, 62% разработчиков используют AI-инструменты для генерации кода, но только 18% организаций применяют их для проверки безопасности. Это создаёт разрыв: код пишется быстрее, чем проверяется. В этой подборке — 12 практических промтов, которые помогут безопасникам, DevSecOps-инженерам и разработчикам автоматизировать аудит, анализ уязвимостей и реагирование на инциденты. Каждый промт сопровождается примером использования и реальным контекстом.
Базовые промты: автоматизация рутины
1. Быстрый аудит кода на типовые уязвимости
Задача: Проверить фрагмент кода на наличие распространённых уязвимостей (SQL-инъекции, XSS, небезопасная десериализация).
Промт:
Ты — опытный AppSec-инженер. Проанализируй следующий код на Python на предмет уязвимостей из OWASP Top 10 (2021). Для каждой найденной проблемы укажи: тип, строку, серьёзность (CVSS), рекомендацию по исправлению с примером кода.
Код:
```python
def get_user(username):
query = f"SELECT * FROM users WHERE name = '{username}'"
return db.execute(query)
*Пример результата:*
Уязвимость: SQL-инъекция (CWE-89)
Строка: 2
Серьёзность: 9.8 (Critical)
Рекомендация: Использовать параметризованные запросы:
def get_user(username):
query = "SELECT * FROM users WHERE name = %s"
return db.execute(query, (username,))
**2. Генерация чек-листа для code review**
*Задача:* Создать кастомизированный чек-лист безопасности для конкретного проекта.
*Промт:*
Составь чек-лист для code review микросервиса на Go, работающего с персональными данными. Учти требования GDPR, OWASP ASVS Level 2 и лучшие практики безопасной разработки. Разбей на категории: аутентификация, авторизация, работа с данными, логирование, обработка ошибок.
*Пример результата:*
- Аутентификация: Проверка JWT-токенов на подпись и срок действия.
- Авторизация: Проверка прав доступа на уровне каждого эндпоинта (RBAC).
- Работа с данными: Шифрование PII в покое и при передаче.
- Логирование: Отсутствие чувствительных данных в логах.
- Обработка ошибок: Не возвращать stack trace клиенту.
**3. Объяснение уязвимости для нетехнических стейкхолдеров**
*Задача:* Перевести описание CVE на бизнес-язык для отчёта руководству.
*Промт:*
Объясни уязвимость CVE-2024-3094 (XZ Utils backdoor) для менеджеров без технического бэкграунда. Опиши: что это, как может повлиять на бизнес, какие меры уже приняты, что делать дальше. Избегай жаргона, используй аналогии.
*Пример результата:*
CVE-2024-3094 — это как если бы в замок вашего офиса тайно встроили второй ключ. Злоумышленник мог бы войти в любую систему, использующую эту библиотеку, без пароля. Риск: утечка данных, простой. Меры: мы обновили библиотеку до безопасной версии, провели аудит. Дальше: усилить мониторинг аномалий.
### Продвинутые промты: автоматизация анализа
**4. Статический анализ с помощью LLM**
*Задача:* Найти сложные логические уязвимости, которые не видят SAST-инструменты.
*Промт:*
Проанализируй этот фрагмент кода на Java на предмет race condition и TOCTOU-уязвимостей. Обрати внимание на работу с файлами и многопоточность. Предложи исправление с использованием блокировок.
Код:
public void writeFile(String path, String data) {
if (!Files.exists(Paths.get(path))) {
Files.write(Paths.get(path), data.getBytes());
}
}
*Пример результата:*
Уязвимость: Race condition (CWE-362) между проверкой существования и записью. Два потока могут одновременно пройти проверку и перезаписать файл. Исправление: использовать Files.write с опциями CREATE_NEW или блокировку.
**5. Генерация эксплойта для проверки уязвимости**
*Задача:* Создать PoC для подтверждения возможности эксплуатации.
*Промт:*
Напиши Python-скрипт для эксплуатации SQL-инъекции в параметре 'id' эндпоинта /api/user. Используй библиотеку requests. Скрипт должен извлечь версию базы данных и имена таблиц. Только для легального пентеста.
*Пример результата:*
```python
import requests
url = "http://example.com/api/user?id=1' UNION SELECT version(), null-- "
response = requests.get(url)
print(response.text)
6. Анализ логов на признаки вторжения
Задача: Автоматически выявлять подозрительную активность в логах веб-сервера.
Промт:
Проанализируй следующий фрагмент access.log Nginx. Найди признаки атак: SQL-инъекции, XSS, path traversal, сканирование. Для каждого инцидента укажи IP, время, тип атаки, серьёзность.
Лог:
192.168.1.1 - - [10/Sep/2026:10:00:01 +0300] "GET /admin.php?id=1' OR '1'='1 HTTP/1.1" 200 1234
192.168.1.2 - - [10/Sep/2026:10:00:02 +0300] "GET /../../etc/passwd HTTP/1.1" 403 0
Пример результата:
IP 192.168.1.1 — SQL-инъекция (попытка обхода аутентификации), серьёзность: высокая.
IP 192.168.1.2 — Path Traversal (попытка чтения файла), серьёзность: средняя (заблокировано).
Экспертные промты: интеграция в DevSecOps
7. Автоматизация threat modeling
Задача: Провести STRIDE-анализ для новой фичи.
Промт:
Проведи threat modeling по методологии STRIDE для функции загрузки аватарок пользователей. Опиши возможные угрозы по каждой категории (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Предложи меры противодействия.
Пример результата:
Spoofing: Загрузка файла от имени другого пользователя — требуется проверка CSRF-токена.
Tampering: Подмена содержимого файла — проверка MIME-типа и сигнатур.
Information Disclosure: Утечка метаданных EXIF — удаление метаданных при загрузке.
8. Генерация security-тестов
Задача: Создать тесты для проверки безопасности API.
Промт:
Напиши pytest-тесты для проверки эндпоинта /api/login на устойчивость к брутфорсу, SQL-инъекциям и XSS. Используй библиотеку requests. Тесты должны проверять блокировку после 5 неудачных попыток.
Пример результата:
import requests
import pytest
def test_bruteforce():
for _ in range(5):
requests.post("http://example.com/api/login", data={"user":"admin","pass":"wrong"})
r = requests.post("http://example.com/api/login", data={"user":"admin","pass":"wrong"})
assert r.status_code == 429
9. Разбор инцидента: анализ фишингового письма
Задача: Быстро оценить подозрительное письмо.
Промт:
Проанализируй заголовки и тело фишингового письма. Определи: легитимность отправителя (SPF, DKIM, DMARC), подозрительные ссылки, вложения, социальную инженерию. Дай вердикт: фишинг или нет.
Заголовки:
Received: from unknown (HELO evil.com) (192.0.2.1)
From: "PayPal" security@paypal.com
Пример результата:
SPF: fail (IP 192.0.2.1 не авторизован для paypal.com).
DKIM: отсутствует.
Ссылка ведёт на http://paypal-secure.evil.com — фишинг.
Вердикт: фишинговое письмо, рекомендуется блокировка и уведомление пользователей.
10. Автоматизация ответа на инцидент
Задача: Сгенерировать скрипт для изоляции скомпрометированного хоста.
Промт:
Напиши bash-скрипт для изоляции подозрительного хоста в сети: блокировка исходящего трафика, остановка подозрительных процессов, сбор форензик-данных (дамп памяти, логи). Скрипт должен логировать действия.
Пример результата:
#!/bin/bash
iptables -A OUTPUT -m owner --uid-owner 1000 -j DROP
ps aux
| grep -i miner | awk '{print $2}' | xargs kill -9
cp /var/log/auth.log /forensics/
echo "Isolation completed at $(date)" >> /var/log/incident.log
11. Проверка конфигураций на соответствие CIS Benchmarks
Задача: Аудит конфигурации сервера.
Промт:
Проверь конфигурацию Nginx на соответствие CIS Benchmarks. Укажи несоответствия и рекомендации.
Конфиг:
server_tokens on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Пример результата:
Несоответствие: server_tokens on — раскрывает версию Nginx. Рекомендуется off.
Несоответствие: поддержка TLSv1 и TLSv1.1 — устаревшие протоколы. Оставить только TLSv1.2 и TLSv1.3.
12. Пост-инцидентный анализ и отчёт
Задача: Составить отчёт об инциденте для руководства.
Промт:
На основе следующих данных об инциденте (время, вектор атаки, затронутые системы, действия) составь отчёт по шаблону: резюме, хронология, root cause, принятые меры, рекомендации. Язык — деловой, без технического жаргона.
Данные: [вставить данные]
Пример результата:
Резюме: 10 сентября 2026 года произошла попытка несанкционированного доступа к API через SQL-инъекцию. Система обнаружения вторжений заблокировала запрос. Утечки данных не произошло.
Хронология: 10:00 — атака, 10:01 — блокировка, 10:05 — уведомление команды.
Root cause: устаревшая версия библиотеки ORM.
Меры: обновление библиотеки, патчинг.
Рекомендации: внедрить регулярный SAST-анализ.
Как внедрить промты в Secure SDLC
Эти 12 сценариев покрывают ключевые этапы: от проектирования (threat modeling) до реагирования на инциденты. Важно помнить: AI не заменяет эксперта, но ускоряет рутину. Например, в одном из кейсов компания из финансового сектора сократила время первичного анализа логов с 2 часов до 15 минут, используя промт №6. Главное — валидировать результаты и не передавать AI чувствительные данные без необходимости.
Попробуйте адаптировать эти промты под свой стек. Начните с базовых, постепенно переходя к экспертным. И помните: безопасность — это процесс, а не одноразовое действие. Подписывайтесь на обновления блога asibiont.com, чтобы получать больше практических материалов по AI в кибербезопасности.
Комментарии