web-api/security-analysis/README.md

security-analysis

Результаты автоматической security-проверки этого репозитория: Level 0 (детерминированные сканеры) и Level 1 (AI PR review) из требований AI Security Engine. Заводится и сопровождается пайплайном seed-security-scanning (platform-infra) — правки этого README переживут только до следующего его запуска.

Что здесь лежит

• policy.yml — какие severity блокируют merge и какой минимальный confidence нужен, чтобы находка вообще считалась. Общий для обоих уровней.

• findings/pr-<номер>/<unix-время>[-review].json — находки конкретного скана: массив объектов вида

  {
    "id": "...", "source": "semgrep|gitleaks|ai-review",
    "category": "sast|secret|auth|idor|injection|...",
    "severity": "critical|high|medium|low", "confidence": 0.0,
    "file": "...", "line_start": 0, "line_end": 0,
    "title": "...", "description": "...", "rule_id": "...",
    "cwe": "CWE-...", "status": "OPEN",
    "created_at": "...", "pr_number": 0, "commit_sha": "..."
  }
  

  У находок Level 1 (source: ai-review) дополнительно есть impact, exploit_scenario, evidence, recommendation.

Уровни

• Level 0 (security/scan) — semgrep + gitleaks, без LLM. Быстро и воспроизводимо, ловит известные классы проблем. Запускается на каждый PR.
• Level 1 (security/review) — headless-агент (security-reviewer, read-only: без bash/edit/webfetch) читает диф PR через шлюз (модель coder-fast) и ищет то, что детерминированные сканеры не видят: логические дыры авторизации, IDOR, SSRF и т.п. Не идёт по всему репозиторию — только диф и то, что нужно дочитать по grep/glob. Тоже на каждый PR.
• Level 2 (Deep Security Audit) — по запросу (workflow_dispatch на security.yml, вход domains — какие домены проверять, пусто = все). Шесть доменных read-only агентов (audit-auth, audit-authz, audit-injection, audit-ssrf, audit-secrets, audit-business-logic) идут по ВСЕМУ репозиторию последовательно (не параллельно — проще отлаживать, дороже по времени), модель coder-think (рассуждение, не экономичная coder-fast). Каждая находка проходит через независимого верификатора (audit-verifier), который пытается её ОПРОВЕРГНУТЬ, а не подтвердить — не подтверждённые отбрасываются молча. Результат — issue в этом же репозитории (заголовок с датой и сводкой по severity, тело — сводный отчёт, полные данные находок — вложением JSON), заводится через git-mcp от имени отдельного platform-lk-агента (не <репозиторий>-security-bot и не PR), не блокирует merge (это аудит, не гейт).

Кто это делает

Комментарии и статусы всех уровней — от имени <репозиторий>-security-bot, отдельной учётки с правом записи только на этот репозиторий. Не токен разработчика и не администратора: у бота нет прав ни на что, кроме комментирования PR и записи находок сюда же. У Level 1 и Level 2 — свои, отдельные ключи шлюза (SECURITY_REVIEWER_LITELLM_KEY только на coder-fast, DEEP_AUDIT_LITELLM_KEY только на coder-think), каждый со своим бюджетом.