🔴 一頁看完

第 1 棒 H2 掃完了。結論：任何一個能登入的帳號，只要知道一個任務編號，就能讀走別家客戶的稽核證明清單（檔名、描述、雲端硬碟連結、上傳者、檔案指紋）——系統只檢查「你有沒有登入」，沒檢查「這個任務是不是你們專案的」。 同一個檔案裡新增／更新／刪除三處都有檢查，只有「讀」漏掉，是漏寫不是設計。流程留言的讀與寫也一樣漏了，任何登入者可對別人專案的流程塞留言、還會即時推播給該專案成員（可拿來假冒同事釣魚）。而這幾張表在資料庫層的隔離全是關的、job_evidences 與 element_variables 連租戶欄位都沒有——與 FR-086 檔案存取「四層全空」同一個病。三條共用一道修法：補一行既有的 assert_project_participant(...)。

開卡時的八個疑點：五成立、兩證偽、一無問題。 證偽的一項值得記：守門檔註解寫「tenant admin 放行（RLS 仍限租戶）」，追到源頭那個旗標其實是平台超級管理員，所以「租戶 A 管理員動租戶 B」不成立；但註解錯了、它宣稱的兜底也不存在。

📄 H2 報告

第 2 棒 H1 也掃完了。結論：任何登入者只要知道一個輪次編號，就能讀走別家客戶的稽核階段歷程，包括每次退回是誰做的、退回理由全文（網址上帶的專案編號程式從頭到尾沒用過）。「查目前階段」那支也一樣：用你填的專案編號查角色、用你填的輪次編號撈資料，兩者不核對，角色不符也不擋、照樣回整包資料（含流程執行編號，那是另一批 API 的鑰匙）。但開卡時最大的疑點「跨專案推進／退回別人的稽核」經查寫不成立：下游的稽核輪次套件會拿輪次自己的專案再查一次角色，七條寫入路徑首腦逐一開檔核對都有。只是擋住它的是別人不是本層，哪天新增一支不走那個套件的 handler 洞就開了。force 雙版本三個檢查員 0:3 否決、首腦同意：錯位真的存在，但只能跳過設計上就是「軟提醒」的規劃就緒檢查，真正的守門全看外層變數。另發現推進／退回的操作者顯示名稱可由呼叫端自填（權威帳號欄不受影響，LOW）。

H1 的證偽比證實更有價值：兩個最大疑點一個「讀成立寫不成立」、一個「不成立」，三條被否決的候選首腦獨立追完整攻擊路徑，結論與檢查員一致。runner 另抓到工具一處錯誤（它宣稱 compliance.projects 有 RLS，實查沒有，門檻反而更低）。

📄 H1 報告

第 3 棒 P1 也掃完了。結論：一張惡意流程圖能把伺服器卡死。 程式沿流程圖的分岔點往下走時不記得走過哪裡，「分岔點繞回自己」的圖每次讀都 500；更糟的是「一路串接 40 個分岔點」的圖，程式把同一個分岔點算兩次、每多一個工作量翻倍，永遠算不完、連錯誤都不報，一條工作執行緒就卡死，多打幾次整個系統對所有客戶不回應。存進去是一次性動作（要有存流程圖的權限），但之後任何正常使用者打開那輪稽核就會替攻擊者觸發。同檔另外兩支走訪函式都有記路，只有這支沒有，是漏寫。另一條：讀範本時無條件解析 XML 且沒防呆，一筆空字串範本會讓所有人的清單頁都 500。開卡時最擔心的 XML 老問題全部實測擋住：讀本機檔案、實體炸彈、五萬層巢狀都過不了解析器（xmltodict 0.14.2 預設關實體、expat 迭代式）。整個套件零 eval／exec，三支吃檔案路徑的方法零呼叫者（死碼，建議刪）。首腦另判 runner 報的第三條「套件來源走明文 http」在範圍外且是既有 CM-1634 的重複，不另計。

