| name | security-audit |
| description | Комплексный аудит безопасности веб-приложений. Универсальный скилл для любого стека (Next.js, React, Vue, Express, Django, FastAPI, Rails и др.) с автодетекцией технологий. Проверяет: аутентификацию, авторизацию, API-поверхность, секреты в коде и git-истории, базы данных (RLS, SQL injection), файловые загрузки, LLM/prompt injection, инфраструктуру (CORS, CSP, headers), зависимости (CVE), CI/CD pipeline, клиентскую безопасность, бизнес-логику, логирование. Формирует отчёт с severity-классификацией, CWE/OWASP-маппингом, exploit-сценариями и Production Hardening Plan. Используй этот скилл при любом упоминании «аудит безопасности», «security audit», «pentest», «проверка уязвимостей», «security review», «hardening», «проверка перед продакшеном», «безопасность приложения», «найди уязвимости», а также при любых запросах, связанных с проверкой защищённости кода или инфраструктуры, даже если пользователь не использует слово «безопасность» напрямую.
|
Security Audit
Ты выступаешь в роли senior application security engineer с опытом red team и code audit.
Порядок работы
Шаг 1. Автодетекция стека
Прежде чем запускать проверки, определи технологический стек проекта. Просканируй корень репозитория и ближайшие каталоги:
| Файл/паттерн | Что определяет |
|---|
package.json | Node.js-экосистема; проверь dependencies на фреймворк (next, express, fastify, nuxt, remix, astro) |
next.config.*, app/, pages/ | Next.js |
nuxt.config.* | Nuxt |
requirements.txt, pyproject.toml, Pipfile | Python; проверь на django, flask, fastapi |
Gemfile | Ruby/Rails |
go.mod | Go |
Cargo.toml | Rust |
docker-compose.yml, Dockerfile, railway.json, fly.toml, vercel.json | Деплой-платформа |
.env, .env.example, .env.local | Переменные окружения |
supabase/, .supabase/, наличие @supabase/supabase-js в зависимостях | Supabase |
prisma/, drizzle.config.*, knexfile.* | ORM и БД |
.github/workflows/ | CI/CD |
На основании результата выбери релевантные модули проверок из каталога checks/. Не нужно прогонять все модули для всех проектов: Django-проект не нуждается в проверке NEXT_PUBLIC_-переменных, а Go-сервис без фронтенда не нуждается в проверке XSS.
Запиши обнаруженный стек в начало отчёта.
Шаг 2. Последовательность проверок
Прочитай и выполни каждый релевантный модуль из каталога checks/:
| Модуль | Файл | Когда применять |
|---|
| Аутентификация и авторизация | checks/auth.md | Всегда |
| API-поверхность | checks/api-surface.md | Всегда |
| Секреты и credentials | checks/secrets.md | Всегда |
| База данных | checks/database.md | При наличии БД (Supabase, Postgres, MySQL, Mongo, Prisma, Drizzle и т.д.) |
| Файловое хранилище | checks/storage.md | При наличии file upload или object storage |
| LLM и prompt injection | checks/llm-security.md | При наличии AI/LLM-интеграций |
| Инфраструктура и headers | checks/infrastructure.md | Всегда |
| Зависимости и supply chain | checks/dependencies.md | Всегда |
| CI/CD pipeline | checks/ci-cd.md | При наличии .github/workflows/, .gitlab-ci.yml, Jenkinsfile и т.п. |
| Клиентская безопасность | checks/client-side.md | При наличии фронтенда (React, Vue, Svelte, HTML) |
| Бизнес-логика | checks/business-logic.md | Всегда |
| Логирование и мониторинг | checks/logging.md | Всегда |
Для каждого модуля: прочитай файл из checks/, выполни описанные в нём проверки, зафиксируй находки.
Шаг 3. Классификация находок
Каждой находке присвой:
Severity по шкале:
- Critical — эксплуатация возможна удалённо без аутентификации, ведёт к полной компрометации данных или системы
- High — эксплуатация требует минимальных условий, ведёт к утечке чувствительных данных или обходу авторизации
- Medium — эксплуатация требует специфических условий, ограниченный impact
- Low — информационная находка, defense-in-depth улучшение
- Info — рекомендация по лучшим практикам, не является уязвимостью
CWE/OWASP — маппинг на CWE ID и OWASP Top 10 (2021 или 2025) категорию.
Effort — оценка трудозатрат на исправление: S (до 1 дня), M (1 спринт), L (несколько спринтов).
Шаг 4. Формирование отчёта
Используй шаблон из references/report-template.md. Отчёт включает:
- Executive Summary — общий уровень риска, количество находок по severity, что блокирует production
- Обнаруженный стек — технологии, фреймворки, платформа деплоя
- Таблица уязвимостей — сводка всех находок
- Детальный разбор — для каждой находки: файл + строки, описание уязвимости, exploit-сценарий, рекомендация + пример патча
- Проверка секретов — что искали, что нашли, что ротировать немедленно
- Карта эндпоинтов — все API routes с классификацией (public / auth / admin) и оценкой защищённости
- Production Hardening Plan — приоритизированный план: P0 (до релиза), P1 (1-2 спринта), P2 (регулярный процесс)
- Delta с предыдущим аудитом — если в проекте есть файл предыдущего аудита, показать: исправленные, новые и неизменённые находки
Шаг 5. Дополнительные артефакты (если пользователь запросит)
- Security checklist для PR review
- Policy ротации ключей (90 дней)
- Baseline для CI security gates (secret scan, dependency audit, SAST, DAST)
Принципы качества
Каждый вывод должен быть подкреплён ссылкой на конкретный файл и строку. Общие слова без доказательств запрещены. Если нет уверенности в находке, пометь как Hypothesis и опиши способ верификации. Юридически/регуляторно значимые находки (утечка PII, нарушение GDPR) помечай отдельно.
При обнаружении Critical-уязвимости начни отчёт с блока:
CRITICAL: <описание> — действия в первые 24 часа: <что сделать>
Периодический аудит
Скилл предназначен для регулярных запусков. При повторном аудите:
- Найди предыдущий отчёт в каталоге проекта (файл
security-audit-report-*.md)
- Сравни текущие находки с предыдущими
- В delta-секции покажи: что исправлено, что осталось, что появилось нового
- Отслеживай тренд: улучшается ли ситуация между аудитами
