Процесс код-ревью: /code-review и аудит безопасности

Чему вы научитесь

Код-ревью — ключевой этап обеспечения качества и безопасности кода. Этот урок поможет вам:

✅ Использовать команду /code-review для автоматической проверки изменений
✅ Понять разницу между агентами code-reviewer и security-reviewer
✅ Освоить чек-лист безопасности (OWASP Top 10)
✅ Обнаруживать и исправлять типичные уязвимости (SQL-инъекции, XSS, захардкоженные ключи и др.)
✅ Применять стандарты качества кода (размер функций, длина файлов, покрытие тестами и др.)
✅ Понимать критерии одобрения (CRITICAL, HIGH, MEDIUM, LOW)

Ваша текущая проблема

Вы написали код и готовы его закоммитить, но:

❌ Не знаете, есть ли в коде уязвимости безопасности
❌ Беспокоитесь, что упустили проблемы с качеством кода
❌ Не уверены, соблюдены ли лучшие практики
❌ Ручная проверка отнимает много времени и легко что-то пропустить
❌ Хотите автоматически находить проблемы до коммита

Процесс код-ревью Everything Claude Code решает эти проблемы:

Автоматическая проверка: команда /code-review автоматически анализирует все изменения
Специализированное ревью: агент code-reviewer фокусируется на качестве кода, security-reviewer — на безопасности
Классификация по серьёзности: проблемы распределяются по уровням (CRITICAL, HIGH, MEDIUM, LOW)
Детальные рекомендации: каждая проблема содержит конкретные советы по исправлению

Когда использовать этот подход

Перед каждым коммитом следует запускать код-ревью:

✅ После завершения новой функциональности
✅ После исправления бага
✅ После рефакторинга кода
✅ При добавлении API-эндпоинтов (обязательно запустите security-reviewer)
✅ При обработке пользовательского ввода (обязательно запустите security-reviewer)
✅ При работе с аутентификацией/авторизацией (обязательно запустите security-reviewer)

Лучшая практика

Выработайте привычку: перед каждым git commit сначала запускайте /code-review. Если есть проблемы CRITICAL или HIGH — исправьте их перед коммитом.

🎒 Подготовка

Что вам понадобится:

Установленный Everything Claude Code (если ещё не установлен, см. Быстрый старт)
Некоторые изменения в коде (можно сначала написать код с помощью /tdd)
Базовое понимание работы с Git

Что не требуется:

Не нужно быть экспертом по безопасности (агент поможет с обнаружением)
Не нужно помнить все лучшие практики безопасности (агент напомнит)

Основная концепция

Everything Claude Code предоставляет два специализированных агента для ревью:

Агент code-reviewer

Фокусируется на качестве кода и лучших практиках, проверяет:

Качество кода: размер функций (>50 строк), длина файлов (>800 строк), глубина вложенности (>4 уровня)
Обработка ошибок: отсутствие try/catch, операторы console.log
Стандарты кода: соглашения об именовании, дублирование кода, иммутабельные паттерны
Лучшие практики: использование эмодзи, TODO/FIXME без номера тикета, отсутствие JSDoc
Покрытие тестами: отсутствие тестов для нового кода

Сценарии использования: все изменения кода должны проходить через code-reviewer.

Агент security-reviewer

Фокусируется на уязвимостях безопасности и угрозах, проверяет:

OWASP Top 10: SQL-инъекции, XSS, CSRF, обход аутентификации и др.
Утечка секретов: захардкоженные API-ключи, пароли, токены
Валидация ввода: отсутствующая или некорректная валидация пользовательского ввода
Аутентификация и авторизация: некорректная проверка подлинности и прав доступа
Безопасность зависимостей: устаревшие или уязвимые пакеты зависимостей

Сценарии использования: код, связанный с безопасностью (API, аутентификация, платежи, пользовательский ввод), обязательно должен проходить через security-reviewer.

Классификация серьёзности проблем

Уровень	Значение	Блокирует коммит?	Примеры
CRITICAL	Критическая уязвимость или серьёзная проблема качества	❌ Обязательно блокирует	Захардкоженный API-ключ, SQL-инъекция
HIGH	Важная проблема безопасности или качества кода	❌ Обязательно блокирует	Отсутствие обработки ошибок, XSS-уязвимость
MEDIUM	Проблема среднего приоритета	⚠️ Можно коммитить с осторожностью	Использование эмодзи, отсутствие JSDoc
LOW	Незначительная проблема	✓ Можно исправить позже	Несогласованное форматирование, магические числа

