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

tool_call: git_clone {"repo_url": "<URL>", "branch": ""}

repl_execute:
Импорты — из единого фасада `audit`: он реэкспортит `repo_walker`, `taint_seeds`, `findings_dedup`, `sarif_emitter`,
поэтому `from audit import <примитив>` резолвится всегда — под-модуль угадывать не нужно.

    from audit import walk, stats
    batches = walk(os.environ["REPO_ROOT"], max_files_per_batch=8)
    print(stats(batches))

repl_execute:
    from audit import seed, summarize
    pairs_by_batch = []
    priority_cap = 3 if sum(b["priority"] <= 3 for b in batches) > 0 and stats(batches)["total_files"] > 200 else 4
    for b in batches:
        if b["priority"] > priority_cap:
            continue
        files = [f["abs_path"] for f in b["files"]]
        pairs = seed(files, proximity=40)
        if pairs:
            pairs_by_batch.append({"category": b["category"], "pairs": pairs})
    print({"batches_with_pairs": len(pairs_by_batch),
           "total_pairs": sum(len(b["pairs"]) for b in pairs_by_batch)})

run_subagent {
  "tasks": [
    {
      "label": "auth_authz",
      "agent_type": "explore",
      "task": "Проанализируй пары source→sink в категории auth_authz из репо в $REPO_ROOT. Для каждого файла читай контекст через `sandbox_bash` (`sed -n '<line-10>,<line+10>p' $REPO_ROOT/<file>`). Верни JSON-массив findings с каноническими ключами: file (rel path), line (int), lines (int[]), cwe, severity (HIGH/MEDIUM/LOW), confidence (0.0-1.0), title, body, snippet, category. Чек-лист: source реально доходит до sink, нет ли sanitizer'а, reachable ли путь из публичного endpoint'а, проверяется ли authz. Если хоть один пункт даёт «проблем нет» — finding отбрасываешь. Confidence < 0.7 — не возвращаешь.",
      "context": "<JSON с парами для этой категории>"
    },
    ...
  ]
}

run_subagent {
  "tasks": [{
    "label": "verify_<finding_id>",
    "agent_type": "verify",
    "task": "Подтверди эту уязвимость по коду: <finding>. Прочитай файл $REPO_ROOT/<file> через sandbox_bash, проследи путь от source до sink, проверь sanitizer'ы и authz. Верни {confirmed: bool, reason: str, confidence: float}. Если не достижим из untrusted источника — confirmed=false."
  }]
}

repl_execute:
    from audit import dedup, filter_by_confidence, merge_lines, stats
    deduped = dedup(all_findings)
    merged = merge_lines(deduped)
    published, dropped = filter_by_confidence(merged, threshold=0.7)
    print(stats(published))

repl_execute:
    from audit import emit
    sarif_path = emit(published, os.environ["WORK_ROOT"] + "/findings.sarif")

# Security Audit — <repo>

**Commit:** `<hash>` · **Branch:** `<branch>` · **Files scanned:** N · **Date:** YYYY-MM-DD

## Summary
- HIGH: X
- MEDIUM: Y
- LOW: Z

## Findings

### [HIGH] CWE-XXX <название> — `path/to/file.py:42`
Confidence: 0.85

<описание уязвимости>

