FR-075 jedi-* 套件安全掃描與修正

這是六個資安掃描 arc 之一。 六個 arc 合起來的結論、修正卡狀態、還沒開卡的待辦與覆蓋率地圖，在跨 arc 總表：security-scan-consolidated/——要問「總共掃出什麼、還有哪些要修」看那份，本頁只講這一支。

用 Claude Code 的 claude-security plugin 逐支掃描自家 jedi-* 套件，把掃出來的問題整理成清單， 再由決策者逐條裁決要不要修、修的優先序，然後開卡交 runner 執行。

掃描不等於修正——本 FR 的產出是「問題清單 + 裁決結果」，實際修正另外開卡。

jedi-* 套件是全產品的地基：jedi-iam 管登入與授權、jedi-common 管 DB session 與 RLS。 這兩支出問題等於整個產品出問題，而它們過去只被人工 review 過，沒做過系統性的安全掃描。

2026-07 那次資安掃描（docs/features/security-scan-2607/）掃的是主專案 BE 與 FE，沒有涵蓋 jedi-* 套件。

第一輪試掃（2026-09-05）不完整，已重做完成。 那一輪派了 40 個 agent 只有 28 個回報， 且驗證面板從未執行。找到 19 條問題、7 條 HIGH 經逐條開檔核對屬實， 但覆蓋率無法宣稱——被砍掉的 12 個 agent 對應哪些區塊沒有紀錄。那份清單是下限不是全貌。

重做的方式是把 jedi-iam 切成七塊、每塊獨立跑完整條含驗證面板。

切法是「按業務模組垂直切」：每一棒拿到一個模組從 route 到 service 到 domain 到 repository 的完整路徑。 第一版曾把 S4 到 S6 按 DDD 分層水平切（api 一塊、service 一塊、infra 一塊），決策者指出這樣研究員看不到 層與層的接縫，而權限漏洞恰恰活在接縫上——route 收了一個 id，要看到 service 才知道有沒有驗證那個 id 屬於呼叫者。那三張卡（CM-1550 到 1552）已作廢。

七棒合計 266 檔，覆蓋 jedi-iam 全部生產程式碼（只排除翻譯檔與 i18n script），各棒無重複。

S4～S7 首輪全滅的教訓（2026-09-06）：四棒都超過 40 檔，研究員繼承 runner 的 Sonnet 5（200K）， plugin 把研究員寫死 effort: xhigh 且要求追完每個 caller，讀到 20 幾萬 token 時每步思考變慢， 超過 workflow 的 180 秒無 tool call 即判 stalled 就被砍掉從零重派。S1～S3 是 8～34 檔沒踩線。 解法只改一件事：runner 主 session 切 Opus 5 (1M context)，卡片、範圍、effort 全不動。 不切小範圍——S7 證明研究員為追脈絡一定往外讀，切小只會多一輪重複。細節見 scan-methodology.md。

jedi-common 後續另案掃描（FR-085 起）。

S4 的 CRITICAL 首腦親自追完整條路徑確認：route 免登入（設計正確）→ dump 的 schema 第一欄就是 uid → service 組信件連結用的正是同一個 uid → 重設端點只驗 token 不問身分。知道目標 email 即可接管任何帳號， 含原廠 admin。修好進版前建議 nginx 對 /forget-password 加 IP 節流當臨時緩解（環境異動，等令）。

CM-1559 的來由：S2 掃描 0 發現，但 signed_token.py 確實在範圍內。工具沒報是因為該檔 docstring 把 fail-open 寫成刻意設計，研究員讀到就接受了。而 jedi-common db.py 自己的註解記載了 tenant-102 帶 X-Tenant-ID: 0 看到整張 roles 表的實際案例。工具會被程式碼註解說服，看報告時要記得這個盲點。

S1 的 8 條併成 5 張（同檔同根因併卡）。第一輪的 M-6（未設加密時明文 bind）S1 沒重新找到， 首腦判定併入 CM-1560 順帶處理，不另開卡。