📄 P1 報告

第 4 棒 H3 也掃完了（runner 沒交付，首腦補寫）。結論：任何登入者丟一份特製的流程圖給「檢查流程圖」這支 API，就能把後端一條工作程序卡住兩分鐘，連打四次整個系統對所有客戶停止回應。 這支 API 不檢查你有沒有流程範本權限、不限制圖多大、而檢查器對每個分岔點都把全部連線掃一遍。與 P1 的「惡意流程圖卡死執行緒」是同一組病，但門檻更低：不用存進去，打一次就炸。另一條：範本清單與單筆的讀取沒掛 flow_template.read 能力點，同租戶內任何登入者都拿得到全部範本的完整流程圖——這是本專案「讀取端點漏守門」第四次出現。開卡七項疑點四成立、兩確認沒問題；「凍結副本不帶租戶」查出機制（租戶靠 flush 前從登入身分自動填，沒身分就留空）並修正了 FR-087 的描述：191 筆裡只 5 筆是輪次快照、186 筆是原廠母版，回填要分兩類、根因待補查。

📄 H3 報告

第 5 棒 H4 也掃完了。真正新的一條：專案裡定義為「只能看、沒有待辦」的 viewer，其實可以把別人的稽核任務標成完成、或把流程退回上一關——完成與退回這兩支只檢查「你是不是這個專案的人」，沒檢查「這件任務是不是你的」，稽核紀錄上的經手人會變成他。守門政策檔自己寫著這是 2026-06-05 的使用者決策（任一角色皆通過），所以要先問決策者：是刻意讓所有參與者代為完成，還是漏了？runner 另報兩條首腦改判為重複：流程留言零守門（H2 已登記第 51 條，且那個檔不在本棒 scope）、compliance.projects 隔離關閉（FR-087 第 43 條甲組與 FR-083 第 10 條已記三處）。卡片八項疑點全部有答：申報給 AI 儀表板的三支查詢不是 <strong>kwargs 形狀（卡片猜錯成因），但確實零租戶過濾、全靠關著的資料庫隔離兜底；啟動流程時改寫範本 XML 的對象視呼叫者而定**（輪次走快照沒事、module-frame 匯入走母版會互相覆蓋，記非資安 bug）；通知不帶留言原文、收件人從專案往下查；known_project_id 唯一來源是伺服器端解析。範圍外六條憑證有一條新型態：SMTP 寄信密碼、LDAP 綁定密碼、MinIO 金鑰、GitLab 權杖整張設定表被貼進對話紀錄，併 CM-1607。

📄 H4 報告

其餘一棒（P2）當時未掃（後已掃完，見 P2 段）。首腦讀碼時看到的疑點如下。

讀碼時看到的三個最值得先驗的疑點（未經工具驗證，行號已開檔核對）：

1. 推進／回退稽核階段時，「專案編號」與「輪次編號」各查各的、從不核對彼此——專案編號只用來查你的角色、輪次編號只用來找流程。若成立：A 專案的管理者帶自己的專案編號＋B 專案的輪次編號，就能推進或回退 B 專案的稽核。
2. 流程留言與任務證明「讀」完全沒守門：只驗登入，不驗你是不是該專案的人。而這幾張表的資料庫隔離全關、job_evidences 連租戶欄位都沒有——猜到一個編號就能讀（留言還能寫）別家客戶的資料。與 FR-086 檔案存取同一個病。
3. 推進請求裡的 force 旗標有兩個版本：權限檢查看外層的、實際做事的 handler 讀 ctx 裡的。外層填 false、ctx 裡填 true，非管理者可能跳過「規劃就緒檢查」啟動稽核。

資料庫層實況（DEV 唯讀實查）：流程相關 10 張表只有 1 張隔離是開的，其餘 9 張關閉，其中 3 張連租戶欄位都沒有。FR-087 只盤了其中 3 張，另 7 張是本 arc 新增的實況。

