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

這一棒在做什麼（白話）

掃範本底下另外三組清單型資料的 12 支檔、1,642 行：① 這套範本要求哪些控制項要做（控制項預設清單）② 每條控制項底下要驗哪些稽核目標（稽核目標預設清單）③ 範本可以掛哪些參考文件（參考文件池）。三組各有自己的入口、商業邏輯、資料傳遞物件，一棒看完一條完整路徑。只找問題、不修問題。

🔴 為什麼這一棒排全批第二順位

三組裡的參考文件池那支——app/module_frame/service/module_frame_reference_document_service.py（257 行）——是這批盤點裡兩支權限關鍵字 0 次命中的檔案之一：8 支公開方法，grep require_／authz／permission／Forbidden 一個字都沒有，而且其中含一條刪除路徑。

跨 arc 總表第 133 項（刪框架不檢查還有沒有客戶在用）已經證實刪除是最容易漏掉歸屬檢查的路徑形狀之一；「整支檔 0 命中」這個訊號則跟 FR-113 O2 當初鎖定、後來確認真的有洞的檔案同一種強度。兩個訊號疊在同一支檔上。

重點看什麼

• 🔴 優先讀 module_frame_reference_document_service.py 的 8 支公開方法，特別是 delete_from_pool／update_meta／attach_to_control_default 這幾支。盤點時看到的模式是「拿 module_frame_uid 去呼叫 verify_module_frame_exists_by_uid」——這支方法只確認範本存在、不確認範本屬於誰。⚠️ 要逐支方法讀完再下結論：可能真的漏了歸屬檢查，也可能靠路由層的 require_capability 加上別的機制頂著（某個裝飾器、某個共用 base class 做了檢查但關鍵字沒對上）。不要看到 0 命中就直接斷定是洞，也不要因為「路由層有守」就跳過——角色權限檢查不回答「這份範本是不是你家的」。
• 另外兩支服務（控制項預設清單 240 行、稽核目標預設清單 269 行）跑第①項的落差檢查：守門次數對公開方法數差多少，差很多的優先盯。
• 三組都是「清單型資料」，典型形狀是「先查範本、再批次改底下的項目」——查第③項「檢查 A、動手改 B」：查的是範本，動手改／刪的是不是另一張表、另一個使用者送上來的編號？
• 參考文件池那條刪除路徑：刪之前有沒有檢查「這份文件還有沒有別的控制項在引用」，還是直接連鎖刪除？（總表第 133 項就是這個形狀。）

範圍與邊界

本棒 12 檔／1,642 行：三組各自的入口（139／147／281 行）、序列化（46／49／61 行）、商業邏輯（240／269／257 行）、資料傳遞物件（49／47／57 行），三條完整路徑。

不在本棒：範本主體本身的增刪改查在 B1；範本的 Excel 匯出匯入在 B5。

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

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

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

所以這批掃描要問的問題是「逐支公開方法核對守門是不是齊全」，不是「找沒有守門的端點」。

★ 前面各棒的收穫，這一棒請帶著追

FR-113 已掃完十一棒，找到的高風險全部是同一個病：有人守了一半——同一支方法裡，這條路有檢查、那條路沒有。合規範本的寫入路徑被三條不同的路打穿（編輯控制項清單、Excel 匯入、Word 匯入），每一次都是這個形狀。Word 那條最明顯：同一個判斷式三條分岔，前兩條有完整權限檢查、旁邊還有十幾行註解解釋為什麼要這樣守，第三條只有一行註解「驗存在」就放行了。