現況（2026-10-01）：本文是 2026-09-26 的分類快照。文中「未修／待裁」的項目後來已全數處理——FR-114 第 8 批 12 組（CM-2211～2220 等）已修並隨 1.21.0 出貨；1.21.1 再修授權讀取（CM-2369）等。最終狀態以 docs/security-report/SUMMARY.md 問題總表為準（已修 206、拆除退場 15、裁定不修 12、SaaS 前必做 1）。以下內文保留當時的分類過程。

資安剩餘項目總分類（CM-2209）

給決策者一次看完、逐類拍板用。裁完後首腦照這份的編號轉成 FR-119 handoff-to-fix-line.md 那種交接格式，開 FR-114 第 8 批，一次修完再出一包（1.21.0b3 暫停 build 就是在等這份，見 FR-114-STATE.md 最末節）。

編號寫法：#N＝PM 總報告 docs/security-report/SUMMARY.md 的問題編號；總表 N＝資安總表 security-scan-consolidated/README.md §3.1 的項次。兩個都有就都寫。檔:行一律以修正線工作區（fix/security-b1，HEAD 1516d90bc；套件 e758cd6a）為準——那才是第 8 批要改的底版，與主線行號可能差幾行。

還沒修的共 45 項：要決策者裁（丙）8 項、已裁照修（甲）7 項、可直接修（乙）19 項，分 8 組、建議不修只記錄（丁）2 項、已裁暫緩（戊）9 項。

三個要先知道的：

• 原本以為還有一百多件沒修，實際是 45 件。 主線那份 PM 總報告只回寫了第 7 批，第 1～6 批修好的 77 件它還寫「未修」；以修正線那份為準，前 145 件真正還掛著的只有 17 件（13 件未修、3 件部分修、1 件 SaaS 前必做），其中 8 件已裁暫緩（戊類）、#101 已裁不修（不列入）。
• FR-120 這一輪掃出來的 38 項（總表 181～218）：已修 11 項（其中 3 項是修正線順手已收、總表還沒標）、1 項非資安，剩 26 項全在這份裡，是第 8 批的主體。
• 乙類 19 項正常使用看不出任何差別，建議決策者整組一次同意；決策力氣集中在丙類 8 項。丙類只有 1 項是中風險，其餘都是低。

---

現況（2026-10-01）：丙類 8 項決策者 09-26 全部裁完並已修（見 handoff-to-fix-line.md 的 8-G／8-F／8-H／8-I／8-C／8-J），隨 1.21.0 出貨。

每項格式：一句白話（誰能做什麼壞事）→ 修了之後誰會碰到什麼變化 → 選項與代價 → 建議。

丙-1　總表 181｜低｜授權過期只靠每天凌晨一次的排程才轉唯讀

• 白話：客戶授權到期那一刻不會立刻變唯讀，要等排程（UTC 凌晨 2 點，台灣早上 10 點）跑過才生效；排程如果沒在跑（例如只開即時通訊模式的部署），過期客戶可以一直照常新增、修改資料。
• 在哪：common/authz/license.py:280 viewer_is_readonly() 只讀資料庫存的狀態欄；排程在 core/scheduler.py:275-323。
• 修了會改變什麼：過期客戶在到期那一秒就變唯讀，不再有「到期當天還能用到早上 10 點」的寬限。業務或客服若習慣「到期當天還能補照」，會接到客戶「怎麼突然不能改」的電話。
• 選項：
  • 選項一：讀照時當場重算一次，取較嚴的那個（compute_target_status 是純函式、不查資料庫）——即時生效，代價是上面那個寬限消失。
  • 選項二：維持排程，只補「排程多久沒跑就告警」——行為不變，代價是縫還在，只是看得到。
• 建議：選項一。授權到期規則本來就寫「到期即唯讀」，排程延遲是實作副作用、不是設計；要寬限應該用授權檔的寬限期欄位明確給，不是靠排程時間差。

