Security review в Claude Code: пошаговая инструкция и автоматизация GitHub Action в 2026

Я только что прогнал security-review на собственном вайб-проекте, и команда за 4 минуты нашла несколько реальных проблем, которые уже исправлены. Это та же работа, на которую раньше уходил день внешнего консультанта.

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, истории, ошибки. Подпишись, чтобы быть в курсе.

Что такое /security-review в Claude Code?

Команда работает в двух режимах. Локальный - запускаешь /security-review в терминале, Claude читает репозиторий и выдаёт отчёт. Серверный - тот же движок ставится как GitHub Action и автоматически комментирует каждый Pull Request inline-комментами.

В отличие от классических SAST-сканеров (Snyk Code, Semgrep, SonarQube) /security-review не работает по фиксированным правилам. Он читает код как живой инженер - прослеживает поток данных, понимает, что у тебя за фреймворк, где границы доверия, и ловит уязвимости, которые правило не описывает.

Это не значит, что /security-review заменяет внешний пентест или live-тестирование на стенде. Это значит, что 80% типовой работы по проверке кода теперь автоматизируется одной командой. Ниже разберу, как её правильно запустить и что Claude найдёт у тебя на проекте.

Как запустить /security-review за 5 шагов?

Шаг 1. Обнови Claude Code. Команда работает начиная с релиза от 20 февраля 2026.

claude update

Если ставил Claude Code через npm, можно ещё так:

npm install -g @anthropic-ai/claude-code@latest

Проверь, что /security-review появилась:

claude /help | grep security

Шаг 2. Открой проект и войди в Claude Code.

cd ~/projects/my-vibe-project
claude

Шаг 3. Запусти команду. Внутри Claude Code просто введи:

/security-review

Claude автоматически проходит 3 фазы анализа:

1. Repository Context Research - читает структуру, понимает, что за стек, где роуты, где БД-запросы.
2. Comparative Analysis - сравнивает текущее состояние с типовыми паттернами уязвимостей для этого стека.
3. Vulnerability Assessment - выписывает каждое подозрение с уровнем уверенности по шкале 1-10. В отчёт идут только findings с confidence ≥ 8.

Шаг 4. Прочитай отчёт. Формат вывода - markdown-таблица. Для каждого нарушения Claude даёт:

• Файл и номер строки (например, src/auth/login.ts:42)
• Severity (HIGH / MEDIUM / LOW)
• Категория (sql_injection, xss, auth_bypass, insecure_storage)
• Описание - что не так
• Exploit Scenario - как атакующий может это использовать
• Recommendation - как починить

Шаг 5. Попроси применить фиксы. Дальше можно работать как с обычным агентом:

«Применяй HIGH-severity фиксы из отчёта, по одному, с описанием PR.»

Claude откроет каждый файл, предложит правку, ты подтверждаешь. На реальном проекте 5 находок я закрыл за 40 минут вместо запланированных 3 часов.

Хочешь не только запускать /security-review, но и собрать связку, которая делает Claude стабильным помощником? /security-review - один кирпичик. На практикуме за 3 эфира собираешь все три: ИИ-клон + Второй мозг + Контекст-инжиниринг. Именно эта связка превращает Claude из «помощника с галлюцинациями» в инструмент, которому можно доверить security-аудит и не получить кучу ложных тревог.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Набор открыт

Записаться →

Какие уязвимости находит /security-review?

Полный список того, что включено в анализ по умолчанию, описан в официальной документации Anthropic:

Дополнительно команда залезает в категории, которые редко покрывают автоматические сканеры:

• Command injection - shell-выполнение пользовательского ввода (child_process.exec(userInput))
• Path traversal - загрузка файла по ../../etc/passwd
• XXE - XML с внешними сущностями
• Template injection - SSTI в Jinja/Handlebars/EJS
• NoSQL injection - операторы $ne, $gt в MongoDB-запросах
• Crypto misuse - использование MD5, ECB-режим, статичный IV

Для каждой находки Claude даёт severity. Шкала простая:

• HIGH - удалённая эксплуатация без аутентификации, утечка данных всех пользователей
• MEDIUM - эксплуатация с дополнительными условиями (нужна сессия / специфичный input)
• LOW - потенциальный вектор, не критичный сейчас, но стоит починить