Практика: первое код-ревью

Шаг 1: Создайте изменения в коде

Сначала напишите простой API-эндпоинт с помощью /tdd (с некоторыми проблемами безопасности):

bash

/tdd

Попросите Claude Code создать API для входа пользователя, код будет примерно таким:

typescript

// src/api/login.ts
export async function loginUser(email: string, password: string) {
  const query = `SELECT * FROM users WHERE email = '${email}'`  // ❌ Риск SQL-инъекции
  const user = await db.query(query)
  
  if (user.password === password) {  // ❌ Сравнение пароля в открытом виде
    const token = generateToken(user.id)
    console.log('User logged in:', { email, password })  // ❌ Утечка пароля в логах
    return { token }
  }
}

Почему Этот код содержит несколько уязвимостей безопасности и проблем качества — идеально подходит для демонстрации функции код-ревью.

Ожидаемый результат: файл с кодом создан.

Шаг 2: Запустите код-ревью

Теперь выполните команду /code-review:

bash

/code-review

Почему/code-review автоматически вызывает агента code-reviewer для проверки всех незакоммиченных изменений.

Ожидаемый результат: агент начинает анализировать код, затем выводит отчёт о ревью.

Шаг 3: Изучите отчёт о ревью

code-reviewer выведет отчёт примерно такого вида:

markdown

# Code Review Report

## Critical Issues (Fix Immediately)

### 1. [CRITICAL] Hardcoded credentials
**File:** src/api/login.ts:3
**Issue:** Password logging in console
**Fix:** Remove password from logs, only log user ID

```typescript
// ❌ Bad
console.log('User logged in:', { email, password })

// ✓ Good
console.log('User logged in:', { email, userId: user.id })

2. [CRITICAL] SQL injection vulnerability

File: src/api/login.ts:2 Issue: String concatenation in SQL query Fix: Use parameterized queries

typescript

// ❌ Bad
const query = `SELECT * FROM users WHERE email = '${email}'`

// ✓ Good
const { data } = await supabase
  .from('users')
  .select('*')
  .eq('email', email)

High Issues (Fix Before Production)

3. [HIGH] Plaintext password comparison

File: src/api/login.ts:4 Issue: Password stored in plaintext Fix: Use bcrypt to hash passwords

typescript

// ❌ Bad
if (user.password === password) {

// ✓ Good
import bcrypt from 'bcrypt'
const isValid = await bcrypt.compare(password, user.password)

Recommendations

Add input validation for email format
Add rate limiting to prevent brute force attacks
Use JWT tokens instead of generating custom tokens

Approval Status

❌ BLOCKED - 2 CRITICAL issues found

Please fix all CRITICAL and HIGH issues before committing.


**Почему**
Отчёт классифицирует проблемы по серьёзности, каждая проблема содержит местоположение, описание, рекомендации по исправлению и примеры кода.

**Ожидаемый результат**: понятный отчёт о ревью с указанием всех проблем и рекомендаций по исправлению.

---

### Шаг 4: Исправьте проблемы

Исправьте код согласно отчёту:

```typescript
// src/api/login.ts
import bcrypt from 'bcrypt'
import { z } from 'zod'

const LoginSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8)
})

export async function loginUser(input: unknown) {
  // Валидация ввода
  const validated = LoginSchema.parse(input)
  
  // Параметризованный запрос (защита от SQL-инъекций)
  const { data: user } = await supabase
    .from('users')
    .select('*')
    .eq('email', validated.email)
    .single()
  
  if (!user) {
    throw new Error('Invalid credentials')
  }
  
  // Сравнение хешированных паролей
  const isValid = await bcrypt.compare(validated.password, user.password_hash)
  
  if (isValid) {
    const token = generateToken(user.id)
    console.log('User logged in:', { email: validated.email, userId: user.id })
    return { token }
  }
  
  throw new Error('Invalid credentials')
}

Почему Исправлены все проблемы CRITICAL и HIGH, добавлена валидация ввода и сравнение хешированных паролей.