丙-2　總表 184｜低｜首次安裝精靈同時按兩次可能建出兩家公司

• 白話：安裝精靈「開通」這一步中間沒上鎖，裝機者連點兩次（或兩個人同時送），可能建出兩家公司、兩個管理員帳號。要先持有只印在裝機終端機的設定碼才打得到，實務上幾乎只有裝機者自己連點會踩到。
• 在哪：app/setup/service/setup_wizard_service.py:37-41（註解宣稱有資料庫唯一約束，但實際沒有）、:167 查開通、:249 建立。
• 修了會改變什麼：若選加鎖，第二個請求會收到「已開通」錯誤（409），精靈前端要能顯示這個訊息而不是一片空白——前端行為會變。
• 選項：
  • 選項一：只改註解，寫明「並發窗口存在，因需持有設定碼而接受」——零行為變化。
  • 選項二：加資料庫鎖包住「查開通＋建立」，第二個請求排隊、輪到時回 409——要順手確認精靈前端收到 409 的畫面。
• 建議：選項二。一次連點就留下兩家公司是很難事後清的髒資料，修法只有幾行。

丙-3　總表 187｜低｜授權過期唯讀有兩條縫

• 白話：①過期後代理程式的註冊碼照樣能產生（/agents/ 整段豁免唯讀檢查，範圍太寬）；②問卷填答走即時通訊那條路時完全不經過唯讀檢查，過期客戶照樣能填問卷。
• 在哪：common/middleware/license_readonly_mw.py:77（豁免清單）；套件 jedi-survey/jedi_survey/app/handler/fill_survey_socketio_handler.py:164。
• 修了會改變什麼：過期客戶不能再新增代理程式、不能再填問卷。已經裝好的代理程式照常回報（那條是機器對機器，建議保留豁免）。
• 選項：
  • 選項一：兩縫都補——豁免收窄成「代理程式回報結果那幾支」，問卷即時通道補唯讀檢查。
  • 選項二：只補問卷、代理程式豁免維持——理由是代理程式屬基礎設施，過期時讓客戶還能接回機器方便續約後立刻恢復。
• 建議：選項一。「過期＝唯讀」是對客戶說過的規則，唯讀期間新增機器與填問卷都是寫入。

丙-4　總表 190｜低｜雲端硬碟授權連結可以轉寄給別人代按

• 白話：公司 A 的管理員產生一條「連接 Google 雲端硬碟」的授權連結，轉寄給公司 B 的人騙他按同意，B 的 Google 硬碟就被接進 A 公司的帳號。未實測。
• 在哪：app/cloud_integration/service/google_drive_integration_service.py:96-99 產生 state、:113-116 回呼只看 state 本身。
• 修了會改變什麼：授權流程必須同一個瀏覽器發起、同一個瀏覽器完成。「管理員產生連結、交給擁有 Google 帳號的 IT 同事去按」這種分工會失效——如果客戶現場真的這樣做，他們會卡住。
• 選項：
  • 選項一：綁瀏覽器（發起時寫一個 cookie，回呼時比對）——堵住，代價如上。
  • 選項二：不綁、改在回呼成功後寄一封確認信給發起人——分工照舊，事後可察覺。
• 建議：先問客服／實施有沒有看過「代按」的做法；沒有就選項一。

丙-5　總表 185｜中｜使用者上傳的檔案整個目錄公開在 /static/ 不用登入（拿不準乙或丙，放丙）

