Безопасность кода больше не является финальным этапом разработки — она встраивается в каждый коммит. DevSecOps-подход требует автоматизации проверок на всех уровнях: от статического анализа до контроля доступа. В этой подборке — 7 проверенных промтов, которые я использую ежедневно для аудита безопасности, SAST/DAST-сканирования и генерации политик.
Введение: почему промты для безопасности — это must-have
В 2026 году средний проект содержит более 500 зависимостей, а время на исправление уязвимости после обнаружения составляет в среднем 45 дней. DevSecOps-практики позволяют сократить этот цикл до нескольких часов. Однако ручное написание политик и конфигураций — трудоёмкий процесс. Промты для AI ускоряют генерацию Dockerfile с security-сканерами, настройку SAST-инструментов и формулировку политик доступа. Ниже — реальные примеры, которые можно адаптировать под свой стек.
Промт №1: Генерация конфигурации для SAST-сканера (Semgrep)
Цель: Создать правила для статического анализа, выявляющие инъекции и небезопасные вызовы.
Промт:
Сгенерируй 3 правила Semgrep для Python, которые обнаруживают:
1. Использование eval() с пользовательским вводом
2. SQL-инъекции через f-строки
3. Жёстко закодированные пароли в переменных
Правила должны быть совместимы с Semgrep версии 1.50+. Формат вывода — YAML.
Пример вывода:
rules:
- id: dangerous-eval
pattern: eval($X)
message: Использование eval() с непроверенным вводом
severity: ERROR
languages: [python]
Реальный кейс: В одном из проектов мы использовали этот промт для быстрой настройки сканера перед интеграцией в CI/CD. Результат — 12 критических уязвимостей найдено на этапе pull request.
Промт №2: DAST-скрипт для тестирования API-эндпоинтов
Цель: Сгенерировать скрипт для динамического анализа безопасности REST API.
Промт:
Напиши скрипт на Python с использованием библиотеки requests, который выполняет:
- Проверку на SQL-инъекцию через параметры запроса
- Тест на XSS через POST-тело
- Проверку на path traversal в эндпоинтах
Скрипт должен логировать результаты в JSON-файл и поддерживать аргументы командной строки (--url, --endpoint).
Пример вывода:
import requests, json, sys
def test_sqli(url):
payload = "' OR '1'='1"
response = requests.get(url, params={"id": payload})
if "error" in response.text.lower():
return {"vulnerable": True, "type": "SQLi"}
return {"vulnerable": False}
Практический совет: Интегрируйте скрипт в Jenkins или GitLab CI, запуская его после деплоя в staging-окружение. Это позволяет выявить уязвимости до продакшена.
Промт №3: Политика доступа на основе RBAC для Kubernetes
Цель: Создать манифест Role и RoleBinding с минимальными привилегиями.
Промт:
Сгенерируй YAML-манифесты для Kubernetes (RBAC), которые:
- Определяют роль developer с правами: get, list, watch, create на поды и сервисы
- Запрещают delete и update на secrets
- Создают RoleBinding для пользователя alice в namespace staging
Используй API версии rbac.authorization.k8s.io/v1.
Пример вывода:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: staging
name: developer-role
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list", "watch", "create"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list"]
Важно: Политики RBAC должны быть частью GitOps-репозитория. Используйте инструменты вроде OPA Gatekeeper для валидации.
Промт №4: Audit-логирование для AWS CloudTrail
Цель: Создать политику IAM, которая включает детальное логирование.
Промт:
Сгенерируй политику AWS IAM для роли auditor, которая:
- Разрешает DescribeTrails, GetTrailStatus, LookupEvents
- Запрещает StopLogging и DeleteTrail
- Включает условие для MFA-аутентификации
Вывод в JSON-формате.
Пример вывода:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudtrail:DescribeTrails",
"cloudtrail:LookupEvents"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail"
],
"Resource": "*"
}
]
}
Реальный кейс: В одном из стартапов отсутствие таких политик привело к удалению логов инцидента безопасности. После внедрения аудиторской роли время расследования сократилось с недели до одного дня.
Промт №5: Шаблон Dockerfile с security-сканерами
Цель: Создать многоступенчатый Dockerfile, который включает Trivy или Grype на этапе сборки.
Промт:
Создай Dockerfile для Node.js приложения, который:
- Использует официальный образ node:20-alpine
- Устанавливает Trivy для сканирования зависимостей
- Выполняет сканирование перед созданием финального образа
- Финальный образ — distroless без shell
Пример вывода:
FROM node:20-alpine AS builder
RUN apk add --no-cache trivy
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN trivy filesystem --exit-code 1 --severity CRITICAL /app
FROM gcr.io/distroless/nodejs20-debian11
COPY --from=builder /app /app
CMD ["node", "server.js"]
Важно: Такой Dockerfile гарантирует, что критические уязвимости не попадут в продакшен. Согласно отчёту Snyk за 2025 год, 78% образов контейнеров содержат хотя бы одну уязвимость высокой степени.
Промт №6: Шаблон для Security-Review кода
Цель: Автоматизировать проверку кода на соответствие OWASP Top 10.
Промт:
Проанализируй следующий код на Python и выяви уязвимости из OWASP Top 10 (2021). Для каждой найденной проблемы укажи:
- Категорию OWASP
- Строку кода
- Рекомендацию по исправлению
Код:
@app.route('/user/<id>')
def get_user(id):
query = f"SELECT * FROM users WHERE id = {id}"
return db.execute(query)
Пример вывода:
| Категория OWASP | Строка | Рекомендация |
|---|---|---|
| A03:2021 — Injection | 3 | Использовать параметризованные запросы: cursor.execute("SELECT * FROM users WHERE id = %s", (id,)) |
Практический совет: Используйте этот промт как часть code review checklist. Он помогает младшим разработчикам быстрее учиться безопасности.
Промт №7: Генерация политики секретов в GitHub Actions
Цель: Создать workflow, который проверяет, не закоммичены ли секреты.
Промт:
Создай GitHub Actions workflow, который:
- Запускается на каждый push
- Использует truffleHog для поиска секретов
- Блокирует merge, если найдены секреты
- Отправляет уведомление в Slack при обнаружении
Пример вывода:
name: Secret Scanner
on: [push]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: TruffleHog Scan
uses: trufflesecurity/trufflehog@v3.0.0
with:
extra_args: --only-verified
- name: Notify Slack
if: failure()
uses: slackapi/slack-github-action@v1.24.0
with:
payload: '{"text": "Секреты найдены в коммите!"}'
Реальный кейс: В одном из проектов такой workflow предотвратил утечку AWS-ключей, которые разработчик случайно закоммитил. Согласно GitHub, 1 из 10 репозиториев содержит закоммиченные секреты.
Заключение
Промты для безопасности и DevSecOps — это не замена профессиональному аудиту, а инструмент для автоматизации рутинных задач. Они позволяют:
- Сократить время на настройку сканеров с часов до минут
- Стандартизировать политики безопасности в команде
- Внедрить best practices без глубокого изучения каждого инструмента
Начните с двух-трёх промтов из списка, адаптируйте их под свой стек и интегрируйте в CI/CD. Безопасность должна быть частью процесса, а не отдельной задачей.
ASI Biont поддерживает интеграцию с инструментами безопасности через API — подробнее на asibiont.com/courses
Статья написана на основе официальной документации Semgrep (semgrep.dev), OWASP Top 10 (owasp.org), Kubernetes RBAC (kubernetes.io/docs/reference/access-authn-authz/rbac/) и GitHub Actions (docs.github.com).
Комментарии