派工衝突：CM-1560／1561／1562 都動 ldap_adapter.py 或 user_auth_provider_service.py， 序列做不平行。CM-1557／1558／1563／1564 各自獨立可平行。CM-1559 影響面最廣單獨慢做。

換人或換帳號接手，讀 handoff/security-scan-STATE.md（現況）＋ .claude/skills/security-scan-lead/SKILL.md（手冊）。FR-075 與 FR-076 共用這份 STATE。

• scan-findings-batch1.md — 第一輪的 19 條發現。不完整、未經面板驗證， 但七條 HIGH 已逐條開檔核對，可當作重掃的對照基準
• scan-iam-1-auth-and-external-identity.md — S1 重掃結果：8 發現（5 HIGH／3 MEDIUM，面板全數 3/3 一致）、verified，含與第一輪 H-1～H-5/H-7、M-5、M-9 的對照分析
• scan-iam-2-authz.md — S2 重掃結果：0 發現、verified，含與第一輪 M-3 的對照分析
• scan-iam-3-mfa-turnstile.md — S3 重掃結果：2 發現（1 HIGH／1 MEDIUM）、verified，含與第一輪 H-6／M-4／L-1 的對照分析
• scan-iam-4-user-and-password.md — S4 掃描結果：5 發現（2 CRITICAL／1 HIGH／2 MEDIUM）、verified、17 agent 全回報 0 錯誤、面板全數 3/3、全部落在指派範圍內無越界；含全系列首見 CRITICAL（忘記密碼端點回傳重設憑證，知道 email 即可接管任何帳號含原廠 admin），並確認第一輪 M-10 路徑穿越
• scan-iam-5-role-and-capability.md — S5 掃描結果：2 發現（皆 MEDIUM）、verified、14 agent 全回報 0 錯誤；F1 角色讀取端點無守門（外洩租戶權限矩陣＋成員名冊含 email/電話/職稱）、F2 權限守門採計已停用/軟刪除/過期/他租戶的角色指派（與 get_viewable_by_user_uid 的正確查法已分岔）；本塊第一輪未涵蓋故無舊發現對照，兩條均為新發現
• scan-iam-6-tenant-org-unit.md — S6 掃描結果（1M 重跑）：1 發現（MEDIUM）、verified、26 agent 全回報 0 錯誤、8 候選全投完票；F1 組織單位讀取端點無 department.read 守門（外洩整棵部門樹含 metadata/路徑/稽核帳號，與 S5 F1 同病灶建議合併修）。另有 3 條被面板判定「真 bug 但非資安」值得另開非資安卡：tenant/org-unit 部分更新清空 parent_id、org_unit 建立 created_user 寫成 NULL。文末附錄保留首輪 Sonnet 失敗記錄
• scan-iam-7-login-uiroute-common.md — S7 掃描結果：流程跑完但研究員讀檔越界，9 條面板確認發現裡 8 條是 S1 已知問題重複（對應修正卡 CM-1560~1564），只有 1 條 Redis TLS（M-7 對照）真正落在本棒範圍且尚未開卡；本棒真正獨有的 middleware/domain service/plugin.py 預設值等部分沒有任何候選，需另外收窄範圍重掃
• scan-methodology.md — 工具用法、effort 等級的成本差異、兩次失敗的教訓

• docs/features/security-scan-2607/ — 2026-07 主專案資安掃描，範圍不含 jedi-* 套件
• docs/claude/jedi-packages.md — jedi-* 套件名冊與 API 參考
• CLAUDE.md「外部套件異動規範」— 後續修正時要遵守的發版紀律

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

證據與盤點

交接與收口時間軸（handoff/，2 份）

由新到舊。每份是某一棒次交接當下的完整現況快照，看某個時間點「當時知道什麼」請從這裡進。

卡片內容（決策紀錄、驗收條件）以 Notion 為準，本頁只記座標。

相關需求：

• FR-069 — jedi-module-extraction