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

這一棒在做什麼（白話）

掃 15 支檔、1,904 行。範本本身也可以編輯六類附屬資料（當作範本的預設內容）：元件、人員、設備清單、繼承授權、參考資料、系統特性。這一批就是這六組的增刪改查，加上範本專屬的兩支匯出／查詢入口。只找問題、不修問題。

為什麼切這一塊

同一個形狀複製六份，是典型的「漏掉一處」風險。 FR-113 的 O5 那一棒查過真正專案那一側的同樣六組，結論是「全部守齊」——但 module_frame 這邊有一份幾乎一模一樣的鏡射版本（程式邏輯是複製過去改的），O5 完全沒有看過這一份。

另外這棒帶了一支首腦特別點名的檔案（見下方重點第二項）：api/oscal/routes/module_frame_template_ssp_route.py——它原本因為「列在 O2 的檔案清單裡」被當成掃過而排除，但 O2 的報告在「這棒沒有回答的事」段落寫的是「掃描沒有針對這支提出發現」——那句話的意思是「工具沒有報出發現」，不是「查過、確認沒事」。這次要把它當成從沒查過的檔來看。

重點看什麼

• 🔴 逐一對照 O5 的標準：O5 報告裡六組的結論是「讀用『你要是這專案的人』、寫用『你要是這專案的負責人』」。看 module_frame 這邊的鏡射版本是不是做到同樣的事。如果因為範本沒有「專案」這個概念而改用了另一套邏輯，那就要問：那套邏輯本身有沒有把「這份範本是不是你家的」問清楚？ 六組逐一核對，不要抽查——「同一形狀複製六份，只有一份漏了」正是這棒要找的東西。
• 🔴 api/oscal/routes/module_frame_template_ssp_route.py（38 行）要當成從沒查過的檔完整讀。 它只掛 @jwt_required()、沒有掛任何角色權限檢查，呼叫 resource_library_app_service.get_template_ssp_ref(mf_uid)（唯讀查詢）。要確認這支唯讀查詢底層有沒有做歸屬檢查。不能因為是唯讀就跳過——跨 arc 總表第 128 項就是一支唯讀的下載端點，照樣外洩別家公司整份系統安全計畫。
• module_frame_party_service.py（323 行，六組裡最大支）優先看。人員資料含姓名、email、電話、地址，外洩的具體後果最明確。
• mf_ssp_export_route.py（71 行）：盤點時已核對過守門齊全（@jwt_required ＋ require_capability("module-frame.read")），底層服務在 FR-113 O2 的範圍內。這支只需要確認路由本身沒問題，不用往下追——但要注意 require_capability 是角色檢查，不回答「這份範本是不是你家的」，所以還是要看它有沒有第二道。
• 六組服務（186／211／220／214／323／101 行）逐支跑第①項的落差檢查，把六組的守門次數列成一張表對照，哪一組少了就是嫌疑犯。

範圍與邊界

本棒 15 檔／1,904 行：六組入口（56／78／78／91／95／99 行）、範本匯出入口 71 行、被重新納入的範本 SSP 查詢入口 38 行、序列化 43 行、六組商業邏輯（186／211／220／214／323／101 行）。

不在本棒：真正專案那一側的同樣六組已在 FR-113 O5 掃過，不重複；mf_ssp_export_route.py 底層的匯出服務在 FR-113 O2 範圍，不用往下追；app/oscal/service/resource_library_app_service.py 已在 O2 掃過（那棒找到的高風險就在那支），不重複掃——只看上面那支入口怎麼呼叫它。

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

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

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

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

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