• 白話：後端把使用者上傳檔案的資料夾設成網站的公開路徑，問卷答案 Excel、意見回饋附件等只要知道路徑就能抓。今天出貨的代理伺服器只轉 /api/1.0 與 /socket.io，所以正式站打不到；但有人為了排錯直接開 8000 埠、或客戶換自己的代理設定，就整包公開。
• 在哪：core/app_factory.py:95-99（static_folder 指向上傳區，static_url_path='/static'）。
• 修了會改變什麼：我查過修正線 BE、所有套件與前端，沒有任何地方組 /static/... 網址給使用者用（範本下載已在 FR-063.1b 移出 static；問卷答案上傳只是存檔備份，套件 jedi-survey/.../task_survey_route.py:148），所以正常使用看不出差別。
• 拿不準的原因：只能證明「程式碼裡沒有」，證明不了「沒有客戶或維運手上存著 /static/ 連結在用」（例如舊版信件裡的附件連結、維運腳本）。
• 修法：static_url_path=None（或設一個不會對外的前綴），寫入路徑不動。
• 建議：當乙類修（關掉公開路徑），release note 寫一句「/static/ 不再對外提供」；若決策者知道有人在用這種連結，改成丙-5 另議。

丙-6　總表 200｜低｜批次完成任務的通知信把操作者暱稱原樣塞進信件 HTML

• 白話：任何帳號把自己的暱稱改成一段 HTML／script，之後他批次完成任務時，收信人開信就看到他塞的內容（可偽造連結、按鈕）。
• 在哪：app/flow_control/service/job_batch_complete_service.py:95,105、app/flow_control/service/workflow_execution_service.py:1219、app/flow_control/service/project_service.py:776（三處同寫法）。
• 修了會改變什麼：暱稱改成純文字顯示。暱稱裡本來就有 <、& 的正常使用者（例如「R&D 王小明」），信裡會從「R&D」正確顯示——今天反而可能顯示錯。其餘人看不出差別。
• 拿不準的原因：信件範本可能有地方刻意讓暱稱帶粗體等 HTML，跳脫後會變成字面顯示。
• 建議：照修（跳脫），放丙只是因為動到寄出去的信件內容，請決策者知悉。

丙-7　#186／總表 165 剩下那一半｜低｜AI 儀表板查問卷缺模組授權

• 白話：沒買問卷模組的客戶，透過 AI 儀表板對 AI 說一句話，照樣能查問卷資料（直接打網址那兩條已補，AI 儀表板這條沒補）。
• 在哪：di_containers/dashboard_apis/survey.py:20-45（兩支申報）；要改套件 jedi-ai-dashboard（jedi_ai_dashboard/app/registry.py 加「需要的模組」申報欄）。
• 修了會改變什麼：沒買問卷的客戶在 AI 儀表板問問卷相關問題會得到「無權限」而不是資料。要動一支不在 b3 發版清單上的套件（jedi-ai-dashboard），多發一支版。
• 選項：
  • 選項一：套件加申報欄、兩支問卷查詢掛上——根治，多發一支套件。
  • 選項二：先把這兩支從 AI 可用清單拿掉——不改套件，代價是有買問卷的客戶也暫時不能用 AI 問問卷。
• 建議：選項一，且與總表 218（同一支套件，AI 儀表板生成端點缺能力點）同一次發。CM-2194 首腦已把這件「轉決策者排批」。

丙-8　總表 218｜低｜AI 儀表板生成端點只驗商務授權、不驗能力點

• 白話：角色設定上看不到 AI 儀表板的人（例如「稽核人員」「IT 執行人員」），直接打網址照樣能生成儀表板，而且每用一次要付兩次 AI 服務費。runner 已實測。
• 在哪：套件 jedi-ai-dashboard/jedi_ai_dashboard/api/routes/ai_dashboard_route.py:103（只有 @require_license）；主專案 core/plugins/ai_dashboard.py:52-61。
• 修了會改變什麼：這些角色直接打網址會被擋（403）。選單本來就看不到，所以正常操作的人看不出差別；會被擋的只有「知道網址、繞過選單」的人，或有人手上書籤存著這個網址。
• 拿不準的原因：DEV 查到這兩個角色沒有該能力點，但客戶現場的角色設定可能不同——若某客戶把這功能開給了沒勾能力點的角色、靠書籤在用，修完會斷。
• 建議：照修，與丙-7 同一次發 jedi-ai-dashboard；放丙只為了讓決策者知道「多發一支套件」。

