資安掃描總彙整

這份檔在回答一個問題：掃了那麼多，結論是什麼、還有哪些要修。 六個掃描 arc 的報告各自在自己的 FR 資料夾，這裡只做跨 arc 收斂——不重複細節，每條都給座標。 逐條技術細節請點各棒報告；現況與派工紀律看 FR-075/handoff/security-scan-STATE.md。

• 掃了 6 個 arc、27 棒，涵蓋 jedi-iam（290 檔）、License 鏈（118 檔）、遠端 Agent（部分）、jedi-notification、jedi-bulletin、jedi-issue（158 檔），另有 2026-07 的主專案 BE/FE 工具掃描。
• 累計成立的資安發現約 80 條，開出 40 張修正卡：24 張已 Done、15 張待派／Not started（含 1 張 CRITICAL、2 張 HIGH）、1 張暫緩。
• 最急的一張到現在沒動：CM-1595（遠端 Agent 控制面四端點完全不驗身分，CRITICAL，免登入即可取走客戶機器的明文憑證）。它「沒派」是決策者裁定「PM 統一安排修正」的結果，不是漏掉。
• 另有 13 項掃出來但還沒開卡（見 §3），其中 4 項是真 bug 只是不算資安。
• 25 支 jedi- 套件裡只掃過 6 支*，jedi-common（全部套件的地基）至今沒有一次算數的掃描。
• 同一種病一再出現：讀取端點漏守門已第三次（CM-1585／1589 已修、FR-079 公告待修、FR-081 意見回饋待修）；憑證被工作過程寫進版控也第三次（.env.test／JWT 金鑰／DB 密碼 249 檔）。修法可以抄，但要治本得改工作方式。

面板狀態決定可信度，三種「掃完」不一樣：

• ✅ 面板完整跑完且有實質票數——FR-081 六棒是至今唯一全勤的 arc（84 票全投、零漏投、零中斷）。關鍵不在檔數而在分開跑：六棒一次都沒撞額度，對照 FR-079 B2 撞兩次、跑 14 小時。

• ⚠️ 工具零發現 ≠ 乾淨——FR-081 的 I3／I4／I6 三棒工具在範圍內都是 0 條，那三棒真正的產出全是首腦補查的（含「六張表零 RLS」）。小範圍的棒次尤其明顯。

• ⚠️ 下面兩棒要打折看：

• S7 等於沒掃——研究員越界跑去重複 S1，middleware／domain service／plugin.py 預設值／login_log／ui_route 從未被讀過。決策者已裁重跑。

• R1 的七條可信、「只有七條」不可信——三人驗證面板 105 個 verifier 全部撞額度上限，0 票投出。七條是 runner 與首腦各人工開檔核對兩遍確認的（事實陳述，不是推論），但覆蓋率無法宣稱，故加開 R1b 補掃密碼學核心。

2.1 ✅ 已 Done（24 張）— 不用再看

⚠️ 這 24 張多半只進了 DEV／套件源碼，還沒發版上 STG/POC——見 §5 上版待辦。

2.2 🔴 待派／Not started（15 張）— 這是「還有哪些要修」的核心

按嚴重度排序。全部未動是決策者裁定「PM 收集完所有掃描結果再統一安排」的結果，不是漏派。

CM-1559 的關鍵更新：盤點發現 X-Tenant-ID: 0 這條利用路徑已被 FR-069.16 擋死（context.py 加了隸屬檢查）。根因仍在，但已不是可利用的漏洞，故優先級可降。runner 建議下刀順序是「先拿掉 not tenant_id 條件（爆炸面只有 signed_token 一條路徑），再改 elif is_pg 為 fail-closed（動全站 session 進入點）」。

2.3 ⏸ 暫緩（1 張）

這一段最容易漏——它們散在各報告的「建議開卡」段落裡，沒有進 Notion。

3.1 資安類（7 項）

3.2 非資安但是真 bug（4 項）

面板判定「不是資安問題」，但程式碼缺陷是確認過的，值得開一張非資安卡順手修：

9、10 兩條目前打不到（套件那支 service 沒有任何呼叫者，主專案走自己那支）。

3.3 掃描本身的補洞（2 項）

3.4 「等於沒查」，不能當作乾淨

• 公告 content 的儲存型 XSS——需開 FE repo 查渲染方式，FR-079 B2 未查。
• 審計欄位 subquery 是否繞過 users 表 RLS——FR-079 B2 未查。
• docs/、scripts/ 兩棵樹從來不是掃描目標——多條金鑰外洩是密鑰專項順手撈到的，「範圍外」的發現不代表那些地方被檢查過（FR-078 N2 與 FR-081 皆明載）。
• FR-081 六棒的逐檔閱讀帳本都是空的——無法證明每個檔都被讀到結論。六件事都是真的，但「jedi-issue 只有這六個問題」不成立。

25 支 jedi- 套件，實質掃過 6 支。 未掃合計約 102 棒、122 小時*（純掃描，不含驗收／開卡／修正）。

首腦建議的下一批順序（按風險，不是按檔數）：

1. jedi-common（92 檔／8.4h）——全部套件都 import 它，session_scope／@transaction／RLS 注入／error handler 都在這，CM-1559 的根也在這。它出問題等於 25 支全中。
2. jedi-integrity（20 檔／2.4h）——CP 值最高，全是簽章與完整性驗證，FR-076 已在它身上順手撞到一條 HIGH。
3. jedi-file-upload（61 檔／6h）——路徑穿越與任意檔案讀取的天然溫床。
4. jedi-detection 剩下的 140 檔——客戶憑證解密在這，掃描參數會變成 agent 端執行的指令。
5. jedi-participant（103 檔）——jedi-iam 管「你是誰」，這支管「你在這個專案能幹嘛」。

