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

這一棒在做什麼（白話）

掃合規範本本身的新增／查詢／修改／刪除／複製這條主線的 19 支檔、1,787 行。從網址入口一路到資料庫存取，完整一條路徑，還帶上兩支「接線設定」（決定哪個程式由誰建立起來的設定檔）。只找問題、不修問題。

為什麼一路帶到底不按程式分層拆：權限漏洞活在層與層的接縫上——只給入口層看不出「商業邏輯那層漏了檢查」，只給商業邏輯層看不出「資料庫那層根本沒有第二道防線」。

為什麼切這一塊

範本主體是這整塊的骨幹：所有子項、清單、附屬資料都掛在它底下，所有新稽核專案都從它複製出來。它的守門結論是 B1-item／B1c 兩棒的判斷基準。

另外這棒是唯一能看到全模組路由總表（api/module_frame/init.py，252 行）與全模組接線設定（di_containers/module_frame/module_frame_containers.py，260 行）的一棒——哪些網址入口存在、每支服務是怎麼被組起來的，只有在這裡看得到。

重點看什麼

• 🔴 **module_frame_route.py 的 PUT／DELETE 有沒有「檢查 A、動手改 B」的形狀。**FR-113 的 O2 就是這樣抓到洞的：同一個 update 方法裡，改「分享身分」那個分支有守衛（assert_scope_writable），改「適用控制項清單」那個分支完全沒有。只要 update／save 方法裡有 if 分岔去處理不同欄位，就要每個分支分開檢查。
• 🔴 module_frame_repo_impl.py 的 update／delete_by_uid／soft_delete_by_uid：有沒有在資料庫查詢條件上加「只能改自己公司的」，還是完全信任呼叫端已經檢查過？如果是後者，代表這層沒有第二道防線——跟 O2 報告裡「資料庫沒擋下來」是同一個風險敘事，要在報告裡點出來讓首腦知道防線只有一層。
• 🔴 di_containers/dashboard_apis/module_frame.py（22 行）：檢查它接出去的東西跟主線是不是同一套守門。 這支把 module_frame_service.get_module_frame_list_for_dashboard 註冊給 AI 儀表板呼叫，是主線之外的另一條入口。要確認這個方法本身有沒有做「只回自己公司的」過濾，不要因為「這是唯讀」就跳過——FR-113 的 O9b 已證實接線漏接會讓守門靜默失效（接線是延遲建立的，接不上只有在那個入口真的被打到時才會現形，平時看起來一切正常）。
• module_frame_service.py（260 行）逐支公開方法跑第①項的落差檢查；複製範本那條路徑特別看——複製出來的東西歸誰所有，是伺服器端決定還是信任前端送來的欄位。
• api/module_frame/init.py（252 行）是路由總表：看有沒有被註解掉的入口，以及被註解掉的入口它的商業邏輯程式是不是還被別的地方呼叫得到（路由關了但程式還在、別的路由通得到它，就是「以為關了其實沒關」）。

範圍與邊界

本棒 19 檔／1,787 行，一條完整路徑：入口（252＋102＋153 行）→ 商業邏輯（260＋70＋34＋32 行）→ 領域層（76＋113＋37＋23＋33 行）→ 資料庫存取（136＋91＋29＋41＋23 行）→ 接線設定（260＋22 行）。

不在本棒：範本子項（流程樣板那塊）在 B1-item；YAML 整批匯入在 B1c；三組清單型資料在 B2；六類附屬資料鏡射版在 B3；Excel 匯出匯入在 B4／B5／B6。

app/module_frame/service/module_frame_service.py 這支也會出現在 B1-item 與 B1c 的範圍裡，是刻意的接縫檔，不是重複派工。

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

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

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