| name | security-audit |
| description | Комплексный аудит безопасности приложений, API, репозиториев, AI/agent-систем, MCP-интеграций, инфраструктуры и цепочки поставок. Использовать при явном запросе — «аудит безопасности», «security audit», «проверь на уязвимости», «security review», «threat model», «hardening», «проверка перед продакшеном», «prompt injection», «MCP security», — а также при secure-design review или планировании авторизованного пентеста. Не использовать для обычного code review, отладки или рефакторинга без запроса о безопасности. |
Security Audit
Версия методики: 3.1. Срез сверки источников — 2026-08-22, перечень в references/sources.md.
Срез — дата последней проверки версий стандартов, а не гарантия их актуальности. Чем дальше текущая дата от среза, тем обязательнее перепроверка по правилу 8: версии ASVS, OWASP, MCP и статус CVE меняются между аудитами.
Проводить доказательный аудит безопасности с явными границами полномочий. По умолчанию работать только с доступными локальными материалами и не менять проверяемую систему.
Непереговорные правила
- Не расширять объект, окружение или способ проверки сверх запроса пользователя.
- Если режим не указан, выбирать
audit.
- Не считать разрешение на аудит разрешением на эксплуатацию уязвимостей, сетевое сканирование, нагрузочное тестирование, изменение файлов, установку зависимостей или исправление кода.
- До действий определить фактический корень проекта, прочитать применимые инструкции репозитория и проверить текущее состояние рабочей копии. Не очищать и не перезаписывать чужие изменения.
- Не раскрывать секреты. В отчёте указывать тип, расположение и редактированный отпечаток, но не значение ключа, токена, cookie, пароля или приватного материала.
- Не объявлять уязвимость без доказанного пути к воздействию либо явно маркировать её как гипотезу.
- Проверять контрдоказательства: защитный middleware, deny-by-default, ограничения базы, тесты, инфраструктурные политики, недостижимость и компенсирующие меры. Сюда же относятся задокументированные в репозитории осознанные решения — принятый риск, компенсирующая мера, намеренное поведение вроде fail-open. Такое решение не закрывает находку само по себе, но обязано быть названо и оценено: если вывод аудита с ним расходится, объяснить, чем обоснование не покрывает найденный путь.
- Все меняющиеся сведения — версии стандартов, CVE, affected/fixed ranges, KEV, законодательство, облачные настройки — проверять по первичному источнику на дату аудита. Если это невозможно, сообщать, что проверка не выполнена.
Режимы
| Режим | Назначение | Допустимые действия |
|---|
audit | Режим по умолчанию | Чтение кода, конфигурации, документации и уже имеющихся результатов; безопасные локальные команды без изменения состояния |
plan | Проектирование проверки | Threat model, перечень доказательств, тест-план и правила проведения без запуска тестов |
verify | Проверка гипотез | Локальные тесты, существующие анализаторы и изолированные fixtures без обращения к production |
active-test | Активная проверка работающей системы | Только после явного подтверждения полномочий и правил из references/active-testing.md |
remediate | Исправление | Только по явному запросу; минимальные изменения с проверкой регрессий |
Если запрос смешивает режимы, сначала выполнить безопасную часть и отдельно обозначить, какая авторизация нужна для остального.
Маршрутизация материалов
- Для полного аудита или выбора доменов прочитать references/controls.md.
- При наличии LLM, RAG, agents, tools, memory или MCP прочитать references/ai-mcp.md.
- Если в репозитории есть агентные артефакты — каталог
.claude/, скиллы, команды, hooks, конфигурации MCP-клиентов, промпты и автоматизации, порождающие коммиты, — проверить их как отдельную поверхность по разделу 15 references/controls.md.
- Перед любым активным воздействием прочитать references/active-testing.md.
- При запросе о законах, стандартах соответствия или сертификации прочитать references/compliance.md.
- Для формального отчёта или JSON findings прочитать references/reporting.md.
- Перед ссылкой на стандарт, advisory или CVE прочитать references/sources.md и проверить актуальность.
Не загружать все references автоматически: читать только относящиеся к текущему объекту и режиму.
Рабочий процесс
1. Зафиксировать scope
Установить:
- объект и разрешённые каталоги, сервисы, URL и окружения;
- тип результата: краткий review, полный аудит, threat model, план тестов или повторная проверка;
- архитектуру, роли пользователей, активы, чувствительные данные и trust boundaries;
- поверхности входа: UI, API, jobs, queues, webhooks, файлы, админка, AI/MCP;
- явно исключённые области и недоступные доказательства;
- допустимость локальных команд, сети и записи файлов.
Для большого репозитория можно запустить python3 scripts/inventory.py <корень> из каталога этого скилла (пути к scripts/ и references/ в тексте — относительно него). Скрипт читает только метаданные дерева, не следует по symlink и не анализирует содержимое файлов. Каталоги сборки и зависимостей он пропускает и перечисляет в skipped_directories: если в аудит входят закоммиченные артефакты сборки или source maps, смотреть их отдельно.
2. Построить минимальный threat model
Для каждой существенной границы связать:
актив → субъект/злоумышленник → точка входа → проверяемый контроль → возможное воздействие.
Приоритизировать внешние и межтенантные границы, привилегированные действия, денежные или необратимые операции, секреты, персональные данные, цепочку поставок и автономные инструменты.
3. Проверить реализованные контролы
Сначала проследить реальные потоки данных и полномочий, затем сопоставлять их с контрольными семействами. OWASP Top 10 — карта рисков, а не доказательство полноты. Для веб-приложений использовать ASVS как проверочную основу; применять только релевантные требования и указывать их версию.
Предпочитать уже настроенные в проекте линтеры, тесты, SAST/SCA и lockfile-проверки. Не устанавливать инструменты автоматически. Не скрывать stderr и exit code; при пропуске проверки фиксировать причину.
4. Проверить каждую находку
Перед включением в findings:
- Указать точное место и затронутый актив.
- Проследить источник, преобразования, sink или отсутствующий enforcement point.
- Описать предусловия и достижимость.
- Найти и оценить контрдоказательства.
- Безопасно воспроизвести только в разрешённой среде или объяснить, почему не воспроизводилось.
- Отделить фактическое воздействие от теоретического сценария.
- Назначить статус, severity и confidence независимо друг от друга.
Статусы доказанности:
Verified — путь и воздействие подтверждены кодом, конфигурацией или разрешённым тестом.Likely — путь убедителен, но часть runtime-доказательств недоступна.Hypothesis — сигнал требует дополнительной проверки; не считать подтверждённой уязвимостью.Not tested — область входит в scope, но доказательств недостаточно; отражать в coverage, а не как finding.
5. Оценить риск
Не использовать составной балл аудита. Severity отвечает на вопрос о локальном воздействии конкретной находки:
Critical — реалистичный путь к катастрофическому воздействию: массовой утечке особо чувствительных данных, обходу ключевой границы доверия, выполнению кода или необратимому контролю над критической системой с малыми предусловиями.High — существенное воздействие и практически достижимый путь атаки.Medium — ограниченное воздействие либо значимые предусловия, уменьшающие вероятность.Low — небольшой риск или полезное усиление защиты с конкретным сценарием.Informational — наблюдение без доказанного security impact.
Учитывать exposure, reachability, требуемые привилегии, сложность, масштаб данных, обратимость, обнаруживаемость и компенсирующие меры. Для CVE дополнительно проверять реальную версию и достижимость уязвимого кода. CVSS, EPSS и KEV — входные данные, но не замена локальной оценке.
Не считать уязвимостью автоматически:
- последовательные ID при корректной object-level authorization;
- включённую GraphQL introspection;
- наличие source maps без утечки закрытых данных;
- отсутствие конкретной guardrail-библиотеки, MCP gateway, RLS или SBOM;
- использование не самой новой модели;
- отсутствие произвольного фиксированного срока ротации ключей;
- unpinned manifest при наличии воспроизводимого lockfile.
6. Сформировать результат
По умолчанию ответить в чате на языке пользователя; для русскоязычного запроса — по-русски, сохраняя англоязычные термины и идентификаторы стандартов. Создавать или изменять файлы отчёта только по запросу пользователя.
Прогон самодостаточен. Не предполагать наличие предыдущих отчётов, не выстраивать тренды и не сравнивать количество находок между запусками. Если пользователь передал прежний отчёт, использовать его как список гипотез для перепроверки, а не как установленный факт: статус каждой находки подтверждать заново по текущему коду.
Минимальный результат:
- краткий вывод;
- scope, режим и ограничения;
- findings по убыванию риска;
- coverage matrix с
Reviewed / Partial / Not tested / Not applicable;
- подтверждённые сильные контролы;
- приоритетный план исправлений и способ повторной проверки.
Для каждой находки использовать поля из references/reporting.md. Не заявлять production-ready, compliant или без уязвимостей, если scope и доказательства этого не подтверждают.
Обращение с секретами
- Не печатать совпавшее значение даже частично, если по фрагменту можно восстановить или использовать секрет.
- Для fingerprint использовать необратимый хеш от значения и показывать не более короткого идентификатора, например первые 8 символов SHA-256.
- Не отправлять секреты во внешние сервисы и не помещать их в prompt, issue, отчёт или тестовый fixture.
- При обнаружении действующего секрета сообщить о типе и местоположении, рекомендовать отзыв/ротацию и очистку истории; не выполнять это без запроса.
- Полную историю Git сканировать только при явной необходимости. Результаты сканера должны быть редактированы до показа.
Остановка
Остановить активную проверку при выходе за scope, неожиданной деградации, доступе к реальным чужим данным, появлении секрета в выводе, неясности полномочий или достижении согласованного stop condition. Сохранить безопасные доказательства и сообщить, что произошло, не продолжая эскалацию.
