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

這一棒在做什麼（白話）

掃「用一個 YAML 檔整批匯入合規範本」這條路徑的 8 支檔、925 行。YAML 是一種純文字的設定檔格式，使用者上傳一份，系統就照裡面寫的內容一次建出整個範本連同底下的子項。只找問題、不修問題。

為什麼切這一塊

這是外部檔案進入系統的一條正門，而且是一次寫入一整包資料的批次操作——一次寫錯就是整個範本連同底下所有子項都被建出來。它同時是完全獨立的第三條路徑：解析器、轉接器、資料傳遞物件都只有這條路在用，所以獨立成一棒。

建議與 B1-item（範本子項）由同一個 runner 連續跑：這條路徑會批次呼叫子項服務的 add_module_frame_item／update_module_frame_item 建子項，要確認「YAML 建出來的子項有沒有跟手動建立走同一套檢查」——這個問題只有看過兩邊的人答得出來。兩棒合計 1,600 行，仍在每棒 2,000 行上限內。

重點看什麼

• 🔴 匯入建出來的範本歸屬哪家公司，是伺服器端決定的，還是信任使用者上傳的檔案裡寫的欄位？ 如果 YAML 裡可以指定「這個範本屬於哪家公司」而系統照單全收，那就是任何人都能往別家公司塞範本。
• 🔴 批次建子項時走的是不是同一套檢查。 module_frame_import_service.py（415 行）會呼叫 module_frame_item_service.add_module_frame_item／update_module_frame_item。去 B1-item 那棒對照 module_frame_item_service.py——已知那支檔 5 支公開方法裡只有 1 支出現守門呼叫，要確認 YAML 這條路走的是有守的那支，還是沒守的那幾支。
• 入口層 module_frame_import_route.py（95 行）：掛了什麼檢查。上傳類入口通常掛的是「你能不能建範本」這種角色檢查，不回答「你能不能改這份既有的範本」——如果匯入也支援「覆蓋既有範本」，這個落差就是缺口。
• 解析器 yaml_to_module_frame_parser_adapter.py（65 行）：YAML 解析有沒有用安全的載入方式（不安全的 YAML 載入可以讓上傳者在伺服器上執行任意程式）、有沒有巢狀深度或大小上限。
• 接縫檔 module_frame_service.py（260 行，重複自 B1）：看匯入建出來的範本有沒有經過主體那層的檢查。

範圍與邊界

本棒 8 檔／925 行：入口 95 行、商業邏輯 415 行、解析器與轉接器（65＋17＋9 行）、資料傳遞物件與動作型別定義（49＋15 行）、接縫檔 260 行。

不在本棒：子項服務本身在 B1-item（對照看，但不重複掃）；範本主體的完整路徑在 B1。

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

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

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

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

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