Полезно знать: в стандартной конфигурации Claude не репортит DoS, rate-limiting, memory exhaustion, open redirect без proven impact, regex injection / ReDoS, log spoofing. Это специально, чтобы не утопить тебя в шуме. Если эти классы важны - расширь правила (см. блок про false-positive filtering ниже).

Как настроить GitHub Action для автоматической проверки?

Шаг 1. Получи API-ключ. Зайди в console.anthropic.com, создай API-ключ, скопируй.

Шаг 2. Положи ключ в секреты репозитория. В GitHub: Settings → Secrets and variables → Actions → New repository secret. Имя - CLAUDE_API_KEY, значение - твой ключ.

Шаг 3. Создай workflow-файл. Сохрани под именем .github/workflows/security.yml:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

Шаг 4. Слей ветку в main. Со следующего PR действие запустится автоматически.

Что делает action:

• Срабатывает на каждый open / synchronize Pull Request.
• Берёт diff между PR-веткой и main.
• Запускает тот же движок, что локальная /security-review.
• Постит inline-комментарии прямо в строки кода с подозрением.
• Дублирует полный отчёт в Job Summary.

Важные детали в permissions:

• pull-requests: write - чтобы постить inline-комменты.
• contents: read - читать код. Без write. Action не модифицирует код сам, только репортит.

Для приватного репозитория этого набора достаточно. Для public-репо можешь дополнительно указать actions: read, если используешь reusable workflows.

Как фильтровать ложные срабатывания и менять чувствительность?

Полная таблица input'ов GitHub Action (источник: README репозитория):

Пример настройки фильтрации ложных срабатываний. Создаёшь файл .claude/security/false-positives.md:

# False positive filtering rules for our project

- Любой `dangerouslySetInnerHTML` внутри `src/lib/email/layout.ts` безопасен -
  HTML собирается из доверенных шаблонов и проходит через `sanitize-html`
  на этапе записи в БД, не на render-time.
- Хардкод тестовых API-ключей в `__tests__/fixtures/*.ts` не репортить.
  Все ключи начинаются с `sk-test-fake-`.
- SQL-конкатенация в `src/lib/admin/migrations.ts` допустима - файл выполняется
  только под root, входные данные из переменных окружения.

Подключаешь в workflow:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

Custom security scan instructions - симметричная штука. Создаёшь файл с правилами, которые именно для твоего проекта критичны:

# Дополнительные проверки для нашего проекта

- Любой эндпоинт под `/api/admin/*` должен проверять роль администратора
  через единый wrapper. Без этой обёртки - HIGH severity.
- Все YooKassa / CloudPayments webhooks обязаны проверять подпись до
  парсинга тела. Без этого - HIGH severity.
- Magic-link токены должны быть одноразовыми (помечаться как used после
  первого валидного запроса). Многоразовые - MEDIUM severity.

Это уже не пресет от Anthropic - ты переносишь свою экспертизу про проект в правила, которые Claude применяет каждый раз. То самое «методология важнее модели», на котором я делаю акцент в практикуме.

Подробнее про методологию контекста для Claude - в гайде «Как настроить CLAUDE.md» и «Второй мозг в Claude Code».

Что Claude НЕ ловит и почему - честные ограничения?

Anthropic честно перечисляет, что отключено по умолчанию и почему (источник: README репозитория):

• Denial of Service - слишком много шума, почти всегда low-impact.
• Rate limiting concerns - решается на уровне инфраструктуры, не в коде.
• Memory / CPU exhaustion - то же.
• Generic input validation without proven impact - валидация на каждом поле даёт false positive volcano.
• Open redirect - часто intended behavior.

Что Claude в принципе не видит без runtime-доступа:

• Конфигурация продакшен-сервера. NGINX-заголовки, CORS-политики, TLS-настройки, listening ports. Это надо проверять руками на стенде.
• Race conditions. Например, double-spend при одновременных запросах на возврат. Статический анализ их пропускает.
• Бизнес-логические дыры в платежах. Если у тебя сумма заказа считается на клиенте и просто отправляется в платёжку - это HIGH severity, но Claude не всегда видит этот паттерн без явного контекста о том, как должна работать оплата.
• IDOR на уровне БД. Если запрос SELECT * FROM orders WHERE id = $1 не проверяет WHERE user_id = $session.userId - Claude часто ловит. Но если проверка через ORM с middleware, где Claude не видит полный путь данных - может пропустить.
• Социальная инженерия / phishing-устойчивость. Никак не относится к коду.