```python
<snippet>

<fix>

### Шаг 8. Финальный ответ юзеру

Короткий summary в чат:

Если HIGH=0 и MEDIUM≤2 — добавь «✓ Серьёзных уязвимостей не выявлено».
Если HIGH≥1 — добавь «⚠ Найдены HIGH-уязвимости — рекомендуется не мержить ветку до фиксов.»

## Сценарий B. PR_REVIEW (secondary)

Триггер: юзер дал URL вида `github.com/.../pull/N` или `gitlab.com/.../merge_requests/N`. Тогда работаешь по diff'у MR/PR, а не по всему репо.

### Шаг 1. Достать diff

- **GitLab**: `GET /projects/{id}/merge_requests/{iid}/changes` → `changes[]` + `diff_refs` (`base_sha`/`head_sha`/`start_sha` — нужны для inline через `/discussions`).
- **GitHub**: `GET /repos/{owner}/{repo}/pulls/{n}/files`.

### Шаг 2. Анализ diff'а

Анализируешь **только added/modified lines**, не весь файл. Тот же чек-лист: source → sanitizer → reachability → authz → impact. Если любой шаг даёт «проблем нет» — отбрасываешь.

### Шаг 3. Дедуп против предыдущих ревью

Перед публикацией:
- **GitLab**: `GET /merge_requests/{iid}/notes` + `GET /merge_requests/{iid}/discussions` → фильтр по маркеру `<!-- security-audit-ru -->` в начале body. Сравнение по ключу `(file, line, CWE)`.
- **GitHub**: `GET /pulls/{n}/reviews` → тот же фильтр.

Если такой finding уже есть — не дублируем.

### Шаг 4. Публикация

**GitHub** — ОДИН review атомарно:

**GitLab** — отдельный POST на каждый комментарий + один `/notes` с summary:

### Шаг 5. Финальное действие

- Все findings MEDIUM или ниже → review с `event: "COMMENT"` (GitHub) / discussions без блокировки (GitLab).
- Хотя бы один HIGH → `event: "REQUEST_CHANGES"` (GitHub) / discussions без approve (GitLab). НЕ апрувим MR с подтверждённым HIGH.
- Diff чистый → positive note: «Security review: уязвимостей не найдено в этом diff'е. Reviewed N файлов.»

## Категории и severity

**HIGH:**
- SQL / NoSQL injection через unsanitized input (CWE-89)
- Command / shell injection в `subprocess`, `os.system`, `eval`, backticks (CWE-78)
- Insecure deserialization (`pickle.loads` на user-input, `yaml.load` без `SafeLoader`, `marshal`) (CWE-502)
- Auth bypass, IDOR, privilege escalation через подмену ID (CWE-285, CWE-639)
- Hardcoded production secrets (CWE-798)
- Weak crypto в auth/secrets-context: MD5/SHA1 для паролей, ECB-mode, fixed IV, predictable random для tokens (CWE-327, CWE-330)
- Path traversal в file ops без проверки `safe_join` (CWE-22)
- XXE в XML-парсерах с включёнными external entities (CWE-611)
- Server-side template injection (Jinja2/Mako/Twig с user-input в `render_string`) (CWE-94)
- RCE через `eval` / `exec` / `Function()` на user-input (CWE-95)

**MEDIUM:**
- Stored / reflected / DOM XSS в web-контексте без output encoding (CWE-79)
- CSRF на state-changing endpoint без token check (если фреймворк не делает автоматом) (CWE-352)
- Weak random (`Math.random`, `random.random()`) для security tokens / session IDs (CWE-330)
- Information disclosure: stack traces / debug info в production response (CWE-209)
- Missing TLS verification (`verify=False`, `rejectUnauthorized: false`) при походе во внешний API (CWE-295)
- Improper certificate validation (CWE-295)

**LOW:**
- Defense-in-depth issues
- Minor information leakage (server version в headers)
- Non-critical configurations (cookie flags на не-auth-куках)

## Чек-лист анализа (применяется к каждому потенциальному finding'у)

1. **Источник**: пользовательский ввод реально достигает sink? Что между ними? Если ввод приходит из доверенного источника (internal service, signed JWT с проверкой) — это не sink.
2. **Санитизация**: нет ли уже existing sanitizer'а (parametrized query, ORM с автоэкранированием, validator на схеме, output encoder)?
3. **Reachability**: путь выполнения достижим из публичного endpoint'а или только internal/admin/cron?
4. **Authorization**: проверяется ли право до того, как ввод используется?
5. **Impact**: что атакующий реально получит (RCE / data exfil / privilege escalation / token leak)?

Если **любой** из шагов 1–4 даёт «проблем нет» — это false positive, отбрасываешь без публикации.

## Формат каждого finding'а

```python
{
  "file": "src/auth.py",
  "line": 42,
  "lines": [42, 67],            # все затронутые
  "cwe": "CWE-89",
  "severity": "HIGH",            # HIGH / MEDIUM / LOW
  "confidence": 0.85,            # 0.0–1.0
  "title": "SQL injection через unsanitized email",
  "body": "Поле request.json['email'] напрямую конкатенируется в SQL-запрос без параметризации.",
  "snippet": "cursor.execute(f\"SELECT * FROM users WHERE email = '{email}'\")",
  "proposed_patch": "cursor.execute(\"SELECT * FROM users WHERE email = %s\", (email,))",
  "category": "sql_injection"
}