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

這一棒在做什麼（白話）

掃「把整份系統安全計畫匯出成 Excel 範本」這條功能的 2 支檔、1,669 行。**這棒不是去「找」問題，是去確認一個已知的洞、以及它旁邊有沒有同類的其他洞。**只找問題、不修問題。

已知的洞是跨 arc 總表第 128 項，判定高風險：這支功能檢查的是「你能不能讀資源庫」，不是「這份計畫是不是你的」——任何一個登入的人，只要知道別人的計畫編號，就能把對方整份系統安全計畫（人名、email、電話、地址、設備 IP、每條控制項的實施狀況）下載走。

為什麼切這一塊、為什麼刻意只放 2 支檔

app/module_frame/service/ssp_import_template_app_service.py 一支就 1,500 行，裡面有 3 支公開方法，而已知的洞只在其中一支。漏洞的本質就是「檔案裡有 3 支方法，只有其中一支被查過」——拆成好幾份丟給不同人看，反而容易再漏掉另外兩支。所以刻意做成單檔大棒。

🔴 本棒必須與 B6 由同一個 runner 連續跑

不可分開派給不同人，也不可隔開時間。

理由：本棒的服務檔 import 了 B6 的 generator.py（第 77 行）與 sheet_definitions.py（第 81 行）來產生實際的 Excel 檔案內容。兩棒有呼叫關係，但沒有任何物理重複的檔案——分開派會出現責任真空：「使用者填的文字有沒有被安全處理」這條線從產生到寫入儲存格，兩邊都只看得到半條路徑，各自會覺得是對方的責任。這正是跨 arc 總表第 118／119 項那條高風險的成因。

兩棒合併會衝到 3,325 行、超過每棒 2,000 行上限的兩倍，不能硬塞成一棒，所以只能靠同一人接續跑來補這條接縫。

重點看什麼

• 🔴 generate_for_ssp 這支已經是確認的洞，不用重查。重點是另外兩支方法。
• 🔴 generate（範本版）：對範本本身匯出。理論上路由層的 require_capability("module-frame.read") 加上服務層如果有查範本歸屬就夠了，但要實際讀過程式碼確認，不要假設。
• 🔴 generate_by_framework_version（框架版本版）：這支完全不掛在任何範本編號底下（在 api/module_frame/init.py 裡它的路由是 /ssp-import-template，沒有範本的脈絡）。要搞清楚它到底是「查全域框架目錄的唯讀操作」（風險低），還是也會碰到某份具體的客戶資料（風險高）。盤點員沒有讀到底層邏輯、無法判斷，這是首腦特別點名要查清楚的一項。
• 路由檔 ssp_import_template_route.py（169 行）有 3 個入口，分別對到上面 3 支方法——逐個核對入口掛了什麼檢查、對應的方法裡又補了什麼。
• 跟 B6 的接縫：呼叫 generator.py／sheet_definitions.py 時傳進去的是不是使用者可控的內容。這條線要接著在 B6 那棒追完。

範圍與邊界

本棒 2 檔／1,669 行：路由入口 169 行、商業邏輯 1,500 行。

不在本棒：產生 Excel 的底層機制在 B6（接著跑）；範本控制項清單的Excel 匯出匯入是另一條不同的路，在 B5。

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