# Проверка безопасности в Claude Code: инструкция за пять шагов > Пошаговое руководство по проверке безопасности проекта командой /security-review в Claude Code: запуск, настройка GitHub Action, примеры правил, типы уязвимостей и ограничения статического анализа. Source: https://ailoot.ai/blog/ru/claude-code-security-review/ Canonical: https://ailoot.ai/blog/ru/claude-code-security-review/ Language: ru Publisher: Ailoot (https://ailoot.ai/) Translation: guide-212 Revision: sha256-ce68ec12a95d6dc093b33c03d5ef90caadf4364035c30ab183ff2e79a794b8ba Автор исходной статьи рассказывает о проверке собственного проекта, созданного с помощью вайб-кодинга: команда за четыре минуты обнаружила несколько реальных проблем, которые затем удалось исправить. Раньше на такую проверку мог уйти целый день внешнего консультанта. Другие инструкции по настройке инструментов доступны в [документации Ailoot](https://ailoot.ai/docs/).
[Руководства Ailoot](https://ailoot.ai/docs/)
## Что представляет собой /security-review в Claude Code?
Ключевой вывод `/security-review` — встроенная команда Claude Code для анализа безопасности всего проекта или текущих изменений из терминала. Anthropic представила её 20 февраля 2026 года в составе Claude Code Security и открыла пользователям планов Pro, Max и API Console. Запрос оплачивается из обычного баланса Claude API.
Команду можно использовать двумя способами. Для локальной проверки запустите `/security-review` в терминале: Claude изучит репозиторий и подготовит отчёт. Серверный вариант — подключить тот же механизм как GitHub Action, чтобы он автоматически добавлял замечания к каждому Pull Request. Классические SAST-средства, например Snyk Code, Semgrep и SonarQube, проверяют код по заранее заданным правилам. `/security-review` вместо этого анализирует его с учётом контекста: прослеживает потоки данных, учитывает используемый фреймворк и границы доверия, благодаря чему может обнаружить проблемы, не описанные отдельным правилом.

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

— Anthropic, https://www.anthropic.com/news/claude-code-security
При этом `/security-review` не заменяет внешний пентест и динамические проверки на тестовом стенде. Команда может автоматизировать часть первоначального анализа, но доля покрытия аудита здесь не измерена. Ниже — порядок запуска и обзор того, что она может искать. ## Как запустить /security-review за пять шагов?
Ключевой вывод Обновите Claude Code, откройте проект в терминале и запустите `/security-review`. На анализ проекта среднего размера обычно уходит от одной до пяти минут. Изучите результаты с учётом severity и попросите Claude предложить исправления. Инструкция заявляет поддержку разных стеков, включая Next.js, Django, FastAPI, Rails, Go и Rust; отдельная настройка не требуется.
**Шаг 1. Обновите Claude Code.** Команда доступна начиная с релиза от 20 февраля 2026 года. ```bash claude update ``` Если Claude Code установлен через npm, обновить его можно и так: ```bash npm install -g @anthropic-ai/claude-code@latest ``` Убедитесь, что команда `/security-review` появилась: ```bash claude /help | grep security ``` **Шаг 2. Откройте проект и войдите в Claude Code.** ```bash 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 минут вместо запланированных трёх часов.
[Руководства Ailoot](https://ailoot.ai/docs/)
## Какие уязвимости может находить /security-review?
Ключевой вывод В перечень возможных находок входят SQL-инъекции и другие инъекции, XSS, ошибки аутентификации и авторизации, раскрытие чувствительных данных, уязвимости зависимостей и секреты, записанные прямо в коде. Проверка также может учитывать связь логики аутентификации между несколькими файлами — такие цепочки трудно описать набором отдельных правил.
Полный перечень проверок, включённых по умолчанию, приведён в [официальной документации Anthropic](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code): | Категория | Что проверяется | |----|----| | **SQL injection** | Конкатенация строк для построения SQL, небезопасные вызовы ORM (`raw()` без параметров), Prisma `$queryRawUnsafe` | | **XSS** | Использование `dangerouslySetInnerHTML` при выводе без очистки, шаблоны без автоматического экранирования, передача пользовательского ввода в `innerHTML` | | **Auth flaws** | Повторно используемые токены, отсутствие проверки прав в API-маршрутах, JWT без срока действия, фиксация сессии | | **Insecure data handling** | Проверка данных только на клиенте, избыточные поля в ответах (over-fetching), открытые перенаправления | | **Dependency vulnerabilities** | Уязвимые версии пакетов npm, pip и cargo; проверка с помощью `npm audit` и аналогичных инструментов | | **Secrets** | API-ключи, записанные в коде, токены в `.env.example`, пароли в исходниках | Кроме того, команда может проверять категории, которые не всегда покрываются автоматическими сканерами: - **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 для автоматической проверки?
Ключевой вывод Официальный `anthropics/claude-code-security-review@main` публикует замечания PR через workflow. Настройте `CLAUDE_API_KEY` и права workflow. Action предупреждает, что не укреплён против промпт-инъекций и предназначен для доверенных PR. Перед включением проверьте доступ участников и workflow.
**Шаг 1. Создайте API-ключ.** Войдите в [console.anthropic.com](https://console.anthropic.com/), создайте ключ API и скопируйте его. **Шаг 2. Добавьте ключ в секреты репозитория.** В GitHub откройте Settings → Secrets and variables → Actions → New repository secret. Укажите имя `CLAUDE_API_KEY` и вставьте ключ в качестве значения. **Шаг 3. Создайте workflow-файл.** Сохраните его как `.github/workflows/security.yml`: ```yaml 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 есть девять входных параметров для настройки проверки. Среди основных — `exclude-directories` для исключения каталогов, `false-positive-filtering-instructions` для передачи файла с пояснениями о безопасных для проекта конструкциях и `custom-security-scan-instructions` для дополнительных проверок, специфичных для предметной области.
Полный перечень параметров GitHub Action приведён в [README репозитория](https://github.com/anthropics/claude-code-security-review): | Input | По умолчанию | Назначение | |----|----|----| | `claude-api-key` | \- | API-ключ Anthropic; обязательный параметр. | | `comment-pr` | `true` | Определяет, публиковать ли inline-комментарии в PR. | | `upload-results` | `true` | Определяет, сохранять ли результат как artifact на 90 дней. | | `exclude-directories` | \- | Список каталогов через запятую, например `tests/,docs/,fixtures/`. | | `claude-model` | `claude-opus-4-1-20250805` | Модель для проверки. | | `claudecode-timeout` | `20` | Таймаут в минутах. | | `run-every-commit` | `false` | Запускать проверку при каждом push, а не только для PR. | | `false-positive-filtering-instructions` | \- | Путь к Markdown-файлу с правилами фильтрации. | | `custom-security-scan-instructions` | \- | Путь к Markdown-файлу с дополнительными проверками. | **Пример правил для фильтрации ложных срабатываний.** Создайте файл `.claude/security/false-positives.md`: ```markdown # 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: ```yaml - 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 ``` **Дополнительные инструкции по проверке безопасности** работают сходным образом. Создайте файл с требованиями, важными для конкретного проекта: ```markdown # Дополнительные проверки для нашего проекта - Любой эндпоинт под `/api/admin/*` должен проверять роль администратора через единый wrapper. Без этой обёртки - HIGH severity. - Все YooKassa / CloudPayments webhooks обязаны проверять подпись до парсинга тела. Без этого - HIGH severity. - Magic-link токены должны быть одноразовыми (помечаться как used после первого валидного запроса). Многоразовые - MEDIUM severity. ``` Эти правила не являются готовым пресетом Anthropic: они передают Claude ваши требования к проекту и помогают учитывать их при следующих проверках. ## Какие ограничения есть у /security-review?
Ключевой вывод Анализ исходников сам по себе не испытывает работающее приложение и не подтверждает развёрнутое окружение. Он может отметить возможные гонки, ошибки бизнес-логики и конфигурации, видимые в коде, но поведение и оставшиеся риски требуют тестов staging и проверки настоящего развёртывания.
В [README репозитория Anthropic](https://github.com/anthropics/claude-code-security-review) перечислены проверки, отключённые по умолчанию, и причины: - **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
Ключевой вывод В статье описан запуск `/security-review` на TypeScript-проекте с Next.js, Prisma, PostgreSQL и Redis. По словам автора, первичная проверка заняла четыре минуты, выявила несколько проблем разного уровня severity, а подготовка и применение исправлений — около полутора часов. Эти цифры относятся к опыту автора и не гарантируют такие же результаты на других проектах.
Автор указывает, что проверял проект, который уже работал в production, но ещё не проходил ревью. Среди отмеченных областей были логика аутентификации, обработка webhook от платёжной интеграции, загрузка файлов и вывод HTML. Детали находок в статье не приводятся; часть рекомендаций, по словам автора, уже была применена, а часть оставалась в PR. Автор также сообщает, что исключил из отчёта два типа результатов: - Предположения о DoS через регулярные выражения при проверке ввода, поскольку, по оценке автора, реальная нагрузка не проходила через эти выражения. - Замечание о ключе API в коде: это был тестовый ключ с явным префиксом `fake-` в фикстурах. По приведённой автором оценке, запуск занял четыре минуты, анализ отчёта — 25 минут, а применение исправлений и тестирование — около часа. В сумме от начала работы до слияния в main прошло примерно полтора часа. Сроки внешней проверки и её стоимость зависят от объёма и условий проекта. Основной практический вывод: `/security-review` помогает искать типичные ошибки в коде, но не заменяет внешний пентест. Перед публикацией проекта в интернете полезно включить такую проверку в процесс разработки, учитывая её ограничения и проверяя значимые результаты вручную. ## Как включить /security-review в процесс pre-commit?
Ключевой вывод Перед значимым коммитом выполните `/security-review` в сессии проекта, изучите находки, исправьте подтверждённое и повторите нужные тесты. Это процедура проверки, а не технический запрет коммита.
Ранее показанный hook с `git_commit`, `--severity HIGH` и `--fail-on-find` не является документированным рабочим рецептом и не должен использоваться защитным барьером. Проверенного локального hook блокировки коммитов статья не предоставляет. Официальный GitHub Action выше публикует замечания PR; наличие комментария не доказывает блокировку коммитов или слияний. Подробности о хуках собраны в руководстве [«Хуки в Claude Code»](https://ailoot.ai/blog/ru/claude-code-hooks/). Другой вариант — настроить [routines](https://ailoot.ai/blog/ru/claude-code-routines/): например, создать процедуру `pre-deploy-check`, которая одной командой запускает `/security-review`, `npm run build` и `npm run test`. Дополнительные инструкции доступны в документации Ailoot. При использовании [MCP-серверов](https://ailoot.ai/blog/ru/mcp-servers-claude-code/) результаты `/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, что ограничивает проверку изменениями в этом запросе на слияние. ## Источники
### Источники - [Anthropic — объявление о запуске Claude Code Security](https://www.anthropic.com/news/claude-code-security) — официальный анонс от 20 февраля 2026 года. - [Справочный центр Anthropic — автоматические проверки безопасности в Claude Code](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code) — официальная инструкция по запуску. - [GitHub: anthropics/claude-code-security-review](https://github.com/anthropics/claude-code-security-review) — репозиторий GitHub Action и его README. - [Документация Claude Code — проверка кода](https://code.claude.com/docs/en/code-review) — документация Anthropic. - [Справочный центр Anthropic — использование Claude Security](https://support.claude.com/en/articles/14661296-use-claude-security) — материалы о связанных продуктах. - [Port — приём результатов Claude Code Security Reviews](https://docs.port.io/guides/all/ingest-claude-code-security-reviews/) — инструкция по интеграции результатов в Internal Developer Portal. - [История изменений Claude Code](https://code.claude.com/docs/en/changelog) — история релизов.
Дополнительные инструкции по работе с инструментами доступны в [документации Ailoot](https://ailoot.ai/docs/).
[Руководства Ailoot](https://ailoot.ai/docs/)
[Перейти на сайт Ailoot](https://ailoot.ai/)
## Вопросы и ответы ### Доказывает ли чистый отчёт security-review безопасность приложения? Нет. Это начальная проверка кода с возможными пропусками и фильтрацией. Проверьте исправления, роли и одновременные действия на staging, а также настоящую конфигурацию развёртывания. ### Блокирует ли показанный GitHub Action коммиты или слияние автоматически? Показанный workflow этого не доказывает. Он публикует замечания PR. Проверьте их и испытайте подтверждённые исправления. Проверенного локального hook блокировки коммитов статья не даёт. ## Ailoot · Компания и портфель её проектов Ailoot опирается на накопленный опыт работы, большую клиентскую базу, стабильный сервис и постоянный контроль KPI. Компания и портфель её проектов: миллионы клиентов; продажи на миллиарды ежемесячно. Этот опыт Ailoot использует для API-доступа к нейросетям в продуктах клиентов, агентах, приложениях и автоматизациях.