產品裡每一個稽核專案都是照一張「流程圖」在跑：規劃 → 稽核 → 改善 → 結案。每個階段誰能按「推進」、按了之後系統要做什麼，都由「流程引擎」決定。它也負責讀寫流程圖本身（BPMN 格式的 XML 檔），以及每個任務的完成、退回、留言、證明文件。

這個 arc 要回答三個問題：① 有沒有辦法操作別家客戶（或別的專案）的流程與任務？② 有沒有辦法用一張惡意流程圖把系統弄掛？③ 流程資料在資料庫層有沒有隔離兜底？

• 從未掃過。跨 arc 總表 §4 排它第一：「風險密度最高——XML 解析與授權缺口同時存在，真正的端點全在宿主」。
• 宿主比套件本體還大：套件 72 檔（攻擊面口徑，排除測試與 3 個 BPMN 範例後 69 檔 .py），主專案宿主接線 92 檔（總表原估 60～80）。套件自陳 0 route，19 條 live route 全在主專案。授權判定全在宿主那半邊——與 FR-077／078／079 同型。
• 首腦讀碼看到的疑點密度高（見上方三點與各子卡「重點看什麼」）。

排序判準是「可利用門檻」不是嚴重度標籤（決策者 2026-09-12 定的判準）。一次只派一棒。合理停損點在第 3 棒之後（74 檔已涵蓋門檻最低與解析面），但沒跑完六棒不能宣稱「jedi-flow-engine 掃過了」。

接縫：H2 的守門政策檔 ↔︎ H4 的 assert_project_participant／反查鏈（同一條鏈兩端，互相允許越界讀）；P1 的 BpmnUtils ↔︎ P2 的執行 service（P2 只看餵進去的是什麼，不重審解析器）；H1 的 complete_main_workflow_job 住在 H4 檔內。

檔數核對：總表寫「套件 80 檔／宿主約 60-80」，實際 git ls-files 套件 72（含 3 個 .bpmn 範例）、宿主 92。六棒合計 150 檔覆蓋宿主 78＋套件 72；宿主未入棒的 14 檔全是空 __init__.py 與一支 deprecated shim（common/util/workflow_project_guard.py，2 行 re-export）。

核 stamp：verified、候選 11（去重 10）、30 票全投、9 條達標、unreviewed_candidate_sites: 0、研究員派 2 回 2。與 runner 自述一致。

逐條開檔核對（不信 runner 自述）：

越界檢查：範圍外 6 條逐一對照，全落在既有卡，不另計。注意力稀釋：30 票有 18 票投在範圍外，真正投在 23 檔的只有 12 票——「只有這三條」不可宣稱。

首腦改判：F9 嚴重度 runner 保留意見交決策者。首腦判維持 MEDIUM：假冒同事推播釣魚是實質衝擊，但前提與 F1 相同（需取得 UUID）而外洩內容是留言非證明本體；若決策者認為釣魚面更重可升 HIGH。

§2.9 落點：F1／F8／F9 全進 🅰 組「只驗身分不驗歸屬」（與第 34～47 條同病、修法可抄）；三張表無租戶欄進 🅱 組「要先改表結構」那類（與 23／47／7 同難度）。

現況：已處理（早期未開卡，後由 FR-114 修正線照 M06 問題總表修完，1.21.0 出貨），登記總表 §3.1 第 49～51 項。

核 stamp：verified、候選 12（去重 11）、33 票全投、8 條達標、unreviewed_candidate_sites: 0、研究員派 2 回 2、耗時 4 小時。與 runner 自述一致。交付四件齊全（報告／commit 1e95823b 只含報告一檔／Notion append 含 hash 與 run ID／狀態「修正待驗證」）。

逐條開檔核對：

越界：範圍外 4 條逐一對照 CM-1607／1608／1629／1631，全舊案。

首腦改判：無。F5／F6 維持 MEDIUM（前提需取得 UUID，與 H2 F1 同；但外洩的是稽核判斷的敘事文字，PM 可視需求升 HIGH）。

