威脅建模

以四個問題形成閉環：我們在做什麼、什麼可能出錯、如何處理、如何確認處理有效。沿用 OWASP 四步主線與 DFD／STRIDE；把模型轉成可追溯的安全需求與驗證工作。來源與歷史文件限制見 source-basis.md。

選擇工作方式

• 新建：從需求、架構與業務流程建立模型，區分規劃中的控制與已存在控制。
• 逆向：從原始碼、文件及部署設定還原模型；輸出候選發現，不把未見控制當成控制不存在。
• 變更：承接既有模型與版本，分析變更元素、相鄰資料流及共同依賴；保留原 ID，不因刪除元件而遺失歷史決策。
• 審查：對既有模型進行覆蓋、證據及追溯檢查；輸出缺口與修正建議，不虛構新的部署事實。

先確認使用者指定範圍與交付位置。從可用材料找答案，缺少資訊時記錄未知並繼續可做的分析。問影響判斷的關鍵問題；新手每輪一個主要問題，附白話用途與回答例子。不要把完整問卷當成啟動條件。

在 SSDLC-Skill 中，依現有階段流程分配 Planner、Generator、Evaluator 的工作；這些是職責，不要求另啟代理。讀取專案規章及適用 inputs/spec_ref.md。產出預設為當前階段 outputs/threat_model.md；已有 IO 契約時遵守其路徑。逆向產物留在候選區，尚未核准的安全需求不直接寫成正向 SSOT。不得自行建立 Baseline、解除關卡或宣告階段通過。

SSDLC 啟用與必要交付條件

安全基準已啟用（security_baseline.enabled = true），或使用者明確要求／選取威脅建模時，威脅模型為必要交付物；其餘情況為選用。

Planner、Generator、Evaluator 與 IO 必填判定均採同一條件。符合條件時，Planner 載入本 Skill 並規劃模型，Generator 完成模型，Evaluator 審查模型；不符合條件時，不因缺少模型而阻擋階段。使用者選取威脅建模不會自動開啟安全基準。必要交付不等於模型或階段已通過，仍依原有審查與核准流程判定。

SSDLC 里程碑

Phase 01 開始規劃範圍與安全需求；Phase 02 完成第一版模型及模型審查；Phase 03 實作並追溯控制；Phase 04 驗證本次版本改善措施；Phase 05 確認部署假設；Phase 06 依事故與變更持續維護。Phase 02 文件完成不等於 Phase 04 控制驗證完成，不會使後續更新工作終止。

1. 界定範圍與建立系統模型

記錄範圍、業務目的、不可接受後果、來源版本、環境、排除範圍、限制及待確認假設。辨識資產、角色、第三方、入口與出口。將架構與控制敘述標成「來源觀察、文件宣稱、使用者確認、推論、未知」，附來源位置；文件宣稱不等於執行證據。

DFD 至少表達外部實體、處理程序、資料儲存、具方向的資料流與信任邊界。給元素穩定 ID：E／P／DS／F／TB；既有 ID 優先沿用。資料流表補充資料種類、協定（未知則標示）、呼叫身分、來源／目的地、跨越邊界及控制執行點。網路位置與角色／租戶權限是不同邊界，不能僅因同在內網便視為同一信任等級。

使用 Mermaid 時，圖中節點附 ID／類型，資料流標 F-ID，邊界子圖標 TB-ID，附圖例；若來源不足，畫明確標示的候選圖，不能用常見架構填空。高風險流程按需要細化；不用追求所有程式函式都進入圖。

建模面向與方法選擇

選擇分析範圍、比較方法或補強覆蓋時，讀取 modeling-dimensions.md。區分建模面向、分析維度、方法／分類與風險評估。以 DFD＋STRIDE 為主線，依案件選用系統資料流、身分授權、資料隱私、業務流程、攻擊路徑、部署雲端、供應鏈第三方、維運復原及風險處置等面向；這是框架整合提示，非統一外部標準或全部必選清單。

記錄方法選擇理由、適用／不適用、證據缺口及覆蓋狀態。需要時用 LINDDUN、濫用案例、攻擊樹、PASTA、OCTAVE／VAST；ATT&CK 與 API Top 10 只補充情境。安全追查與隱私最小化一併考量。新增分類、方法縮寫及實際編號同步更新個案代碼中文清單；通用字典不代替個案定義。

2. 辨識具體威脅與覆蓋缺口

讀取 analysis-prompts.md，使用 STRIDE 檢視相關元素與跨邊界流；再依系統特性選擇業務濫用、隱私、雲端／供應鏈、營運或 AI 提示。不要求每個元素都硬湊六筆威脅。

每筆情境寫成：「具備某能力的攻擊者，在某前提下，經由入口與路徑，違反某安全／業務規則，對某資產造成某後果。」區分安全威脅與純可靠性故障；故障與攻擊相互放大時記錄關係。

