本卡屬 module_frame 資安掃描母案（見母卡），第 B1-item 棒。只掃不修。範圍 4 檔／675 行。盤點檔：docs/features/FR-113-2609-oscal-host-wiring-security-scan/module-frame-scan-inventory.md

這一棒在做什麼（白話）

掃範本底下「子項」的新增／查詢／修改／刪除這條路徑的 4 支檔、675 行。子項白話講是「範本裡的一個流程步驟」——底層是流程圖（BPMN）裡的一個呼叫節點，實際的流程圖內容由外部套件 jedi_flow_engine 保管。只找問題、不修問題。

為什麼切這一塊

這條路徑幾乎沒有自己的資料庫存取層：子項的邏輯全部委派給外部套件處理流程圖，整支服務只在刪除那支方法裡跨回範本主體一次。所以縱切下來天生就小（675 行），不是「跟別棒重複太多切不開」，而是這條路徑本來就沒有自己的下層。

建議與 B1c（YAML 整批匯入）由同一個 runner 連續跑，兩者有呼叫關係、對照看才問得出問題——YAML 匯入會批次呼叫這支服務建子項，要確認「YAML 建出來的子項有沒有跟手動建立走同一套檢查」，這個問題只有看過兩邊的人答得出來。兩棒合計 1,600 行，仍在每棒 2,000 行上限內。

🔴 重點看什麼：這支檔的守門分布不均，正是本 arc 抓到四次的形狀

首腦實查過 app/module_frame/service/module_frame_item_service.py（249 行）：

• 🔴 守門只出現在一處：第 7 行 import 了 assert_scope_writable，第 65 行呼叫了一次（在 update_module_frame_item_xml 這支方法裡）。但整支檔有 5 支公開方法：get_module_frame_item（:29）、update_module_frame_item_xml（:46）、add_module_frame_item（:89）、update_module_frame_item（:159）、delete_module_frame_item（:227）。**也就是說：一支有守、四支沒有出現守門呼叫。**這正是本 arc 反覆抓到的「同一支檔裡這條路守了、那條路沒守」——請逐支公開方法核對：哪幾支有守、哪幾支沒有、沒有的那幾支是真的漏了，還是靠入口層或別的機制頂著。
• 🔴 第 229 行是「檢查 A、動手改 B」的病徵：delete_module_frame_item 裡有一行 module_frame_service.get_module_frame(payload.get("moduleFrameUid"))——拿使用者送上來的編號去撈範本。這跟跨 arc 總表第 118／119 項那條高風險是同一個形狀（檢查的是網址上那個東西、動手改的是使用者另外送的那個編號，兩者從沒核對過）。請查：這行撈出來的範本，後面被拿去做什麼？有沒有核對過它屬不屬於呼叫者？還是只要 uid 查得到就往下刪？
• 接縫檔 module_frame_service.py（260 行，重複自 B1）帶進來就是為了讓你追這條線——看得出子項的改動有沒有真的經過範本主體那層的檢查。
• 入口層 module_frame_item_route.py（128 行）：逐個入口核對掛了什麼檢查。

範圍與邊界

本棒 4 檔／675 行：入口 128 行、序列化 38 行、子項商業邏輯 249 行、接縫檔（範本主體服務）260 行。

不在本棒：流程圖（BPMN XML）本身的處理在外部套件 jedi_flow_engine 裡，不是這批範圍——看到程式呼叫它的地方，只看「傳進去的是不是使用者可控」，不要追進套件。範本主體的完整路徑在 B1（接縫檔以外的部分）。

module_frame_service.py 是刻意重複列在 B1／B1-item／B1c 三棒的接縫檔，不是重複派工。

本棒建議與 B1c 由同一個 runner 連續跑，兩者有呼叫關係、對照看才問得出問題。

盤點檔在 docs/features/FR-113-2609-oscal-host-wiring-security-scan/module-frame-scan-inventory.md，裡面有完整的範圍界定、八棒切法與推導。有疑問先翻盤點檔，但範圍以本卡為準。

🔴 先更正一件事：不要拿「完全沒有權限檢查」去掃

跨 arc 總表曾寫「這部分的功能入口只驗證有沒有登入、完全沒有功能權限檢查」。這句話經首腦實際查過程式碼，不成立，照抄去掃會掃出一整棒誤報。實際情況是：系統安全計畫（SSP）那條線的權限是有守的，只是守在下一層——網址入口那層只驗「有沒有登入」，真正判斷「你是不是這個專案的人、是不是負責人」寫在下一層的商業邏輯程式（app service）裡。這種「入口只驗登入、權限守在下一層」的寫法，是本專案 CLAUDE.md 明文允許的正規做法（原文：資源域守門維持 app service 層），不是漏洞。