§2.9 落點：F4／F5／F6 進 🅰 組（「守門查對了人卻查錯了物」，與第 45 條「收了專案編號卻不用」同型）；F8 進 🅶「一行能修」；project_audit_rounds／round_stage_transitions 無租戶欄進 🅱「要改表結構」。新的一條規劃相依進 🅘：本層「靠下游擋」，修 F4 時要把 advance_stage／rollback_stage 一併補歸屬檢查。

現況：已處理（早期未開卡，後由 FR-114 修正線照 M06 問題總表修完，1.21.0 出貨），登記總表 §3.1 第 52～54 項、§3.2 第 13 項（force 雙版本清理）。

runner 提的跨棒觀察採納：project_audit_rounds／round_stage_transitions「無租戶欄且無 RLS」是 FR-087 13 張表之外的死角，同型的表可能還有——已登 §3.4，母卡收口時單獨盤一次。

核 stamp：verified、候選 4（去重 3）、9 票全投、3 條達標皆 3:0、unreviewed_candidate_sites: 0、研究員派 2 回 2、耗時 7 小時 15 分（本 arc 最久，agent 12 個 1 個出錯）。與 runner 自述一致。交付四件齊全（報告／commit ebd3b1e1 只含報告一檔／append 含 hash 與 run ID wf_c14982f8-67a／狀態）。

逐條開檔核對（對 jedi HEAD 45f14ad9）：

版本漂移：掃描從 151c5f88 起跑，期間 jedi HEAD 移到 45f14ad9。首腦逐檔核對 P1 範圍的差異只有 logger 名稱、註解、刪 __main__ 與三個 .bpmn 範例，無邏輯變更，三條發現行號已對 HEAD。但 P2 範圍變了：plugin.py（261 行）拆成 plugin/__init__.py／assembly.py／contract.py／runtime.py／wiring.py，infra/models/__init__.py 也改了——P2 scope 已重算為 49 檔，派工前要重寫卡片（差異：plugin.py → plugin/ 五檔；另多了 api/__init__.py／api/guards.py／domain/ports.py 三支新檔——套件開始長 api 層，原 plugin.py 自陳「無 route」的前提要重驗）。

首腦改判：F2 範圍外重複（見上）。F1／F3 維持 MEDIUM。

§2.9 落點：F1 屬資源耗盡類，與 CM-1638（AI 聊天無上限）、§3.1 第 31 條（分頁無上限）同型，目前 §2.9 沒有這一組，新增 🅹「資源耗盡」；F3 進 🅹 同組（一筆壞資料拖垮查詢）＋🅶（寫入端補 schema 一行）；三支死碼方法進 🅶。

現況：已處理（早期未開卡，後由 FR-114 修正線照 M06 問題總表修完，1.21.0 出貨），登記總表 §3.1 第 55～56 項、§3.2 第 14 項（死碼）。

runner 未交付四件（無報告、無 commit、無 Notion 回寫、狀態未改），首腦依手冊第三節第 3 點補寫報告並核對。本 arc 第一次、全計畫第四次（C1／S7／B2／H3）。

核 stamp：verified、候選 10 去重 10、30 票全投、10 條全 3:0、5 條降級（4 條 HIGH→MEDIUM、1 條 MEDIUM→LOW）、研究員派 2 回 2、耗時 2h16m。scope 13 檔與卡片逐檔相同。

逐條開檔核對：

七項疑點自答（runner 沒答，首腦補）：見報告 §5。重點：① 宿主 flow_templates 的 mapper 不解析 XML，壞 XML 存進去讀不會炸、發布會擋，與 P1 F3 套件側每讀必解析是兩張表兩種行為；② 內建範本守門四處呼叫無遺漏；③ DTO 無敏感欄位；④ 凍結副本不帶租戶的機制＝套件範本鏈零 tenant_id 處理、靠 jedi-common db_mw.py:64 flush 前從 get_user_context().tenant_id 自動填，沒身分就留空；DEV 實查 191 筆裡 provider='snapshot' 只 5 筆、Billows-Official 母版 186 筆（jediadmin 119／blsadmin 72，2026-07-27～08-09，127 筆仍連著執行紀錄），FR-087 §5.2「191 筆凍結副本」的描述要修正，根因（當時 module-frame 匯入路徑的 context tenant 為 None）補查一個 git log -L 即可。

