# S2 掃描結果：jedi-iam 授權守門與提權路徑

> **掃描日期**：2026-09-05
> **掃描版本**：jedi-python-package `feature/FR-075` @ `67cb075`
> **工具**：Claude Code `claude-security` plugin v0.10.2.3（`claude-security:scan` workflow）
> **狀態**：✅ **已完整跑完並經驗證面板流程**（`verification.status: verified`）
> **對應卡片**：CM-1548（母卡 CM-1546）

## 掃了什麼

- 範圍：`jedi-iam/jedi_iam/authz/`（platform-admin / super-admin / capability 三軸判定與 decorator）+
  `jedi-iam/jedi_iam/infra/elevated_session.py`（提權情境）
- 檔數：8（tracked files 實測，與卡片指定一致）
- effort：`low`（single-researcher shape，非 medium 的元件矩陣）
- focus：`attack-surface`
- 研究員：派 2、回報 2（0 error、0 skipped）
- 面板：候選數 0 → 面板無票可投（`panel_votes: 0`），這是「沒有候選」而非「面板沒跑」

## 結果

**0 條發現。**

兩位研究員各自完整讀過整個範圍（8 個檔全讀，不是抽樣），都沒有回報任何候選問題。因為沒有候選，
本輪不需要驗證面板投票，但 render_report.py 的 stamp 仍標記 `verification.status: verified`
（代表流程本身正常跑完、沒有中途失敗或降級）。

原始 workflow 回傳、`journal.jsonl`、`scan-meta.json` 等中繼檔已在 `render_report.py` 產出正式報告後
依 workflow 設計自動清除（只留 `CLAUDE-SECURITY-RESULTS.md/.jsonl/.sarif` + revision stamp），
正式報告落在 repo 根目錄 `CLAUDE-SECURITY-20260905-062253/`（該資料夾自帶 `.gitignore` 排除進版控，
本檔案是摘要副本）。

## 對照第一輪不完整掃描（母卡 CM-1546 提到的 M-3）

第一輪（40 agent、28 回報、面板未跑）在這塊範圍找到過一條：

> M-3 signed-token 最小情境以 super admin 執行（根因在 jedi-common 的 session_scope，觸發點在這裡）

**本輪兩位研究員都沒有重新發現這條**。核對兩種可能：

1. **面板刪掉了**——不成立，因為本輪候選數本來就是 0（`candidates: 0`），從未進到面板階段，
   不是「候選被否決」而是「候選一開始就沒被提出」。
2. **根本沒掃到**——需要進一步核對。M-3 的根因描述是「jedi-common 的 session_scope」，
   如果 M-3 真正的觸發點程式碼（signed-token 建立 session 的呼叫點）不在
   `jedi-iam/jedi_iam/authz/` 或 `elevated_session.py` 這 8 個檔案內，而是在 jedi-common 側
   或 jedi-iam 的其他檔案（例如 signed-token 的產生/驗證邏輯本身），那麼**這次的 8 檔範圍本來就不包含它**，
   兩位研究員自然看不到。

   實地檢查：`elevated_session.py` 是本次範圍內唯一處理「提權情境」的檔案，我直接讀過其內容，
   其中確實有 `elevated_session` context manager 會建立一個帶特定權限的 session，但這個檔案本身
   **不直接處理 signed-token**（沒有 token 驗證/解析邏輯）。signed-token 的驗證與最小情境建構
   應在別的模組（如 `jedi_iam/authz/` 下的 signed-token 專用檔或 jedi-common 側），需另外確認
   M-3 原始清單記錄的確切檔案路徑才能判定是否落在本次範圍外。

**結論**：這是「範圍邊界問題」而非「這輪掃描漏看」——本卡的範圍（8 檔）是按 CM-1546 母卡定義好的切法，
若 M-3 觸發點確實在範圍外，屬正常現象，不代表本輪掃描品質有問題。建議：若要驗證 M-3 是否仍存在，
下一輪掃描 jedi-common 或涵蓋 signed-token 相關檔案時特別對照。

## 這一輪的收穫

沒有新發現。8 個檔案裡的 platform-admin / super-admin / capability 判定條件、decorator 形式守門、
`elevated_session.py` 的提權邊界，兩位獨立研究員讀完都沒找到可攻擊的缺陷。

## 這份報告的可信度

- ✅ effort=low 但**單一研究員讀整個範圍**（不是抽樣，8 檔全讀），且派了 2 位獨立研究員交叉
- ✅ workflow 正常跑完，stamp 為 `verified`，非因額度或錯誤而降級
- ⚠️ low effort 沒有 inventory / threat-model / breadth-sweep 這些 medium 才有的階段，
  是比 medium 更輕的單次讀取式審查，不等於「窮盡式」審查
- ⚠️ 「0 發現」不代表「絕對沒問題」，只代表兩位獨立讀者都沒看出可攻擊的缺陷