安全漏洞在系統裡的分佈不是均勻的。大多數漏洞集中在幾個特定的設計決策——「這個 API 的呼叫者需要是誰」「這份資料應該只有哪些角色能看到」「這個操作失敗了怎麼辦」。
威脅建模就是在設計階段系統性地問這些問題，而不是等到上線後被攻擊才發現。
STRIDE：最常用的威脅分類框架
Microsoft 的 STRIDE 把威脅分成六類，每類對應一個被破壞的安全性質：
| 威脅 | 英文 | 破壞的性質 | 例子 |
|---|---|---|---|
| Spoofing | 偽裝 | Authentication | 假冒合法用戶的 token |
| Tampering | 竄改 | Integrity | 修改傳輸中的訊息 |
| Repudiation | 否認 | Non-repudiation | 操作後否認「我沒有做過」 |
| Information Disclosure | 資訊洩漏 | Confidentiality | log 裡洩漏密碼 |
| Denial of Service | 服務拒絕 | Availability | 讓系統無法回應 |
| Elevation of Privilege | 權限提升 | Authorization | 普通用戶執行 admin 操作 |
用 STRIDE 做威脅建模的流程：畫出系統的資料流圖（DFD），對每個元件和每條資料流，逐一問「這裡有沒有 Spoofing / Tampering / … 的威脅」，然後決定接受、緩解還是移轉這個威脅。
實際操作：一個簡短的範例
假設設計一個 webhook endpoint，讓第三方服務呼叫。用 STRIDE 快速掃一遍：
- Spoofing：任何人都能 POST 這個 endpoint 嗎？→ 需要驗證來源（HMAC signature 或 shared secret）
- Tampering：payload 可以被中間人修改嗎？→ 需要 HTTPS + signature 驗證
- Information Disclosure：webhook 的 response body 會洩漏系統內部資訊嗎？→ 錯誤回應只給最少資訊
- Denial of Service：攻擊者能用大量 webhook 耗盡 server 資源嗎？→ rate limiting
- Elevation of Privilege：webhook payload 裡的
userId能被假造嗎？→ 不信任 payload 裡的 identity，從 token 裡取
這十分鐘的對話，在設計評審裡就能防掉幾個常見的錯誤設計。
PASTA 和 Attack Tree
PASTA（Process for Attack Simulation and Threat Analysis）：更完整的七步驟框架，從商業目標開始，到攻擊模擬和風險評估。適合正式的安全評估，企業級系統或有合規需求時使用。
Attack Tree：以目標為根節點，向下展開「攻擊者可以怎麼達成這個目標」的樹狀結構。適合分析特定高風險功能（付款流程、帳戶接管）的攻擊路徑。
什麼時候做，誰來做
威脅建模最有效的時機是設計評審階段——在開始寫 code 之前。這時候改設計是免費的，上線後發現問題改起來是昂貴的。
不需要每個功能都做完整的 STRIDE 分析。判斷標準：這個功能涉及認證、授權、外部輸入、或敏感資料，就值得花 15–30 分鐘做快速的 STRIDE 掃描。
威脅建模不需要安全專家在場——開發工程師和 tech lead 一起做就夠了。安全專家的角色是提供框架和最終審核，不是替代開發團隊思考安全問題。