總表 §7「目前真的還要決策者裁的 7 項」（第 8／13／14／18／18b／5／21 項）是方向類待裁，本文不重寫；與本清單無重疊（第 18b 項管的是 §3.2 非資安第 28／29 項；第 21 項管「落地版證據分類停用」，只影響第 6 節 #130 的急迫度），請直接看 §7 那張短清單。

---

現況（2026-10-01）：甲-1 ✅ 已修（#75，CM-2230／CM-2252）；甲-2～4 🗑️ 隨舊線退場（#9／#66／#67，CM-2222）；甲-5～7 ✅ 已修（#89 CM-2225、#132 CM-2226、#131 CM-2227），均 1.21.0 出貨。

決策者裁過要修，但還沒有修正卡或卡還沒 Done。

甲-2～甲-4 三件舊線、甲-5～甲-7 三件分類容器，派工順序被 CM-1849（FR-107.6 舊線退場）卡住（乙-G 的 #129 同樣），而 CM-1849 本身是個跨兩支套件發版＋e2e 的大卡。決策者要不要讓第 8 批直接做「刪舊線路由」這一小段、不等整張 CM-1849，是這組唯一的排程問題。

---

使用者照正常方式用看不出任何差別。建議決策者整組一次同意。

乙-A　補歸屬／成員檢查（4 項，另 1 項修正線已收）

現況：✅ 已修（8-A，CM-2211，1.21.0 出貨）。

這組是什麼病：只驗「有登入」或「是網址上那個專案的人」，沒驗「你要動的東西屬不屬於那個專案／公司」。修法一律用 common.authz 既有守門，不另寫。

總表 191 修正線已收、不計入，列在這裡是為了讓修正線知道不要重做。

乙-B　診斷包與紀錄遮罩（4 項，與總表 162「部分修」同組）

現況：✅ 已修（8-B，CM-2212，1.21.0 出貨）。

這組是什麼病：回廠診斷包與伺服器紀錄裡，密碼、登入權杖會以各種寫法原樣留下，遮罩程式只認得其中幾種。要一次修完——總表 162 就是只補一種寫法、其他三件未修的前車之鑑。

總表 207（寄信失敗把整組寄信設定含密碼寫進紀錄）修正線已修（套件 jedi-notification commit e12287e2，CM-2111），總表還寫未修，見第 7 節。但它當初暴露的「遮罩不認得 password='值'」仍要在上面 diag_masking.py 那列一起補。

乙-C　輸出前跳脫與安全寫法（4 項）

現況：✅ 已修（8-C，CM-2213，1.21.0 出貨）。

這組是什麼病：使用者可控的字，輸出成 Excel／PDF／查詢條件時沒當成「資料」處理。

乙-D　維運腳本與診斷包路徑（3 項）

現況：✅ 已修（8-D，CM-2214，1.21.0 出貨）。

這組是什麼病：維運指令與出貨主機的預先蒐集，信任了容器內或索引檔裡的路徑。前提都是「已經能動容器內部的人」，但後果是 root 被騙寫到任意地方。

乙-E　首次安裝精靈錯誤處理（1 項）

現況：✅ 已修（8-E，CM-2215，1.21.0 出貨）。

乙-F　刪沒人用的死碼（1 項）

現況：🗑️ 已拆除（M06-16 備用服務由 8-E 拆掉，CM-2215）。

總表 215（解析工作單新增規則一律允許）修正線已收（scripts/sql/2026-09-25-fr114-ap-ar-parse-jobs-rls-fix.sql:21-26,58-63，CM-2195），只剩出貨基線重產時帶到（CM-2197 已列），不計入。