Поэтому /security-review закрывает примерно 80% типового аудита за 5 минут. Оставшиеся 20% - dynamic testing на стенде, проверка прав по ролям в админке, SAST-сканер с правилами под твой стек, и ручная проверка production-конфигурации (Coolify / Nginx / Redis / S3).

Если для тебя 80% - уже огромный выигрыш, чем ноль, как было до февраля 2026 - подключай и пользуйся. Если хочешь 100% - после /security-review всё ещё нужен внешний аудит раз в полгода.

Как я прогнал security review на вайб-проекте

Что попалось. Типовая картина для среднего вайб-проекта на этапе «работает в проде, но не было ревью»: несколько подозрений по auth-флоу, по логике обработки webhook'ов из платёжной интеграции, по работе с загрузкой файлов, и пара точечных замечаний по обработке HTML на render-time. Я не описываю детали публично - часть рекомендаций уже применена, часть ещё едет в PR. Сам факт того, что 80% работы делается за 5 минут, а не за неделю - вот это и интересно.

Что выкинул как false positive:

• Находки про DoS через регулярки в input-валидации - реальная нагрузка не на этих регулярках.
• Одну находку про hardcoded API-ключ - это был тестовый ключ с явным префиксом fake- в фикстурах.

Сколько это заняло. Сам прогон - 4 минуты. Разбор отчёта - 25 минут. Применение фиксов - около часа с тестами. Итого примерно полтора часа от «начал» до «всё в main». Внешний пентест на ту же поверхность - неделя календарного времени и в десятки раз дороже.

Главный вывод. /security-review не заменяет внешний пентест. Но он закрывает основную массу типовых ошибок вайб-кодинга, которые эксплуатируют боты-сканеры в первые сутки после публикации в прод. Если у тебя проект в открытом интернете без прохождения через эту команду - ты несёшь риск, который убирается одной командой за 5 минут.

Как встроить /security-review в рутину pre-commit?

Базовый pre-commit hook в Claude Code описывается в .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "git_commit",
        "command": "claude /security-review --severity HIGH --fail-on-find"
      }
    ]
  }
}

Полный разбор хуков - в гайде «Хуки в Claude Code».

Альтернатива через routines - сделать рутину pre-deploy-check, которая запускает /security-review + npm run build + npm run test одной командой. Этот же сценарий разбираю на втором эфире практикума.

Если используешь MCP-серверы - можно интегрировать findings из /security-review с системой инцидентов (Sentry, Linear, Notion), чтобы каждое HIGH автоматически становилось тикетом.

FAQ про /security-review

Сколько стоит один прогон? Зависит от размера проекта. На моих 30K строк один прогон тратит примерно $0.30-0.50 API-баланса. Большой энтерпрайз-репозиторий в миллион строк - до $5-8 за прогон. Это в десятки раз дешевле любого SaaS-сканера с подпиской.

Как часто запускать локально? Минимум - перед каждой публикацией в продакшен. Лучше - перед каждым PR. Идеально - через хук на каждый коммит с фильтром только по HIGH severity, чтобы не задерживать рабочий цикл.

На каком стеке работает? На любом, который Claude умеет читать. Проверено лично: Next.js / Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel), Ruby on Rails. На совсем экзотических языках (Erlang, Elixir, Clojure) качество ниже, но что-то найдёт.

Что делать, если Claude каждый раз находит одну и ту же «уязвимость», которая на самом деле не уязвимость? Добавь её в false-positive-filtering-instructions с объяснением «почему это безопасно». В следующих прогонах Claude перестанет об этом репортить.

Можно ли запустить только на конкретные файлы? Локально - да, просто запусти /security-review src/lib/auth/*.ts. В GitHub Action работает только diff текущего PR, что обычно и есть «конкретные файлы».

Sources

Полная схема по вайб-кодингу за вечер: ИИ-клон + Второй мозг + Контекст-инжиниринг. На практикуме показываю, как из этих трёх китов собирается рабочий процесс, в котором /security-review становится одним из понятных инструментов в общей связке.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Набор открыт

Записаться →