# Security Audit

> Комплексный аудит безопасности приложений, API, репозиториев, AI/agent-систем, MCP-интеграций, инфраструктуры и цепочки поставок. Использовать при явном запросе — «аудит безопасности», «security audit», «проверь на уязвимости», «security review», «threat model», «hardening», «проверка перед продакшеном», «prompt injection», «MCP security», — а также при secure-design review или планировании авторизованного пентеста. Не использовать для обычного code review, отладки или рефакторинга без запроса о безопасности.

- Skill: `kirilltrubitsyn/security-audit` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add kirilltrubitsyn/security-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kirilltrubitsyn/security-audit/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: KirillTrubitsyn (https://skillmd.com/u/kirilltrubitsyn)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/kirilltrubitsyn/security-audit

---


# Security Audit

Версия методики: 3.1. Срез сверки источников — 2026-08-22, перечень в [references/sources.md](references/sources.md).

Срез — дата последней проверки версий стандартов, а не гарантия их актуальности. Чем дальше текущая дата от среза, тем обязательнее перепроверка по правилу 8: версии ASVS, OWASP, MCP и статус CVE меняются между аудитами.

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

## Непереговорные правила

1. Не расширять объект, окружение или способ проверки сверх запроса пользователя.
2. Если режим не указан, выбирать `audit`.
3. Не считать разрешение на аудит разрешением на эксплуатацию уязвимостей, сетевое сканирование, нагрузочное тестирование, изменение файлов, установку зависимостей или исправление кода.
4. До действий определить фактический корень проекта, прочитать применимые инструкции репозитория и проверить текущее состояние рабочей копии. Не очищать и не перезаписывать чужие изменения.
5. Не раскрывать секреты. В отчёте указывать тип, расположение и редактированный отпечаток, но не значение ключа, токена, cookie, пароля или приватного материала.
6. Не объявлять уязвимость без доказанного пути к воздействию либо явно маркировать её как гипотезу.
7. Проверять контрдоказательства: защитный middleware, deny-by-default, ограничения базы, тесты, инфраструктурные политики, недостижимость и компенсирующие меры. Сюда же относятся задокументированные в репозитории осознанные решения — принятый риск, компенсирующая мера, намеренное поведение вроде fail-open. Такое решение не закрывает находку само по себе, но обязано быть названо и оценено: если вывод аудита с ним расходится, объяснить, чем обоснование не покрывает найденный путь.
8. Все меняющиеся сведения — версии стандартов, CVE, affected/fixed ranges, KEV, законодательство, облачные настройки — проверять по первичному источнику на дату аудита. Если это невозможно, сообщать, что проверка не выполнена.

## Режимы

| Режим | Назначение | Допустимые действия |
|---|---|---|
| `audit` | Режим по умолчанию | Чтение кода, конфигурации, документации и уже имеющихся результатов; безопасные локальные команды без изменения состояния |
| `plan` | Проектирование проверки | Threat model, перечень доказательств, тест-план и правила проведения без запуска тестов |
| `verify` | Проверка гипотез | Локальные тесты, существующие анализаторы и изолированные fixtures без обращения к production |
| `active-test` | Активная проверка работающей системы | Только после явного подтверждения полномочий и правил из [references/active-testing.md](references/active-testing.md) |
| `remediate` | Исправление | Только по явному запросу; минимальные изменения с проверкой регрессий |

Если запрос смешивает режимы, сначала выполнить безопасную часть и отдельно обозначить, какая авторизация нужна для остального.

## Маршрутизация материалов

- Для полного аудита или выбора доменов прочитать [references/controls.md](references/controls.md).
- При наличии LLM, RAG, agents, tools, memory или MCP прочитать [references/ai-mcp.md](references/ai-mcp.md).
- Если в репозитории есть агентные артефакты — каталог `.claude/`, скиллы, команды, hooks, конфигурации MCP-клиентов, промпты и автоматизации, порождающие коммиты, — проверить их как отдельную поверхность по разделу 15 [references/controls.md](references/controls.md).
- Перед любым активным воздействием прочитать [references/active-testing.md](references/active-testing.md).
- При запросе о законах, стандартах соответствия или сертификации прочитать [references/compliance.md](references/compliance.md).
- Для формального отчёта или JSON findings прочитать [references/reporting.md](references/reporting.md).
- Перед ссылкой на стандарт, advisory или CVE прочитать [references/sources.md](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:

1. Указать точное место и затронутый актив.
2. Проследить источник, преобразования, sink или отсутствующий enforcement point.
3. Описать предусловия и достижимость.
4. Найти и оценить контрдоказательства.
5. Безопасно воспроизвести только в разрешённой среде или объяснить, почему не воспроизводилось.
6. Отделить фактическое воздействие от теоретического сценария.
7. Назначить статус, 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. Сформировать результат

По умолчанию ответить в чате на языке пользователя; для русскоязычного запроса — по-русски, сохраняя англоязычные термины и идентификаторы стандартов. Создавать или изменять файлы отчёта только по запросу пользователя.

Прогон самодостаточен. Не предполагать наличие предыдущих отчётов, не выстраивать тренды и не сравнивать количество находок между запусками. Если пользователь передал прежний отчёт, использовать его как список гипотез для перепроверки, а не как установленный факт: статус каждой находки подтверждать заново по текущему коду.

Минимальный результат:

1. краткий вывод;
2. scope, режим и ограничения;
3. findings по убыванию риска;
4. coverage matrix с `Reviewed / Partial / Not tested / Not applicable`;
5. подтверждённые сильные контролы;
6. приоритетный план исправлений и способ повторной проверки.

Для каждой находки использовать поля из [references/reporting.md](references/reporting.md). Не заявлять `production-ready`, `compliant` или `без уязвимостей`, если scope и доказательства этого не подтверждают.

## Обращение с секретами

- Не печатать совпавшее значение даже частично, если по фрагменту можно восстановить или использовать секрет.
- Для fingerprint использовать необратимый хеш от значения и показывать не более короткого идентификатора, например первые 8 символов SHA-256.
- Не отправлять секреты во внешние сервисы и не помещать их в prompt, issue, отчёт или тестовый fixture.
- При обнаружении действующего секрета сообщить о типе и местоположении, рекомендовать отзыв/ротацию и очистку истории; не выполнять это без запроса.
- Полную историю Git сканировать только при явной необходимости. Результаты сканера должны быть редактированы до показа.

## Остановка

Остановить активную проверку при выходе за scope, неожиданной деградации, доступе к реальным чужим данным, появлении секрета в выводе, неясности полномочий или достижении согласованного stop condition. Сохранить безопасные доказательства и сообщить, что произошло, не продолжая эскалацию.