本卡為 module_frame 資安掃描母案。掃 compliance-manager-be 主專案裡「合規範本／資源庫」那一塊程式碼：8 棒、68 支不重複檔、11,114 行，只掃不修。子卡清單在末段。盤點檔：docs/features/FR-113-2609-oscal-host-wiring-security-scan/module-frame-scan-inventory.md

這一批在做什麼（白話）

module_frame 是「合規範本／資源庫」那塊程式碼——客戶自己建的合規範本、原廠給大家用的公版範本，都放在這裡。範本是所有新稽核專案的起點：開一個新專案時，系統會從範本複製一份出來當底。所以範本被人動了手腳，之後開的每個專案都長在被污染的內容上。

這批用 Claude Code 官方的資安掃描工具（claude-security plugin），把這塊程式碼從頭到尾看一遍，要找的是：誰能打這些功能、打了能改到誰的資料、使用者上傳的檔案會被怎麼處理。只找問題、不修問題——修正卡由首腦看完所有報告後統一開。

為什麼要另開這一批

module_frame 原本在 FR-113 盤點時被判斷「入口層的守門看起來比較齊全」（25 支路由檔裡有 15 支已經用了 require_capability 這種角色權限檢查），所以沒有排進原本的十一棒。

這個判斷後來被打臉。 FR-113 的 O5 那一棒本來是去查 SSP 底下六類附屬資料的權限，查完結論是「六組全部守齊，乾淨」。但餵資料給這六組的那支「把整份系統安全計畫匯出成 Excel 範本」的功能，剛好就是 module_frame 的程式碼，而它檢查的是「你能不能讀資源庫」，不是「這份計畫是不是你的」——任何一個登入的人，只要知道別人的計畫編號，就能把對方整份系統安全計畫（人名、email、電話、地址、設備 IP、每條控制項的實施狀況）下載走。這條列進跨 arc 總表第 128 項，判定高風險。

這件事說明一個道理：「掛了檢查」不等於「檢查對了」。 角色權限檢查只問「你是誰」，不問「這筆資料是不是你的」。module_frame 到目前為止沒有一支檔案被完整讀過、確認過有沒有第二道檢查。決策者因此裁定單獨掃這一批。

🔴 這批最該先看的兩支（派工順序的依據）

兩支都是整支檔抓不到任何權限關鍵字，而且都涉及「刪除」或「下載／匯出」這兩種已經證實最容易出事的路徑形狀：

為什麼是這兩支：跨 arc 總表第 128 項是下載（能把別家公司整份系統安全計畫下載成 Excel）、第 133 項是刪除（刪框架不檢查還有沒有客戶在用），已經證實刪除與下載是這批程式碼裡最容易漏掉歸屬檢查的兩種路徑。而「整支檔 grep 權限關鍵字一個字都沒有」這個訊號，跟 FR-113 O2 當初鎖定、後來確認真的有洞的 resource_library_app_service.py 是同一種強度。

怎麼切的（8 棒）

切法原則：按業務路徑垂直切（同一組功能的入口→商業邏輯→資料庫存取放同一棒），不按程式分層水平切——權限漏洞活在層與層的接縫上，只給入口層或只給商業邏輯層，兩邊都看不出來。每棒 2,000 行以內、行數逐檔實算。