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

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

Меньше 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 или попросил «проаудить репо».

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

URL обязателен: подтянуть репозиторий из сессии больше нечем. Клон упал на аутентификации: репозиторий закрыт, попроси публичный URL.

После клонирования сними и зафиксируй git rev-parse --short HEAD, git rev-parse --abbrev-ref HEAD, git ls-files | wc -l: они пойдут в отчёт.

Шаг 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: до 5 подзадач за вызов, одновременно идут столько, сколько называет схема run_subagent, остальные ждут очереди.

Дозированно: до 3 категорий за один run_subagent. "wait": true передавай явно: без него вызов уходит в фон, а findings нужны в этом же ходе для шага 5. После завершения собери findings[] из отчёта каждого ребёнка.

Шаг 5. Verification loop

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

"wait": true и здесь: вердикты нужны шагу 6 в этом же ходе. Роль verify сюда не подходит: она закрывается вызовом verdict по критериям, а не отчётом с confidence.

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

Шаг 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..."}] }