Проверка безопасности в Claude Code: инструкция за пять шагов

Автор исходной статьи рассказывает о проверке собственного проекта, созданного с помощью вайб-кодинга: команда за четыре минуты обнаружила несколько реальных проблем, которые затем удалось исправить. Раньше на такую проверку мог уйти целый день внешнего консультанта.

Другие инструкции по настройке инструментов доступны в документации Ailoot.

Что представляет собой /security-review в Claude Code?#

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

Классические SAST-средства, например Snyk Code, Semgrep и SonarQube, проверяют код по заранее заданным правилам. /security-review вместо этого анализирует его с учётом контекста: прослеживает потоки данных, учитывает используемый фреймворк и границы доверия, благодаря чему может обнаружить проблемы, не описанные отдельным правилом.

При этом /security-review не заменяет внешний пентест и динамические проверки на тестовом стенде. Команда может автоматизировать часть первоначального анализа, но доля покрытия аудита здесь не измерена. Ниже — порядок запуска и обзор того, что она может искать.

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

Шаг 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

Согласно описанию команды, анализ проходит в три этапа:

1. Repository Context Research — изучение структуры проекта и используемого стека, поиск маршрутов и запросов к базе данных.
2. Comparative Analysis — сопоставление кода с типичными для этого стека шаблонами уязвимостей.
3. Vulnerability Assessment — формирование списка подозрений с оценкой уверенности от 1 до 10. В отчёт включаются результаты с 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. Попросите Claude подготовить исправления. Затем можно продолжить работу с агентом в обычном режиме:

«Исправь найденные проблемы уровня HIGH по одной и описывай каждую правку для PR».

Claude откроет соответствующие файлы и предложит изменения, а вы сможете их подтвердить. Автор статьи сообщает, что исправил пять найденных проблем за 40 минут вместо запланированных трёх часов.

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

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

Кроме того, команда может проверять категории, которые не всегда покрываются автоматическими сканерами:

• Command injection — выполнение команды оболочки с пользовательским вводом, например 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.

Для каждого результата указывается severity. В статье уровни описаны так:

• HIGH — удалённая эксплуатация без аутентификации либо раскрытие данных всех пользователей.
• MEDIUM — для эксплуатации нужны дополнительные условия, например действующая сессия или особый ввод.
• LOW — потенциальный вектор, который пока не считается критичным, но требует внимания.

Учитывайте также перечисленные в статье типы проблем, которые стандартная конфигурация не сообщает: DoS, отсутствие ограничения частоты запросов, исчерпание памяти, открытые перенаправления без подтверждённого воздействия, regex injection и ReDoS, подмена записей в логах. Это ограничение объясняется стремлением сократить шум. Если эти классы важны для проекта, правила проверки можно расширить — ниже описана настройка инструкций.

Как настроить 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. После этого action будет запускаться для новых PR.

Что выполняет action:

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

Права в permissions:

• pull-requests: write — разрешение публиковать inline-комментарии.
• contents: read — разрешение читать исходный код. Запись содержимого не запрашивается: action только формирует отчёт и не меняет файлы.

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

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

Полный перечень параметров 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

Дополнительные инструкции по проверке безопасности работают сходным образом. Создайте файл с требованиями, важными для конкретного проекта:

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

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

Эти правила не являются готовым пресетом Anthropic: они передают Claude ваши требования к проекту и помогают учитывать их при следующих проверках.

Какие ограничения есть у /security-review?#

В README репозитория Anthropic перечислены проверки, отключённые по умолчанию, и причины:

• Denial of Service — потенциально даёт много шумных результатов, часто с низким воздействием.
• Rate limiting concerns — ограничение частоты запросов обычно настраивается на уровне инфраструктуры.
• Memory / CPU exhaustion — аналогично, относится к исчерпанию системных ресурсов.
• Generic input validation without proven impact — проверка каждого поля без доказанного риска может приводить к большому числу ложных срабатываний.
• Open redirect — во многих случаях перенаправление предусмотрено логикой приложения.

