Как провести security-ревью кода, который пишет ваш ИИ-агент для кодинга

ИИ-агенты для кодинга быстры, и эта скорость — палка о двух концах. Они с удовольствием сгенерируют работающую фичу за считаные минуты — и с тем же удовольствием соберут SQL-запрос через конкатенацию строк, запишут секрет в лог или пропустят проверку авторизации. Код работает, тесты проходят, а уязвимость уходит в продакшен. Security-ревью не опционально, когда печатает агент; это та часть, за которую по-прежнему отвечаете вы.

Вот практичный, не зависящий от инструментов рабочий процесс проверки кода, сгенерированного ИИ, до того как он попадёт в продакшен.

Знайте, что искать

Большинство реальных уязвимостей группируется в несколько шаблонов. Когда вы (или инструмент) проверяете вывод агента, сначала просканируйте на предмет вот этого:

• Инъекции (Injection) — SQL-, shell- или шаблонный ввод, собранный конкатенацией строк вместо параметризованных запросов.
• Межсайтовый скриптинг (XSS) — пользовательский ввод, отрисованный в HTML без экранирования.
• Сломанная аутентификация/авторизация — эндпоинты, которые проверяют, кто вы, но не имеете ли вы право; отсутствие проверок владения записями.
• Небезопасная работа с данными — секреты в коде, учётные данные в логах, чувствительные данные в сообщениях об ошибках.
• Уязвимые зависимости — пакет, добавленный агентом, с известными CVE.

Это близко соответствует OWASP Top 10 и ровно те категории, которые, по словам Anthropic, ищет её автоматическое security-ревью. Держать этот короткий список в голове — значит сделать ручную проверку намного эффективнее.

Пусть агент проверит сам себя — но в свежем контексте

Та же модель, что написала код, может его проверить, но не на одном дыхании. Агент, который только что 20 ходов подряд заставлял фичу работать, настроен её защищать. Начните новую сессию и дайте ему одну-единственную задачу: найти изъяны.

Промпт, который хорошо работает:

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

Пункт «concrete exploit scenario» — самое важное. Он заставляет модель доказать, что проблема реальна, а не перечислять расплывчатые шаблонные фразы вроде «подумайте о валидации ввода».

Обращайтесь к встроенным инструментам

Если вы используете Claude Code, есть специальная команда /security-review, которая анализирует ваши изменения на предмет распространённых шаблонов уязвимостей и, с вашего одобрения, применяет исправления напрямую. Она доступна на платных планах Pro и Max и на API-аккаунтах с оплатой по мере использования.

Для непрерывного покрытия Anthropic также выпускает открытый GitHub Action, который запускается на каждый pull request и оставляет встроенные комментарии ровно на тех строках, что его беспокоят. Подключение к репозиторию выглядит примерно так:

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

Теперь каждый PR — открыл ли его человек или агент — проходит проверку безопасности прежде, чем кто-либо нажмёт merge. Cursor, Copilot и другие ассистенты предлагают сопоставимые интеграции ревью; принцип один и тот же независимо от инструмента.

Не пропускайте детерминированные проверки

ИИ-ревью — мощное дополнение, а не замена скучной оснастки, которая никогда не устаёт:

• Сканирование зависимостей — npm audit, pip-audit или Dependabot ловят пакеты с известными уязвимостями, которые LLM не распознает по имени.
• Сканирование секретов — инструменты вроде gitleaks или push-защита GitHub не дают утёкшему ключу вообще попасть в историю.
• Статический анализ (SAST) — линтеры и инструменты вроде Semgrep единообразно применяют правила ко всей кодовой базе.

Используйте ИИ, чтобы рассуждать о логике и контексте — «может ли здесь аутентифицированный пользователь прочитать записи другого пользователя?» — и используйте детерминированные сканеры для механического, поддающегося сопоставлению по шаблону. Они закрывают слепые зоны друг друга.

Конкретный пример

Предположим, ваш агент генерирует такой эндпоинт:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

Проверка безопасности должна отметить две проблемы: запрос — это готовая вот-вот случиться SQL-инъекция (интерполированный invoice_id), и нет проверки того, что счёт действительно принадлежит user — любой залогиненный аккаунт может прочитать любой счёт, угадывая ID. Исправление — параметризованный запрос плюс фильтр по владению:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

Инъекция — из тех вещей, что ловит сканер. Отсутствующая проверка авторизации — из тех, что требуют человека — или ИИ-ревьюера с правильным промптом, — понимающего, для чего этот код. Вот это разделение и стоит держать в уме.

Вывод

Отnoситесь к каждому diff, который выдаёт ваш агент, как к недоверенному, пока он не пройдёт ревью — по тому же стандарту, что вы применили бы к первому pull request нового коллеги. Сочетайте ИИ-ревью в свежем контексте, автоматизированную проверку PR и детерминированные сканеры — и вы получите почти всю скорость разработки с помощью ИИ, не унаследовав его худших привычек.