security-reviewer - Аудит кода и оценка уязвимостей

Когда звать

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

Что проверяет Security Reviewer

Security Reviewer предназначен для аудита кода, зависимостей и инфраструктуры. В прочитанном файле версии 1.1.1 автор выделяет аутентификацию, авторизацию, пользовательский ввод, криптографию и поиск секретов. Ожидаемый результат - отчёт с оценкой важности и исправлениями, а не автоматически защищённое приложение.

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

Автоматические инструменты и ручной разбор

В рабочем процессе перечислены Semgrep, Bandit, Gitleaks, npm audit и Trivy. Автор предлагает сначала использовать автоматический поиск, а затем вручную читать авторизацию, обработку входа и криптографические решения. Отказываться от ручной части после чистого отчёта сканера запрещено.

При этом в заголовке SKILL.md поле allowed-tools ограничено Read, Grep и Glob. Поэтому доступ к запуску сканеров нельзя считать подтверждённым самим файлом. В клиенте, который применяет это ограничение, агенту может потребоваться уже подготовленный вывод проверок или отдельно разрешённый исполнитель.

Это полезно учитывать до задания: «Сделайте аудит» не должно заканчиваться выдуманным выводом утилит, которые агент не мог запустить. Статический разбор предоставленных файлов и реальный запуск инструмента должны быть разделены в отчёте.

Как автор требует описывать находки

Для каждого замечания нужны конкретное место в файле, последствия и способ исправления. Важность оценивается последовательно по уровням Critical, High, Medium, Low и Info с использованием CVSS. Даже низкие уровни инструкция запрещает просто игнорировать.

В учебном примере показана SQL-инъекция из-за подстановки пользовательского ввода в строку запроса. Предложенное направление исправления - параметры запроса или ORM. Оценка и номер строки в этом примере относятся только к иллюстрации автора, не к вашему проекту.

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

С чего начать без активных испытаний

Пример задания: «Прочитайте модуль авторизации и предоставленный отчёт зависимостей. Проверьте границы доступа и попадание секретов в ответы. Для каждой находки укажите файл, условие возникновения и минимальное исправление. Сетевых проверок не запускайте». Это задаёт понятный статический объём работы.

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

Мы прочитали основной документ и MIT-лицензию одного коммита. Сканеры, установку и испытания скилла не запускали, включая Codex. Для написания защитного кода коллекция отдельно содержит Secure Code Guardian, а для широкого ревью - Code Reviewer.