首腦改判：無。同意檢查員的兩處降級。

§2.9 落點：F7 進 🅹 資源耗盡（與 P1 F1／F3、CM-1638、第 31 同組，可與 P1 合一張「BPMN 輸入強固化」卡）；F10 進 🅰 讀端點漏守門（第四次）；F9 併 CM-1608。

現況：已處理（早期未開卡，後由 FR-114 修正線照 M06 問題總表修完，1.21.0 出貨），登記總表 §3.1 第 57～58 項。

交付四件齊全（報告／commit c6c12e68 只含報告一檔／Notion append 含 hash 與 run ID wf_ba3ef1cb-e96／狀態「修正待驗證」）——加了「開掃前先回報四件落點」那句之後這棒做滿了。核 stamp：verified、候選 9 去重 9、27 票全投、8 條 3:0、1 條 0:3、無降級、研究員派 2 回 2、耗時 4h51m；scope 21 檔逐檔相同；掃描版本 8fc8c1c1 到 HEAD 範圍內零 diff。

逐條開檔核對與改判：

八項疑點的新資訊（runner 答得完整，兩處修正卡片的猜測）：① 申報給儀表板的三支是 query_entity 形狀不是 **kwargs，卡片猜的成因錯，但零租戶過濾是真的——併入 FR-083「27 支零守門」，不另計；④ _patch_template_xml_job_uids（:429-441）寫回的是傳進來的 workflow_template：輪次流程傳快照（audit_round_app_service.py:348）沒事，module-frame 匯入傳母版（module_frame_service.py:241）多流程共用會互相覆蓋——記 §3.2 第 15 非資安 bug；⑦ 問卷 uid 進 link_task_survey（jedi-survey task_survey_service.py:140）只 verify_survey_exist_by_uid、未見租戶檢查，套件不在 scope，列 §3.4 沒讀到。

範圍外 6 條：外-1／外-3／外-4／外-5 分別落 CM-1607／1631／1629／1608。外-2 是新型態：part-verbatim-03-of-03.md:5933 把 system_configs 整張表 dump 進對話紀錄，含 SMTP Gmail 應用程式密碼、LDAP 綁定密碼、MinIO 存取金鑰、GitLab 權杖——首腦開檔（遮罩）確認四種型態都在，全部 scan 報告 grep 零命中。併 CM-1607 並在該列補這四種型態；SMTP 那把與 CM-1605「測試信端點外洩平台 SMTP 密碼」是同一組憑證。runner 另比對 .env 確認 Google 密鑰仍是活的，首腦以 .env 值前綴 grep 對話紀錄命中 11 檔屬實（CM-1631 已記「不是每套安裝各自產生」）。

§2.9 落點：第 59 條進 🅷「要先做產品決策」（政策自陳是決策）＋🅰；§3.2 第 15 進非資安。

現況：已處理（早期未開卡，後由 FR-114 修正線照 M06 問題總表修完，1.21.0 出貨）。

交付四件齊全（報告／commit 31c0d7f6 只含報告一檔／Notion append 含 hash 與 run ID wf_ca839a58-ac4／狀態「修正待驗證」）。核 stamp：verified、候選 3 去重 2、6 票全投、1 條 3:0、1 條 0:3、無降級、研究員派 2 回 2、耗時 3h21m；stamp 內 scope 49 檔；掃描版本 ac9c152，掃描期間 jedi HEAD 走到 677f20f（task-platform 的改動），jedi_flow_engine/ 零 diff。

