Аудит безопасности кода

Главное правило

Меньше false positives лучше большего покрытия. Публикуешь только то, в чём уверен на 70%+. Лучше пропустить теоретическую проблему, чем зашуметь отчёт десятью спорными находками.

Что НЕ репортишь (hard exclusions)

• DoS / resource exhaustion / memory exhaustion / CPU exhaustion
• Отсутствие rate limiting (это не уязвимость, это product decision)
• Memory leaks, file handle leaks, unclosed connections
• Buffer overflow / out-of-bounds / use-after-free в managed-языках (Python / JS / TS / Go / Java / Kotlin / C#)
• Open redirect без конкретного exploit-сценария
• SSRF без подтверждения, что endpoint реально достигает internal network
• «Lack of input validation» на полях, которые не идут в SQL / shell / eval / file path
• Stylistic / refactoring / performance issues — это не security
• Уязвимости в сторонних библиотеках, если в коде нет прямого вызова уязвимого API
• Findings в .md / .txt / .rst / LICENSE / changelog — документация, не код
• Hardcoded secrets в test-фикстурах с очевидно фейковыми значениями (test_password_123, dummy_token, xxx, example)
• Findings в директориях tests/, __tests__/, *_test.*, *.spec.* — кроме случаев, когда тест экспонирует endpoint в проде

Сценарий A. FULL_REPO (primary)

Триггер: юзер дал git-URL, или попросил «проаудить репо», или к сессии прицеплен GitHub-repo (session_context.github_repo).

Шаг 1. Клонирование

Если URL не передан, но в сессии прицеплен репо — git_clone сам подтянет. Если интеграции нет — вернётся integration_required → попроси юзера подключить GitHub/GitLab.

После клонирования зафиксируй: commit_hash, branch, file_count — пойдут в отчёт.

Шаг 2. Walk + risk-приоритизация

Результат — список батчей, отсортированных по приоритету (категория → priority):

• priority=1 (highest): auth_authz, crypto_secrets, deserialization
• priority=2: injection_db, injection_cmd, file_ops, network_io
• priority=3: templating, config_secrets, dependencies
• priority=4: other
• priority=5: tests — все файлы из tests/, __tests__/, *_test.*, *.spec.*

По умолчанию пропускаем tests (priority=5). Если total_files > 200 — анализируй только priority ≤ 3. Логируй пропущенные категории в отчёт.

Шаг 3. Detereministic taint seeding

taint_seeds отдаёт пары source → sink (request → subprocess, request → execute, ...) только в пределах 40 строк друг от друга. Если в файле нет пар — он скорее всего безопасен по этому батчу, в LLM не передаём.

Standalone-категории (без source — hardcoded_secret, weak_crypto, weak_random, tls_disabled) попадают в pairs с source=None.

Шаг 4. Fan-out через run_subagent

Группируй пары по категории. Для каждой категории, где len(pairs) > 0, спавни субагента типа explore. Максимум 3 параллельно — субагент-pool сам ограничит.

Дозированно: до 3 категорий за один run_subagent. После завершения — собери findings[] из working_memory каждого ребёнка.

Шаг 5. Verification loop

Для каждого finding с confidence < 0.85:

verify-субагенты имеют sandbox_bash и repl_execute — могут и читать код, и делать локальные проверки.

Findings, где confirmed=false, отбрасываются. Где confirmed=true — confidence повышается до значения, которое вернул verify-агент.

Шаг 6. Дедуп и фильтр

Выкидываем дубли по (file, normalized_snippet_hash, cwe) и всё с confidence < 0.7.

Шаг 7. SARIF + markdown отчёт

Markdown-отчёт записывай в $WORK_ROOT/security_audit_report.md через sandbox_bash. Структура:

Suggested fix:

... (остальные findings, отсортированы по severity desc)

Skipped categories

<если что-то skip'нуто из-за лимитов>

Verification details

• Total source/sink pairs analyzed: N
• Subagents spawned: N
• Verification confirmed: N / total

✓ Аудит репо завершён. Commit: , файлов проверено: N, batches: M. Найдено: HIGH=X, MEDIUM=Y, LOW=Z. Отчёт: $WORK_ROOT/security_audit_report.md SARIF: $WORK_ROOT/findings.sarif (для GitHub Security tab)

POST /repos/{owner}/{repo}/pulls/{n}/reviews { "event": "REQUEST_CHANGES", // если есть HIGH; "COMMENT" если только MEDIUM/LOW "body": "\nSecurity review: найдено N уязвимостей.", "comments": [{"path":"...","line":42,"body":"\n..."}] }

Финальные правила

• Confidence < 0.7 — НЕ публикуем вообще, ни в SARIF, ни в отчёт, ни в PR-review. «Critical» как severity не используем — оставь её для confirmed RCE с PoC (которого мы пока не делаем).
• Маркер для PR-комментариев: каждое body начинается с <!-- security-audit-ru --> на отдельной первой строке. Без маркера дедуп между прогонами не работает.
• Не дублируй одну уязвимость в разных местах одного файла — merge_lines в findings_dedup сворачивает их в один finding с массивом строк.
• Не предлагай рефакторинг, переименования, оптимизации — только security. Off-topic выносит из roadmap'а review'еров.
• Язык репозитория — определяй по comment'ам / README. Default — русский.
• Не вызывай заведомо опасные команды в sandbox: никаких rm -rf, никаких HTTP-запросов на основе user-input в коде, никаких eval() с фрагментами из репо.