Без доступа к работающему приложению Claude не может непосредственно проверить:

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

Поэтому одной статической проверки недостаточно для полного аудита. Дополнительно могут потребоваться динамические тесты на стенде, проверка ролевого доступа в административной панели, SAST-сканер с правилами под конкретный стек и ручная проверка production-конфигурации, включая Coolify, Nginx, Redis и S3.

После /security-review для более полного охвата всё ещё может понадобиться независимый внешний аудит, например раз в полгода; периодичность зависит от проекта и его рисков.

Как автор статьи проверял вайб-проект с помощью security review#

Автор указывает, что проверял проект, который уже работал в production, но ещё не проходил ревью. Среди отмеченных областей были логика аутентификации, обработка webhook от платёжной интеграции, загрузка файлов и вывод HTML. Детали находок в статье не приводятся; часть рекомендаций, по словам автора, уже была применена, а часть оставалась в PR.

Автор также сообщает, что исключил из отчёта два типа результатов:

• Предположения о DoS через регулярные выражения при проверке ввода, поскольку, по оценке автора, реальная нагрузка не проходила через эти выражения.
• Замечание о ключе API в коде: это был тестовый ключ с явным префиксом fake- в фикстурах.

По приведённой автором оценке, запуск занял четыре минуты, анализ отчёта — 25 минут, а применение исправлений и тестирование — около часа. В сумме от начала работы до слияния в main прошло примерно полтора часа. Сроки внешней проверки и её стоимость зависят от объёма и условий проекта.

Основной практический вывод: /security-review помогает искать типичные ошибки в коде, но не заменяет внешний пентест. Перед публикацией проекта в интернете полезно включить такую проверку в процесс разработки, учитывая её ограничения и проверяя значимые результаты вручную.

Как включить /security-review в процесс pre-commit?#

Ранее показанный hook с git_commit, --severity HIGH и --fail-on-find не является документированным рабочим рецептом и не должен использоваться защитным барьером. Проверенного локального hook блокировки коммитов статья не предоставляет. Официальный GitHub Action выше публикует замечания PR; наличие комментария не доказывает блокировку коммитов или слияний.

Подробности о хуках собраны в руководстве «Хуки в Claude Code».

Другой вариант — настроить routines: например, создать процедуру pre-deploy-check, которая одной командой запускает /security-review, npm run build и npm run test. Дополнительные инструкции доступны в документации Ailoot.

При использовании MCP-серверов результаты /security-review можно связать с системой учёта инцидентов, например Sentry, Linear или Notion, чтобы автоматически создавать тикет для каждой находки уровня HIGH.

Частые вопросы о /security-review#

Сколько стоит один запуск? Стоимость зависит от размера проекта. Автор статьи оценивает проверку своего проекта объёмом 30K строк в $0.30–0.50 из баланса API. Для репозитория на миллион строк он приводит ориентир до $5–8 за запуск. Это оценки автора, а фактическая сумма может отличаться.

Как часто запускать локальную проверку? Рассмотрите её перед значимыми коммитами, PR и выпусками. Проверенного автоматического hook блокировки коммитов статья не предоставляет.

С какими стеками работает команда? С теми, чей код Claude способен анализировать. Автор статьи сообщает о проверках Next.js и Node.js, Python (Django, FastAPI), Go, Rust, PHP (Laravel) и Ruby on Rails. Для редких языков, например Erlang, Elixir и Clojure, качество может быть ниже; результат зависит от проекта и контекста.

Как поступить, если Claude снова сообщает об одной и той же безопасной конструкции? Добавьте в false-positive-filtering-instructions пояснение, почему она безопасна в вашем проекте. Эти инструкции будут учитываться при следующих запусках.

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

Источники#

Дополнительные инструкции по работе с инструментами доступны в документации Ailoot.