runner 唯一報的一條自標重複，首腦同意：P2-1 流程留言零守門＝H2 第 51 條（決策者 2026-09-13 已裁升 HIGH）。本棒的價值是從套件側證實 element_variable_service.py:26/:50 同樣零檢查——不存在「套件有擋、宿主漏傳」的可能，守門只能加在主專案 app service 層。這句已補進總表第 51 條。

首腦獨立開檔核對四項，全部屬實：① 主專案六個目錄 grep 零 import 套件的 WorkflowExecutionService——卡片寫「complete_job／revert_job 零授權檢查是設計如此、宿主包一層」，實況是宿主整支重寫了自己的，套件那 13 支公開方法目前沒有任何外部入口；② JobExecutionService 在 di_containers/flow_engine/workflow_excution_containers.py:113 建了 provider，全 codebase 零取用——接好沒人用的插頭，6 支方法零守門零租戶檢查，哪天接上就是現成的無守門端點，登記 §3.2 第 16 為未來陷阱；③ plugin/assembly.py:39 建的 blueprint 沒掛任何 resource，api/guards.py 整支只有一支 runtime()，名字叫 guards 但不是守門，與主專案 common/authz/workflow.py 不構成兩套並存；④ domain/ports.py 兩張插槽是讀設定與寄信，不是權限判斷，沒接不會變放行。

被否決的那條反而有用：研究員報「element_variables 沒掛租戶 mixin、比姊妹表危險」，三個檢查員以出貨基線 schema 一致否決——因為姊妹三張的隔離開關也全是關的，反差不存在。這坐實「四張流程表資料庫層一道隔離都沒有」：workflow_executions／job_executions／workflow_templates 三張 FR-094 已接（CM-1770／1771／1772），element_variables 連租戶欄都沒有，只能靠程式層守門，即第 51 條那批。

兩處 runner 沒做、首腦記下：DB 隔離狀態是讀 scripts/init/02-schema.sql 不是 DEV 實查（runner 自陳）——與首腦 H2／H3 的 DEV 實查結果一致，不需重查；工具沒留逐檔閱讀帳本（coverage.research 空），「49 檔只有這一條」的信心停在中等，但卡片九項疑點無一「沒讀到」。

無新發現，無需修正。六棒收口：母卡 append 六棒總表；SUMMARY 等決策者下令。

現況：已處理。 對應 docs/security-report/M06-flow-engine.md：24 件中 23 件已修（隨 1.21.0 出貨，含 viewer 可代完成他人任務／回退流程的守門、凍結副本、惡意流程圖卡死執行緒等）、1 件裁定刪除（M06-14＋16 三支接收路徑，CM-2215）。

• 套件：~/Projects/Jedicogy/module/jedi-python-package/jedi-flow-engine/（scanRoot 指此子目錄，與 FR-086 B1 同做法）
• 宿主接線：api/flow_engine/、app/flow_engine/、domain/flow_engine/、infra/flow_engine/、di_containers/flow_engine/、di_containers/dashboard_apis/flow_engine.py、common/authz/workflow.py、app/flow_control/service/oscal_stage_*.py
• 相關前案：CM-1559（無身分時隔離全關）、FR-087 T1（workflow_templates／workflow_executions／job_executions 三張表與 191 筆無主凍結副本）、FR-083 D2（儀表板 27 支零守門）、FR-079 F13（**kwargs 掉租戶過濾）、FR-086（四層全空的檢查清單）
• 首腦手冊：.claude/skills/security-scan-lead/SKILL.md
• 跨 arc 總表：security-scan-consolidated/
• 現況：FR-075/handoff/security-scan-STATE.md

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

證據與盤點

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

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

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

相關需求：

• FR-075 — jedi-package-security-audit
• FR-079 — bulletin-security-scan
• FR-083 — ai-dashboard-security-scan
• FR-086 — file-upload-security-scan
• FR-087 — tenant-isolation-audit