Ожидаемый результат: код обновлён, уязвимости безопасности устранены.

Шаг 5: Повторное ревью

Снова запустите /code-review:

bash

/code-review

Почему Проверяем, что все проблемы исправлены и код готов к коммиту.

Ожидаемый результат: отчёт об успешном прохождении примерно такого вида:

markdown

# Code Review Report

## Summary

- **Critical Issues:** 0 ✓
- **High Issues:** 0 ✓
- **Medium Issues:** 1 ⚠️
- **Low Issues:** 1 💡

## Medium Issues (Fix When Possible)

### 1. [MEDIUM] Missing JSDoc for public API
**File:** src/api/login.ts:9
**Issue:** loginUser function missing documentation
**Fix:** Add JSDoc comments

```typescript
/**
 * Authenticates a user with email and password
 * @param input - Login credentials (email, password)
 * @returns Object with JWT token
 * @throws Error if credentials invalid
 */
export async function loginUser(input: unknown) {

Low Issues (Consider Fixing)

2. [LOW] Add rate limiting

File: src/api/login.ts:9 Issue: Login endpoint lacks rate limiting Fix: Add express-rate-limit middleware

typescript

import rateLimit from 'express-rate-limit'

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5 // 5 attempts per window
})

app.post('/api/login', loginLimiter, loginUser)

Approval Status

✅ APPROVED - No CRITICAL or HIGH issues

Note: Medium and Low issues can be fixed in follow-up commits.


**Ожидаемый результат**: ревью пройдено, код готов к коммиту.

---

### Шаг 6: Специализированный аудит безопасности (опционально)

Если ваш код связан с API-эндпоинтами, аутентификацией, платежами или другими чувствительными функциями, можно отдельно вызвать security-reviewer:

```bash
/security-reviewer

Почему security-reviewer проводит более глубокий анализ по OWASP Top 10, проверяя больше паттернов уязвимостей.

Ожидаемый результат: детальный отчёт о безопасности, включающий анализ OWASP, проверку уязвимостей зависимостей, рекомендации по инструментам безопасности и др.

Контрольная точка ✅

После выполнения вышеуказанных шагов вы должны:

✅ Уметь запускать команду /code-review
✅ Понимать структуру и содержание отчёта о ревью
✅ Уметь исправлять проблемы кода на основе отчёта
✅ Знать, что проблемы CRITICAL и HIGH обязательно нужно исправить
✅ Понимать разницу между code-reviewer и security-reviewer
✅ Выработать привычку проводить ревью перед коммитом

Типичные ошибки

Ошибка 1: Пропуск код-ревью

Проблема: Считаете код простым и коммитите напрямую, не запуская ревью.

Последствия: Можно пропустить уязвимости безопасности, получить отказ от CI/CD или вызвать инцидент в продакшене.

Правильный подход: Выработайте привычку запускать /code-review перед каждым коммитом.

Ошибка 2: Игнорирование проблем MEDIUM

Проблема: Видите проблемы MEDIUM и не обращаете на них внимания, они накапливаются.

Последствия: Качество кода снижается, технический долг растёт, поддержка становится сложнее.

Правильный подход: Хотя проблемы MEDIUM не блокируют коммит, их следует исправлять в разумные сроки.

Ошибка 3: Ручное исправление SQL-инъекций

Проблема: Пишете собственное экранирование строк вместо использования параметризованных запросов.

Последствия: Экранирование может быть неполным, риск SQL-инъекции сохраняется.

Правильный подход: Всегда используйте ORM или параметризованные запросы, не собирайте SQL вручную.

Ошибка 4: Путаница между двумя reviewer'ами

Проблема: Для всего кода запускаете только code-reviewer, игнорируя security-reviewer.

Последствия: Уязвимости безопасности могут быть пропущены, особенно в коде, связанном с API, аутентификацией, платежами.

Правильный подход:

Обычный код: code-reviewer достаточно
Код, связанный с безопасностью: обязательно запускайте также security-reviewer

Итоги урока

Процесс код-ревью — одна из ключевых функций Everything Claude Code:

Функция	Агент	Что проверяет	Серьёзность
Ревью качества кода	code-reviewer	Размер функций, обработка ошибок, лучшие практики	HIGH/MEDIUM/LOW
Аудит безопасности	security-reviewer	OWASP Top 10, утечка секретов, уязвимости инъекций	CRITICAL/HIGH/MEDIUM

Ключевые выводы:

Перед каждым коммитом запускайте /code-review
Проблемы CRITICAL/HIGH обязательно исправляйте перед коммитом
Код, связанный с безопасностью, обязательно проверяйте через security-reviewer
Отчёт о ревью содержит точное местоположение и рекомендации по исправлению
Выработайте привычку: ревью → исправление → повторное ревью → коммит

Анонс следующего урока

В следующем уроке мы изучим Автоматизация с Hooks.
Вы узнаете:
Что такое Hooks и как автоматизировать процесс разработки
Как использовать 15+ автоматических хуков
Как настроить Hooks под потребности проекта
Сценарии применения SessionStart, SessionEnd, PreToolUse и других хуков

Приложение: справка по исходному коду

Нажмите, чтобы развернуть расположение исходного кода

Дата обновления: 2026-01-25

Функция	Путь к файлу	Номер строки
---	---	---
---	---	---
---	---	---
---	---	---

Ключевые константы:

Лимит размера функции: 50 строк (code-reviewer.md:47)
Лимит размера файла: 800 строк (code-reviewer.md:48)
Лимит глубины вложенности: 4 уровня (code-reviewer.md:49)

Ключевые функции:

/code-review: вызывает агента code-reviewer для ревью качества кода
/security-reviewer: вызывает агента security-reviewer для аудита безопасности
git diff --name-only HEAD: получает список незакоммиченных изменённых файлов (code-review.md:5)

Критерии одобрения (code-reviewer.md:90-92):

✅ Approve: No CRITICAL or HIGH issues
⚠️ Warning: MEDIUM issues only (can merge with caution)
❌ Block: CRITICAL or HIGH issues found

Процесс код-ревью: /code-review и аудит безопасности ​

Чему вы научитесь ​

Ваша текущая проблема ​

Когда использовать этот подход ​

🎒 Подготовка ​

Основная концепция ​

Агент code-reviewer ​

Агент security-reviewer ​

Классификация серьёзности проблем ​

Практика: первое код-ревью ​

Шаг 1: Создайте изменения в коде ​

Шаг 2: Запустите код-ревью ​

Шаг 3: Изучите отчёт о ревью ​

2. [CRITICAL] SQL injection vulnerability ​

High Issues (Fix Before Production) ​

3. [HIGH] Plaintext password comparison ​

Recommendations ​

Approval Status ​

Шаг 5: Повторное ревью ​

Low Issues (Consider Fixing) ​

2. [LOW] Add rate limiting ​

Approval Status ​

Контрольная точка ✅ ​

Типичные ошибки ​

Ошибка 1: Пропуск код-ревью ​

Ошибка 2: Игнорирование проблем MEDIUM ​

Ошибка 3: Ручное исправление SQL-инъекций ​

Ошибка 4: Путаница между двумя reviewer'ами ​

Итоги урока ​

Анонс следующего урока ​

Приложение: справка по исходному коду ​

Процесс код-ревью: /code-review и аудит безопасности

Чему вы научитесь

Ваша текущая проблема

Когда использовать этот подход

🎒 Подготовка

Основная концепция

Агент code-reviewer

Агент security-reviewer

Классификация серьёзности проблем

Практика: первое код-ревью

Шаг 1: Создайте изменения в коде

Шаг 2: Запустите код-ревью

Шаг 3: Изучите отчёт о ревью

2. [CRITICAL] SQL injection vulnerability

High Issues (Fix Before Production)

3. [HIGH] Plaintext password comparison

Recommendations

Approval Status

Шаг 5: Повторное ревью

Low Issues (Consider Fixing)

2. [LOW] Add rate limiting

Approval Status

Контрольная точка ✅

Типичные ошибки

Ошибка 1: Пропуск код-ревью

Ошибка 2: Игнорирование проблем MEDIUM

Ошибка 3: Ручное исправление SQL-инъекций

Ошибка 4: Путаница между двумя reviewer'ами

Итоги урока

Анонс следующего урока

Приложение: справка по исходному коду