jedi-oscal-v2（364 檔）建議獨立 arc：風險形狀不同（XXE／解析炸彈／資源耗盡），混進授權鏈掃描會讓卡片失焦。

兩個排計畫時的陷阱（FR-077／FR-079 換來的）

1. 「某某套件掃過了」這句話要問範圍——看報告要看 scope 清單，不是看套件名。
2. 排名表的檔數只涵蓋套件本體、不含宿主接線——jedi-bulletin 被列為「攻擊面小」，但「誰能看到哪一則公告」的判定整個在主專案的 33 檔裡，十個重點有八個落在宿主側。排下一支時要先問「這支有沒有宿主那一半」。 FR-081 的宿主那半藏在 feedback/ 底下，用檔名 grep issue 會漏掉。
3. 切棒尺放寬為 40 檔，但前提是一次只跑一棒（FR-081 換來）——FR-077 R1 的 42 檔曾讓 105 個 verifier 全滅，據此把尺收到 30；FR-081 I5 故意放到 40 檔，15 票全投零中斷。差別不在檔數，在有沒有和別的工作搶額度。 六棒全部分開跑一次都沒撞額度，對照 FR-079 B2 撞兩次、跑 14 小時。
4. 套件自己的註解會騙人——FR-081 開卡前查證，套件檔頭自稱「GitLab／GitHub 整合沒在用、約佔 58%」是錯的（主專案六處實際呼叫）。照它跳過就會漏掉唯一會帶著密碼對外連線的那半邊。這是工具已知盲點「被程式碼註解說服」的現行犯。

24 張 Done 的修正卡多數只在套件源碼與 DEV，尚未發版：

• jedi-iam：13 張修正卡待發版 → 主專案 pyproject.toml pin → 重出 image → 部署 STG → 部署 POC
• License Center：CM-1583／1584 走 LC 部署四步；1583 帶兩支 alembic migration（皆 nullable）需套 STG/POC
• 主專案 BE：CM-1580 的部分唯一索引 migration 需套 STG/POC（DEV 已建）

⚠️ 上版行為變化提醒（會直接擋連線，上版前先確認）：

• CM-1565（Redis TLS）：若 STG/POC 已開 TLS 但憑證有問題，上版後會直接擋連線。
• CM-1560（LDAP TLS）：上版後預設驗憑證，若有接 LDAP 且憑證未配置好會連不上。

掃描本身：

1. 下一支掃哪個套件——FR-081 已完成，首腦建議 jedi-common（地基，至今無算數掃描）或 jedi-integrity（CP 值最高）。
2. S7 重跑時機——已裁要重跑，未排。

憑證處置（FR-081 帶出，三件都要裁）：

3. DB／Redis 密碼要不要換？（CM-1629）依 FR-079 判準查過安裝程式，每套安裝各自產生、客戶端是安全的——但這條不能因此降級：同一把用在 DEV、出貨基線庫與 STG／POC，而 POC 依規定等同正式環境、基線庫是出貨映像檔的來源。與「只影響開發機」的 JWT 金鑰那條不同。 若要換，DEV 與基線庫可規劃；STG／POC 屬環境異動，依鐵律要決策者當次明示。 另建議把 Redis 與 DB 密碼分成兩組（目前同一組）。
4. Google 應用程式密鑰要不要現在轉？（CM-1631）這把不是每套安裝各自產生的，是 Google 後台一組、所有環境共用，轉了要重發到各環境。加密金鑰若要換，得先寫好「把既有權杖重新加密」的程式，否則客戶既有的雲端硬碟整合會全部失效。
5. Nexus 上 jedi_issue 0.0.14／0.0.15 兩個舊套件檔下架了沒？——CM-1573 沒收乾淨的尾巴（那兩版把含密碼的設定檔打包進去發布）。程式碼查不到，要連 Nexus 才能確認。

其他：

6. CM-1559 修法方向——盤點已完整回寫 Notion 卡，等裁「先下第二刀再下第一刀」這個順序可不可以、以及三類分流的範圍。
7. 上版時機——jedi-iam 13 張 Done 修正卡何時與 LC 一起發版上 STG/POC。
8. CI 加秘密掃描（gitleaks／trufflehog 擋在 pre-commit 或 CI）——新增基礎設施要決策者裁。FR-081 的 249 檔事件讓這件事更急：憑證被工作過程寫進版控已是第三次（.env.test／JWT 金鑰／DB 密碼），九成來自查資料庫的指令被寫進對話紀錄。不改工作方式，清了還會再長出來。

已裁決、不要重問的：POC DB 與 blsadmin 密碼不需更換（測試機專用）／不重寫 git 歷史（.env.test 事件）／修正卡一律不派由 PM 統一安排／FR-079 F12 降衛生類併 CM-1607／F15 先記錄不開卡。

六個 arc 各自的站（本表只做收斂，逐條技術細節在各站）：

其他座標：

母卡：FR-075 CM-1546／FR-076 CM-1566／FR-077 CM-1591／FR-078 CM-1602／FR-079 CM-1609／FR-081 CM-1612。

維護紀律：本表由掃描首腦在每一棒驗收完成時同步更新，與回寫母卡同一個動作（security-scan-lead skill 第五節第 7 步「回寫四處」與 5.1 節）。不要累積到 arc 結束才補——2026-09-09 建好後隔天就因 FR-081 收口而 stale，而 stale 的總表比沒有更糟。

相關需求：

• FR-075 — jedi-package-security-audit
• FR-076 — license-chain-security-scan
• FR-077 — remote-agent-security-scan
• FR-078 — notification-security-scan
• FR-079 — bulletin-security-scan
• FR-081 — issue-tracking-security-scan