Security Audit

Security Audit

Версия методики: 3.1. Срез сверки источников — 2026-08-22, перечень в 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, законодательство, облачные настройки — проверять по первичному источнику на дату аудита. Если это невозможно, сообщать, что проверка не выполнена.

Режимы

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

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

• Для полного аудита или выбора доменов прочитать 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:

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. Не заявлять production-ready, compliant или без уязвимостей, если scope и доказательства этого не подтверждают.

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

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

Остановка

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