乙-G　證據分類刪除殘留（1 項，與甲-5～7 同一張驗證卡 CM-2061）

現況：✅ 已修（#129，CM-2227，1.21.0 出貨）。

乙-H　刪檔順序（1 項）

現況：✅ 已修（總表 217，CM-2228，套件 5ec9b617，1.21.0 出貨）。

乙類合計：乙-A 4＋乙-B 4＋乙-C 4＋乙-D 3＋乙-E 1＋乙-F 1＋乙-G 1＋乙-H 1＝19 項。中風險 7 項（總表 205／186／209／162／204／208／217），其餘低。

---

現況（2026-10-01）：總表 213 🗑️ 已拆除（CM-2373，1.21.1）；總表 195 🚫 裁定不修。

總表 201「查不到專案就放行」是決策者 09-26 裁定、CM-2208 已照做，不列在這裡；CM-2208 runner 實查 DEV 54,267 個流程實例全部查得回專案，實務上走不到那一支。

---

現況（2026-10-01）：#23 ✅ 已修（CM-2271＋CM-2369）、#104 ✅ 已修（CM-2271）、#24 ✅ 已修（12 張補齊，餘 1 張屬平台層設定）、#105 🕓 SaaS 前必做、#98／#91 🚫 裁定不修、#99 📋 已裁記錄不修、總表 193 🚫 裁定不修、#130 ✅ 已修（CM-2223）。

只列，不展開。

---

7-1　主線 PM 報告 vs 修正線 PM 報告（#1～145）：兩邊狀態不同的共 94 件。

• 77 件主線寫「未修」、修正線寫「已修」——以修正線為準，合回時整批覆蓋即可。
• 6 件主線寫「裁定刪除」、修正線寫「已修」；5 件主線寫「部分修」、修正線寫「已修」；1 件主線寫「裁定做法」、修正線寫「已修」；1 件主線「裁定拆除」、修正線「已修」——同上，以修正線為準。
• 要人看一眼的 4 件：
  • #91：主線「未修」、修正線「⚠️ 部分修（毀損只記警示不拒絕）」。
  • #101：主線「未修」、修正線「⚠️ 部分修（lock 已入版控；https 裁不修）」。
  • #124：主線「未修」、修正線「🚫 裁定不修（比照 #101）」。
  • #109：兩邊都是「裁定退役」，只是格式不同，不用處理。

7-2　主線 PM 報告 #146～198（修正線那份沒有這段）：主線寫未修／部分修共 11 件，實際：

7-3　主線模組頁：M06-flow-engine.md 第 17～22 條（＝#169～#171、#182～#184）全標未修，實際全修（見上表）；第 14 條（#118 前半）標未修，實際已隨 4a416ece 刪除。

7-4　資安總表 §3.1（修正線是照 PM 報告編號派工，不回寫總表）：

7-5　總表 §7 待裁清單：短清單下方註記「第 51 項已裁、FR-114 開卡中，卡號待回填」→ 卡號是 CM-2208（Done，1516d90bc）。

---

判「乙還是丙」用的準則：使用者照正常方式用（走選單、不改網址、不繞路）是否看得到差別。會被擋的只有「繞過選單直打網址」的，算乙；正常流程會變（寬限期消失、分工斷掉、錯誤訊息出現、多發一支套件）的算丙。拿不準一律丙並寫理由（丙-5、丙-6、丙-8）。

打折處：

• 行號以修正線 HEAD 1516d90bc／套件 e758cd6a 為準，第 8 批開工前若修正線又前進，runner 要照卡上「先 grep 驗行號」的紀律重新對。
• 「/static/ 沒有任何地方在用」只查了程式碼（BE、全部套件、前端 src/），沒查客戶端或維運手上存的舊連結——所以丙-5 放丙。
• 丁-3（總表 201 查不到專案）的「全部查得回」是 DEV 的數字，STG／POC 沒查（唯讀可查，但本卡不必要）。