раздел 11 · рецепт

Security-аудит

Security-аудит - то, что должно происходить минимум перед каждым крупным релизом и при каждой смене авторизации/работы с деньгами/работы с PII. С Claude Code это не страшный многонедельный процесс, а одна команда /security-review + час осознанной работы.

Когда применять

  • Перед публичным запуском продукта
  • После добавления авторизации или работы с платежами
  • Когда подключаете новую внешнюю интеграцию
  • После того, как PII (имена, телефоны, документы) появились в системе
  • Раз в квартал на действующем продукте

Шаги

Шаг 1. Автоматический security-review

В Claude Code:
/security-review

Что делает:
- Просматривает текущие изменения (diff с main)
- Проверяет паттерны OWASP top 10
- Ищет хардкод секретов
- Анализирует контекст: где входная точка, какие данные принимаются
- Возвращает приоритизированный отчёт с severity

Это первый проход. Берите топ-priority находки, остальные - на ревью человеком.

Шаг 2. OWASP top 10 - ручной чек-лист

Запустите для каждого пункта:

Промпт:
"Проверь код на OWASP A01:2021 - Broken Access Control.
Найди все endpoints, ищи:
- Где роль/owner проверяется в начале, а не в конце
- Где user_id берётся из request body вместо JWT
- IDOR - где id запрашиваемого ресурса не сверяется с owner
- Privilege escalation - где роль меняется без проверки текущей
Верни таблицу endpoint:уязвимость:как исправить."

Повторите для:

OWASPЧто искать
A01 Broken Access ControlIDOR, отсутствие проверки роли, privilege escalation
A02 Cryptographic FailuresСлабые алгоритмы (MD5, SHA1), хранение паролей в plain
A03 InjectionSQL/NoSQL/Command injection, XSS, template injection
A04 Insecure DesignОтсутствие rate limiting, captcha, валидации
A05 Security MisconfigurationDefault credentials, debug-режим в проде, открытый /admin
A06 Vulnerable ComponentsУстаревшие зависимости с известными CVE
A07 Identification & AuthenticationСлабые пароли, отсутствие 2FA, session fixation
A08 Software & Data IntegrityUnsigned обновления, eval() с user-input
A09 Security Logging FailuresНет логирования критических событий (login, payment)
A10 SSRFЗапрос на user-controlled URL без whitelisting

Шаг 3. Поиск утечек секретов

# Поиск секретов в git-истории
pip install gitleaks
gitleaks detect --source . --verbose

# Или через Claude

Промпт:
"Просканируй весь репозиторий на наличие хардкод-секретов:
- API-ключи (паттерны: AIza..., sk-..., AKIA..., AAAA...)
- Пароли в коде ("password": "...")
- Приватные ключи (-----BEGIN PRIVATE KEY-----)
- Connection strings с паролем
Используй grep и регулярки. Включи .git/ историю.
Не репортуй примеры в .env.example и тестовые фикстуры."

Шаг 4. Аудит зависимостей

# Node
pnpm audit
npm audit --audit-level=moderate

# Python
pip-audit
safety check

# Universal
trivy fs .

Шаг 5. Headers и CORS

Промпт:
"Проверь HTTP-headers нашего API:
- Strict-Transport-Security есть?
- X-Frame-Options или Content-Security-Policy?
- X-Content-Type-Options: nosniff?
- Referrer-Policy?
CORS:
- Allow-Origin не *, если cookies?
- Allow-Credentials с осознанием рисков?
- Whitelist origins, не regex .* ?
Покажи curl-команду для проверки и предложи middleware."

Шаг 6. Финальный отчёт

После всех проходов:

Промпт:
"Сведи все findings в один отчёт:
- Критические (фиксить до релиза)
- Высокие (фиксить в этом спринте)
- Средние (план на квартал)
- Низкие (бэклог)
Для каждого: что, где, как эксплуатировать, как фиксить.
Формат: Markdown, можно отправить команде."

Антипаттерны

Что не делатьПочему
Аудит только перед прод-релизомБезопасность - не финальный чек, она в каждом PR.
Игнорировать «low severity»Несколько low может комбинироваться в high.
Удалять console.log как «security fix»Утечка через логи - это другая проблема.
Менять секрет, но не ротировать его на продеХакер уже знает старый, он работает.
Доверять «AI-сгенерированный fix» без ревьюИногда Claude добавляет уязвимости, фиксируя другие.

Полезные ссылки