威脅 TM-ID 指向實際 DFD 元素／F-ID／TB-ID、來源及假設。記錄既有控制的位置與證據、控制是否覆蓋完整攻擊路徑，以及發現狀態：候選／靜態支持／執行驗證／不適用。靜態支持不代表可利用性已驗證；不適用需附理由。

使用覆蓋表記錄高價值資產、重要流程、邊界及適用面向的分析狀態：已分析／不適用（附理由）／待確認／未分析。不得以威脅數量或 STRIDE 六類皆出現作為完整性證明。對高價值或多步攻擊目標，可補攻擊樹並標出 AND／OR 條件；它不是每個小型變更的必備文件。

3. 排序、處置與跨階段追溯

優先使用組織現有尺度。沒有尺度時用 risk-and-review.md 的暫定定性方法，記錄可能性、影響、理由與不確定性；未知不自動當低風險。風險嚴重度與修復成本分開，AI 不替責任人核定嚴重度或接受風險。

每筆威脅給處置方向：降低、移除、移轉或接受。降低時寫明控制執行點、行為要求、負責角色／待確認人員、期限（未知可標示）及驗證方法。移轉契約或購買保險不代表技術威脅消失；保留剩餘控制與責任。

建立 TM-ID → 現有 REQ／候選安全需求 → CTRL-ID → 實作或工作項目 → TEST-ID／驗證證據的鏈。沿用專案 ID；新增候選以 SEC-CAND-ID 標記，待適用流程核准後映射正式 REQ。不得憑空填入 Issue、負責人或測試結果。將負向、濫用、邊界及必要的正向案例轉成可觀察的驗收條件；測試設計、測試存在與測試通過分別記錄。

分開記錄改善前風險、預期剩餘風險及已驗證剩餘風險。措施尚未實作／驗證時，只能寫預期降低。接受紀錄應有核准者、日期、理由、範圍、效期或重新檢視條件；缺少正式決策便標為待決。

4. 評估、交付與維護

使用 deliverable-template.md 組織交付；小型變更可合併章節。以 risk-and-review.md 檢查模型證據、覆蓋、排序、追溯與驗證，輸出通過／待修正／證據不足的模型審查結論及理由。這不等於階段核准、資安合規或系統安全證明。

重要規範：完整代碼與中文說明對照清單（必須交付）

每次建立、更新或審查威脅模型，必須在交付分析成果前主動建立或同步更新一份完整的「代碼與中文說明對照清單」，不得等使用者詢問才補充。清單須涵蓋本次分析文件、圖表與追溯表實際使用的代碼及縮寫；不只說明前綴，也必須逐項解釋每個實際編號。

• 涵蓋範圍：STRIDE 各分類與實際組合；DFD 的 E／P／DS／F／TB；資產、來源、假設、證據與未決項目 ID；TM／REQ／SEC-CAND／CTRL／TEST 等追溯編號；實際出現的 API 結果碼、重要欄位／類別名稱及技術縮寫。其他命名慣例依該專案實際代碼補列，不硬套示例編號或虛構未使用元素。
• 每項內容：代碼原文、分類、中文名稱／白話用途、本案對應元素或行為、來源文件／位置，以及候選、未知或未驗證等必要限制。說明 / 表示並列、箭頭表示方向或追溯、範圍及來源行號的讀法；區分 STRIDE 的 S／E 與來源 S01／外部實體 E1，避免混淆。
• 存放與查閱：預設在威脅模型所在交付目錄建立 code_glossary.md；已有專案清單則沿用並更新，避免產生兩份不同定義。於模型、成果 README／導覽與最終交付回覆提供可點擊連結及明確檔案位置。可另附可搜尋的離線 HTML，但不能只在聊天中解釋。
• 交付檢核：逐項核對分析與圖表的實際 ID 均可查到對照；一般縮寫、結果碼與重要名稱另檢查語意完整性，不能僅靠正則掃描判定全部完成。新增、改名或退役時同步更新清單及引用，退役 ID 保留歷史說明。缺清單、代碼漏列或定義矛盾時，視為交付待修正，補齊後再交付。

對照清單只解釋已有內容，不將候選安全需求變成正式 REQ、不補造控制或測試結果，也不得包含秘密或真實個資。完整性檢核不代表威脅已確認、控制已驗證或階段已核准。

變更模型記錄新增／修改／退役的元素與威脅、受影響控制／測試及重新檢視的接受決策。遇到架構、資料用途、角色／租戶隔離、第三方、部署邊界、事故或驗證結果變更時，更新受影響部分。只有內容確實更新並具證據，才改變驗證狀態。

執行邊界

建模預設使用文件、圖表與靜態證據；不因此取得掃描、正式環境請求、帳號操作或資料修改的授權。需要主動驗證時，先確認既有授權及允許範圍；沒有授權便交付測試設計與待驗證項目。不要輸出密鑰、完整 Token 或真實個資。掃描結果是證據之一，掃描乾淨不表示沒有設計威脅。