從需求進入

從需求面進入本模組、從 0.8 資安與資料保護需求 開始——該章節定義六議題（權限分級 / 伺服器防護 / 資料遮罩 / 傳輸保護 / 密鑰與秘密 / 稽核追蹤）、各別 link 到本模組對應章節（7.2-7.7）。本模組是該六議題的 implementation-ready 層、提供問題節點、判讀訊號、風險邊界與交接路由。

模組方法

問題驅動方法的核心是讓案例退到證據角色，讓知識網以服務環節問題為主體。

1. 先定義服務環節問題與責任邊界。
2. 再定義判讀訊號與風險後果。
3. 接著定義交接路由與前置控制面。
4. 最後在問題觸發時引用對應案例。

模組分工定位

本模組提供觀念、判讀與路由。實作細節由對應模組承接，確保概念層與實作層分工清晰。

• backend/04-observability：偵測、稽核訊號、證據鏈與 alert / dashboard 實作。
• backend/05-deployment-platform：入口、部署與平台邊界實作。
• backend/06-reliability：驗證、回復與變更節奏實作。
• backend/08-incident-response：分級、指揮、通報與復盤實作。

案例驅動讀法

資安案例的核心讀法是先判斷事件發生在 identity、credential 還是 network control plane，再選擇對應治理控制。

反例與規模對照入口： 7.C9 反例 / 7.C10 對照。

回退判讀寫法見 0.C4 回退判讀寫法，資安案例要優先保留身份作用域、憑證輪替、例外權限與控制面擴散條件。

從章節到實作的 chain

各章節交付三樣：問題節點清單、判讀訊號、控制面 link。判讀完成後沿兩條 chain 進入 implementation：

1. Mechanism chain：點問題節點表的 [control-name] link 進 knowledge-cards、那層展開機制 / 邊界 / context-dependence。例：[authentication] 的 knowledge-card 是該 control 的 mechanism SSoT。
2. Delivery chain：章節「交接路由」欄位指向下游模組——04-observability（偵測 / 稽核 / 證據訊號）/ 05-deployment-platform（入口 / 配置 / 平台邊界）/ 06-reliability（驗證 / 回退 / 演練）/ 08-incident-response（分級 / 指揮 / 通報 / 復盤）。

兩條 chain 走完，控制面交付完整。Implementation 強度取決於兩條 chain 的完成度，章節閱讀本身完成 routing 階段。

各章節在「從本章到實作」段給該章的具體 control-name 例子跟交接路由 list、本段是模組級的共用規格。

Vendor / Platform 清單

資安控制服務見 vendors — 先以 index 大綱規劃身份、IAM、Secrets、KMS、WAF、PKI、供應鏈、SIEM 與 DLP 服務頁。這層目前只做服務頁教學大綱，不展開個別服務正文。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

章節列表

模組完成狀態

主章目前已形成基礎問題節點、藍隊操作循環、跨模組延伸章節與推演素材庫，並新增 7.27 的 credential rotation 實作示範。素材庫已完成 11 張 field cases、4 張 scenarios 與 7 張 control patterns，並回寫到 7.B1、7.B9、7.B12 與 7.24。比例設計依 素材庫比例支撐主情境的反向驗證，文章主情境保持 4-5 個、素材庫保留 2-3 倍來源做反向驗證。資安章節進入穩定維護狀態。

下一輪推演大綱

推演資產化的完成條件是讓讀者能從一個事故壓力出發，依序找到案例卡、情境卡、控制模式與回寫章節。這條路徑完成後，資安章節即可進入穩定維護狀態。

本輪輸出

本輪已完成主章的問題節點、藍隊循環與延伸章節骨架，並把設計輸入、放行判準、可靠性共同控制面、事故回寫與成熟度節奏接回後端實作路由。

跨分類引用

• → infra 模組二：身分與憑證地基：IAM role / policy、OIDC 短期憑證與權限邊界設計，是本模組 secret management 與 credential rotation 的地基層
• → infra 模組八：治理好習慣：secrets 不進 code 的儲存與引用模式、密鑰命名規範

資安教學內容的 audit 標準不該由「讀者讀不讀得懂」決定、該由「讀者照做後系統會不會出破口」決定。 讀懂是學習端的成本、破口是生產端的代價、兩者級數不同。

級數不對稱的後果：一般教學的 audit bar 是「讀者能不能拿到 reasoning」、資安教學的 audit bar 必須升級為「讀者照做後的實作可不可被驗證為無破口」。預設讀者會 implement、不只 read。

情境

資安章節（backend/07-security-data-protection/）的內容形態不是純概念說明、是「問題節點 + 判讀訊號 + 風險後果 + 前置控制面 + 交接路由」。讀者拿到的不只是知識、是會拿去做防護設計的依據。

寫作便利的選擇（在一般教學沒問題、在資安教學會出事）：

• 用「能擋」「能防」「可以避免」這類動詞、沒寫適用 threat model
• 給防護方法、沒寫「這方法擋不到什麼」
• 引用 OWASP / RFC / NIST、沒寫版本 / 沒驗證引用句意
• 描述判讀訊號、沒給訊號失效的 deployment 條件
• 把 mitigation 寫得通用、沒拆 context-dependence（同 mitigation 在 SaaS / on-prem / 多租戶條件失效不同）

這些選擇在一般教學是「簡潔風格」、在資安教學是 silent 破口——讀者照字面理解去實作、產生 false sense of security（見 #100 false sense of security 是資安寫作的主要失敗模式）。

理想做法

把資安內容的審查標準從 readability-first 升級到 verifiability-first：每個論述要回答「讀者照做後、實作的正確性能不能被反向驗證」。

三條 audit bar

1. Threat model 對稱性：講「防 X」必須寫「不防 Y」、形成對稱論述（見 #101 threat-model-explicitness）
2. Mitigation 對位驗證：防護措施跟 threat 的對應鏈要可驗證、不能只是「業界常用」（見 #102 mitigation-threat-alignment）
3. Context-dependence 顯式化：mitigation 在不同 deployment 的有效性差異要寫出來、不假設讀者知道（見 #103 mitigation-context-dependence）

寫作流程的差異

沒這樣做的麻煩

False confidence 在生產系統累積

讀者讀完含糊論述、心理上覺得「學到防護方法了」、實作時用最直覺的詮釋。當實作有 gap 時、讀者不會警覺——因為「我學過了 / 我做了」。等同 #82 字面攔截 vs 行為精煉 在資安領域的具體展現：教學含糊 = hook 規則太粗、看似有保護、實際抓不到行為層的破口。

最危險的是：含糊的資安教學比沒讀過更糟。沒讀過的人會去查標準、會問人；讀過含糊版的人會跳過驗證、直接 implement。

破口的可利用窗口跟教學擴散同步放大

含糊的資安內容若被多個團隊 / 文章引用、所有下游 implementer 都繼承同一個 silent gap。攻擊者只要找到原始教學的 misinterpretation pattern、就可以批量利用所有 implementation。一般教學的錯誤是 個別讀者的學習成本、資安教學的錯誤是 系統性風險面擴大。

後續修補無法 trace 到原文

當下游事故發生、回溯到「讀者照某教學實作」時、含糊的原文難以判定是「教學錯」還是「讀者誤解」——因為含糊本身就是 ambiguity 來源。理想的資安教學應該讓「實作 vs 教學」可以被 1:1 對照、出問題時找得到 root cause。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安內容（auth / crypto / 傳輸 / 機敏資料 / 標準引用 / mitigation 設計）、以及任何「讀者照做後錯誤是不可逆 / 系統層」的高風險領域（例：concurrency correctness、distributed consistency claims、financial / medical 計算）
• 不適用：純概念說明文章（沒有讀者會直接照做的 step）、實驗性 / playful 內容（讀者預期自行驗證）
• 邊界：「verifiability-first」≠「百科全書化」——不是把所有邊界都寫滿、是讓 audit 標準對應風險量級、必要時引用更深的標準文件而不重述
• 過度應用反例：把每個資安句子都加滿 boundary / threat / context 補述、文章變密度爆炸、讀者讀不下去——audit bar 對應風險量級、低風險段落（背景介紹 / 概念 anchor）保持簡潔、把 verifiability 投資集中在 mitigation / 標準引用 / 實作 step 段落

本卡是後續資安 audit 系列卡片（#100-105）的 anchor、確立「為什麼資安寫作需要學術級審查標準」的論證基底。

資安教學的主要失敗模式不是「讀者學不到」、是「讀者以為學到了」。 學不到是 active failure（讀者知道自己沒會、會去查）、以為學到是 silent failure（讀者跳過驗證、直接 implement、破口在生產系統累積）。

中間那行（false sense of security）是資安寫作要消滅的目標。比沒讀過更糟——沒讀過會去查，讀過含糊版會跳過。

情境

讀者讀完資安章節、會自然形成一個結論：「我學到了 X 防護方法」。這個結論的安全性依賴它能不能被分解成可驗證的子句：

• 對什麼 threat 安全？
• 在什麼 deployment 條件下成立？
• 什麼前提失效時這個防護失效？
• 跟既有實作疊加會不會 silent 干擾？

如果讀者讀完無法回答這四題、結論就是空殼——表面上「學到了」、實質上是 false sense of security。資安章節（backend/07-security-data-protection/）的「問題節點」表格容易長出這個結構：

1判讀訊號：登入驗證節奏失衡
2風險後果：身分擴散速度提升
3前置控制面：authentication / incident-severity

讀者讀完知道「節奏失衡很危險」、但不知道：

• 「節奏失衡」具體閾值是什麼？（threat model 沒寫）
• 「authentication」是哪一層的 control？適用什麼 deployment？（context-dependence 沒寫）
• 用了 control 之後、什麼情況下還是會擴散？（mitigation 邊界沒寫）

讀者照字面實作 → 心裡覺得「節奏控管做了、authentication 用了」→ silent gap。

理想做法

把「讀者讀完會說什麼」當成 audit 主軸。對每段論述跑這個反向驗證：

反向驗證模板

寫完一段、自問：

1. 讀者讀完會在心裡形成什麼結論？（例：「我做了 session invalidation 就安全」）
2. 這個結論能不能拆成可驗證子句？（對什麼攻擊安全 / 什麼條件下 / 什麼前提失效）
3. 如果不能、補哪一塊讓它能？（threat model / context / boundary / 前提條件）

走完三步、原文若仍是「讀完會 false confidence」、必須改寫——加 contrast、加 boundary、加前提、或拆成更小的可驗證單元。

識別 false-sense 句子的訊號詞

下列詞彙在資安內容是 high-risk、預設要被 audit：

每出現一個訊號詞、檢查段落有沒有對應的 boundary 補述；沒有 → 補完或改寫。

Methodology-layer 訊號詞（多 layer false sense）

False sense of security 不只發生在 mitigation layer——還會在 methodology / framework / process layer 出現。Reader 讀完「我們有方法論 / 有路由系統 / 有 maturity stage / 有 release gate / 有 tripwire」、形成「有 system / framework = 安全」結論、跳過驗證下游 control 是否真擋 threat。

Methodology-layer 訊號詞清單：

驗證方式跟 mitigation layer 同：reader 讀完能否拆 falsifiable 子句？能不能列出具體下游 control + 各自 boundary + 各自驗證訊號？不能 → methodology-layer false sense 產地、補「下一步路由 / 必連控制面 / 各 control 的 verification check」。

對抗「只給結論」的句法

跟 #94 正向改寫保留對照論據 同骨：資安結論單獨成立會空降、必須跟 contrast / 邊界 / 前提同句承載。

沒這樣做的麻煩

Silent failure 比 noisy failure 更貴

Noisy failure（讀者讀不懂、實作報錯、被 reviewer 抓到）發生在開發前期、修復成本是 commit 等級。silent failure（讀者以為對了、ship 進生產）發生在生產系統、可能等到事件才被發現、修復成本跳到事件處理 + 通報 + 復盤 + 信任修復。

跟 #82 字面攔截 vs 行為精煉 同病——#82 的核心是「驗證工具的字面層 vs 行為層 ceiling」：CI 字面層通過不代表行為層沒問題、但 CI 通過會建立 false confidence、阻止後續行為層檢查。本卡是 #82 在資安寫作的具體展現：含糊的論述提供字面 mitigation、讀者讀完建立 false confidence、阻止實作端的行為層 verify。

教學擴散把單篇 silent gap 放大成系統性 risk

含糊的資安內容若被多團隊引用 / 翻譯 / 二次教材化、原始 misinterpretation pattern 會被批量繼承。攻擊者只需找一次 misinterpretation、就可以利用所有 implementation。一般教學的錯誤是個別讀者的學習成本、資安教學的錯誤是 risk surface 集體放大——跟 #67 寫作便利度跟意圖對齊反相關 在資安領域的展現：寫得越輕鬆、擴散越快、silent gap 越廣。

事故發生後的 root cause 無法還原

下游事件 root cause 分析時、若實作來源是含糊的教學內容、無法判定是「教學錯」還是「讀者誤解」——含糊本身就是 ambiguity 來源、責任邊界模糊。理想的資安內容應該能讓「實作 vs 教學」1:1 對照、出問題時 trace 得到 root cause（#82 字面攔截 vs 行為精煉 的 traceability 面）。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安內容（auth / crypto / 防護 / 標準引用 / mitigation 設計）的 audit；任何「讀者照做後錯誤是不可逆 / 系統層」的高風險領域（concurrency 正確性、distributed consistency claims、financial / medical 計算）
• 不適用：純概念說明 / 歷史背景內容（讀者不會直接照做）、研究探討文章（讀者預期自行驗證）
• 邊界：「消滅 false sense of security」≠「把所有邊界寫到極致」——是讓讀者讀完能列出邊界、不是讓讀者讀完什麼都不敢做。Audit bar 是 verifiability、不是完備性
• 過度警覺反例：對所有句子都打防呆 disclaimer、把資安內容寫成 legal-style 「在 X 條件下、若無 Y 前提、且不考慮 Z 攻擊路徑、可能可以」——讀者讀不到任何 actionable 結論、退化成「什麼都不要做」式 paranoia、跟 silent failure 一樣有害；判別準則：讀者讀完應該能列出可實作的 mitigation 集合 + 各自 boundary、不是「不知道該不該做任何事」

本卡是後續資安 audit 維度卡片（#101-104）的主軸——每個維度都在回答「false sense of security 在哪裡產生」。

寫資安 mitigation 必須對稱：每段「防什麼」要配「不防什麼」、不能單邊寫。 讀者沒拿到「不防 Y」、會用 universal validity 詮釋 mitigation——預設「防 X」涵蓋整個 threat space、實際只是 X 的 subset。Threat model 的 boundary 是 mitigation 論述的一部分、不是補充說明、不能省。

差別在於讀者實作時的覆蓋判斷——前者讀完跳過 endpoint 驗證、後者讀完知道要補 Y。

情境

資安寫作有兩個誘因會讓 threat model boundary 被省略：

1. 正向陳述優先規範（AGENTS.md 原則二）會誤把「不防 Y」歸類為負面句、批量改寫時刪掉、跟 #94 正向改寫保留對照論據 同病
2. 章節篇幅控制會把 threat boundary 當成「進階補充」往後丟、留主章節「乾淨主旨」

兩者都會產出 universal-flavored 的 mitigation 句子。讀者讀「使用 X 即可保護 Y」時、Y 會被腦補成「所有 Y 相關攻擊」、X 跟 Y 之間的 scope 配對被 silent 地放大成 universal。

實際資安章節（backend/07-security-data-protection/）會出現的形態：

1判讀訊號：登入驗證節奏失衡
2前置控制面：authentication / incident-severity

這個寫法把 threat 抽象成「節奏失衡」、把 mitigation 抽象成「authentication」——對熟手 OK、對學習者讀完會以為「用 authentication 就擋節奏失衡」、實作時不會去問 authentication 的局部 scope（防 credential 弱、不防 session 重放、不防 supply chain 信任傳導）。

理想做法

每個 mitigation 句子強制走「對稱論述」結構：

對稱論述模板

1[Mitigation X] 防 [in-scope threat A]、
2不防 [out-of-scope threat B]（[B 的補強路由 / 外部引用]）。

三個欄位都要填：

• In-scope threat：X 真正擋的攻擊類型（具體、不抽象）
• Out-of-scope threat：讀者最容易誤以為 X 也擋的攻擊（讀者直覺會 extrapolate 的方向）
• 補強路由：Y 該由什麼補（其他章節 / 外部標準 / 已知條件）、不能只丟「自己想辦法」

例（HTTPS 章節）：

1HTTPS 防中間人「讀取」傳輸內容（passive eavesdrop）、
2不防 endpoint 「身分驗證」失效（compromised CA / cert pinning bypass）、
3endpoint 信任靠 cert pinning + CT log monitoring 補（見 7.5）。

例（per-IP rate limit）：

1per-IP rate limit 擋「單來源」連續嘗試（brute force from single host）、
2不擋「分散來源」嘗試（botnet / credential stuffing）、
3分散攻擊靠 reputation-based filtering + adaptive challenge 補（見 7.3）。

對稱不是「補負面」、是「scope 顯式化」

跟 #94 正向改寫保留對照論據 同骨：「不防 Y」不是負向陳述、是 mitigation 的 scope qualifier。把 contrast 寫進句子、不是違反「正向陳述優先」、是讓主句的 X claim 站得住。

主句仍然承載 X 的 mitigation claim（正向）、不防 Y 是 scope qualifier、不是論述主體——結構符合「正向陳述優先」、語意保留 boundary。

Threat model 的層級對應

對稱論述要在三個層級保持一致：

三個層級任一缺、reader 都可能 silent universal 詮釋。實作 audit 時三層分別檢查、不是只看句子。

沒這樣做的麻煩

Reader 用 universal 詮釋、實作覆蓋永遠是 worst case

人類讀句子時、預設的 scope 是 universal、不是 minimal——這是語言學跟認知偏差的結合。「使用 X 防 Y」讀者預設 X 防整個 Y space。要讓讀者預設 minimal、必須顯式給 boundary——這跟物件的 type narrowing 同骨：沒寫 narrowing predicate、預設 widest type。

跟 #100 false sense of security 主軸對應——universal 詮釋是 false sense 的主要產地。

Reviewer 跟原作者對 mitigation 的 scope 認知會 silent drift

含糊 threat model 的 mitigation 段、不同 reviewer 讀會 reconstruct 出不同的 in-scope 集合。原作者腦中是 [A, B]、reviewer 讀成 [A, B, C, D]、實作者實作為 [A, B, C, D, E]——三個人對同一段話的覆蓋認知都不同、且都覺得自己對。對稱寫法讓 scope 變成 fact、不是 reconstruction。

多 mitigation 疊加時的 gap 永遠看不到

多個 mitigation 各自寫 in-scope、不寫 out-of-scope、疊加時的 gap（哪個 threat 沒人擋）就看不到。對稱寫法讓每個 mitigation 都有顯式 boundary、疊加 audit 時可以做集合運算（聯集 in-scope 應涵蓋 threat space、否則有 gap）。沒對稱寫法、audit 工具只能憑感覺、無法量化覆蓋。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：所有資安 mitigation 論述（auth / crypto / 傳輸 / 防護 / 標準引用）；高風險領域的「方法論述」（concurrency primitive 的 ordering 保證、distributed consensus 的 failure mode）
• 不適用：純歷史 / 概念介紹文章（不教 mitigation、不需 threat model）、研究探討（讀者預期自行 explore boundary）
• 邊界：「對稱論述」≠「列出所有不防的 threat」——只列讀者直覺會 extrapolate 的方向、不是 enumerate 整個 threat space。判別準則：「讀者讀完 X 防 A 之後、心裡最可能誤以為 X 也防的 B 是什麼？」——B 就是該寫的 out-of-scope
• 過度對稱反例：每個 mitigation 列十個 out-of-scope threat、文體變 audit-driven（為了 audit checklist 而寫）、不是 reader-driven（為讓讀者建立可驗證 mental model 而寫）；單一 mitigation 的 out-of-scope 通常 1-2 個直覺 extrapolation 方向就夠、列 10 個 = 把 audit 模板當成寫作目標、退化成 #67 寫作便利度反向

本卡是資安 audit 第一個維度（threat model）、配 #102 mitigation 對位、#103 context-dependence、#104 citation 形成完整的 audit dimension 集合。

資安 mitigation 對讀者有意義的不是「mitigation 存在」、是「mitigation 跟 threat 的對應鏈成立」。 對應鏈拆三段——設計上 mitigation X 攔 threat Y + 攔的 mechanism 是 Z + Z 失效時的訊號是 W——任一段空、mitigation 在實作端就會跟 threat 錯位、變成「看似在防、實際只擋表面 artifact」的 defense theater。

三段都齊、reader 才能反向驗證實作有沒有達到設計強度。

情境

資安章節常見的論述形態：給 mitigation 名稱（rate limit、CSRF token、prepared statement）+ 對應 threat 名稱（brute force、CSRF、SQLi）。表面對位、底層 mechanism 沒交代。讀者讀「prepared statement 防 SQLi」、實作時用 string concat + escape function、心裡覺得「我擋 SQLi 了」——因為原文只給 mitigation/threat 對應、沒給 mechanism（parameterization 跟 escape 是兩種不同 mechanism、抗的攻擊面不同）。

實際 case 的失效模式有三類：

失效模式 1：Mitigation 攔表面 artifact、不是攻擊 mechanism

1論述：rate limit 擋 brute force
2讀者實作：per-IP rate limit
3攻擊 mechanism：分散來源（botnet）每個 IP 低頻率、整體高頻率
4結果：mitigation 攔到的是「單 IP 高頻」表面、不是「身分嘗試」mechanism

對位該寫的是「rate limit 攔『單來源高頻嘗試』、不攔『身分嘗試』本身」——mechanism level 的對位、不是名稱對位。

失效模式 2：Mitigation 跟 threat 在不同抽象層

1論述：CSP 擋 XSS
2讀者實作：CSP header 設 default-src 'self'
3Threat 抽象層：XSS 是 injection class、有 reflected / stored / DOM 三類
4Mitigation 抽象層：CSP 是 browser-side execution policy
5結果：CSP 擋「未授權 script 執行」、不擋 stored XSS 在 DB 已 persist 的階段

對位該寫 mitigation 在抽象層的位置——CSP 在 browser 執行層、不在 input 處理層。讀者光看「CSP 擋 XSS」會以為 input sanitization 不必做。

失效模式 3：Mitigation 假設上層 threat 已擋

1論述：bcrypt 防 password DB 外洩後 brute force 還原
2讀者實作：bcrypt 存 password
3被忽略的 threat：DB 外洩前 - phishing / credential stuffing / weak password
4結果：bcrypt 是「外洩後」的 last line、不是 password security 的 first line

對位該寫 mitigation 在 defense-in-depth 的層次跟前提——bcrypt 在「假設 DB 外洩」的條件下成立、不擋外洩前的 threat。讀者沒拿到前提、會以為 bcrypt 是 password security 的 sufficient solution。

理想做法

每個 mitigation 段落補三欄對位：

三欄對位模板

1[Mitigation X]
2- 攔的 threat：[具體攻擊行為、不是攻擊類別名稱]
3- 攔的 mechanism：[X 在什麼層擋 / 擋的是 mechanism 的哪一步]
4- 失效訊號：[reader 能觀察到 mitigation 有沒有發揮的具體現象]

例（per-IP rate limit）：

1per-IP rate limit
2- 攔的 threat：單來源連續嘗試（同 IP 短時間多次 login）
3- 攔的 mechanism：在 single-source 維度限制 attempt rate、攻擊者必須切 IP 才能繞
4- 失效訊號：分散來源（多 IP 各自低頻）的 aggregate 嘗試率、per-IP rate limit metric 不會 trigger

例（bcrypt password hashing）：

1bcrypt
2- 攔的 threat：DB 外洩後 password 被離線 brute force 還原
3- 攔的 mechanism：work factor 控制 hash 計算成本、攻擊者每次嘗試的成本不可優化
4- 失效訊號：weak password / 已知 password 在 dictionary 中、攻擊者不需 brute force 全 space
5- 前提：上層擋住 phishing / credential stuffing、bcrypt 是 last line、不是 first line

對位的層次規則

對位驗證要在三個層次都對齊：

只到名稱層 = defense theater；到 mechanism 層 = 可實作驗證；到前提層 = 可疊加 defense-in-depth audit。

對位 audit 的工具方法

對 mitigation 群組做集合運算：

11. 列章節所有 mitigation 跟對應 threat
22. 對每對 (mitigation, threat) 補 mechanism + 前提
33. 集合化：聯集所有 mitigation 攔的 mechanism、聯集所有 threat 的 mechanism
44. 找 gap：threat 集合裡沒被 mitigation 集合涵蓋的 mechanism
55. Gap 處理：補 mitigation / 標 out-of-scope（[#101](../threat-model-explicitness/)）/ 升級到 defense-in-depth 上層

集合運算讓對位錯誤跟覆蓋 gap 從「靠感覺」升級到「可量化」。

沒這樣做的麻煩

Defense theater 在 audit 跟 implementation 都通過、生產系統有破口

只到名稱層對位的 mitigation、audit 工具看到「rate limit 已部署」會 pass、implementation 看到「CSRF token 已加」會 pass、threat 還在——攻擊者用 mechanism 變體（分散來源 / DOM XSS / stored injection）繞過、mitigation 集體 silent 失效。對位錯誤的 mitigation 跟沒 mitigation 在攻擊者眼中等價、但對 audit / 對讀者不等價——這個 gap 是 defense theater 的本質。

跟 #82 字面攔截 vs 行為精煉 同骨：mitigation 名稱對位是字面層、mechanism 對位是行為層、前提對位是 contextual 行為層。stop at 字面層 = false confidence。

Mitigation 變體跟 threat 變體無法 trace

新 threat 出現（如 credential stuffing 之於傳統 brute force）、reader 必須重新評估既有 mitigation 是否還對位。對位鏈寫到 mechanism + 前提的 mitigation 可被 trace（per-IP rate limit 的 mechanism 是 single-source 限制、credential stuffing 是分散來源、不對位、需新 mitigation）；只到名稱層的 mitigation 不可 trace（rate limit vs credential stuffing：名稱看起來「應該擋」、實際不擋）。寫作時的 mechanism / 前提投資、是給未來 threat evolution 留的 review 入口。

Mitigation 疊加時的責任邊界含糊

多個 mitigation 共防一個 threat、若各自不寫 mechanism + 前提、疊加時無法判斷「誰負責什麼層」。修補某個 mitigation 時不知道會不會影響其他 mitigation 的前提、變更冒險成本上升。明示 mechanism + 前提 = 明示 mitigation 之間的 dependency、修補成本可控。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安 mitigation 設計（auth / crypto / 防護 / 標準 control）的論述；任何「方法 → 問題」對應的高 stakes 領域（concurrency primitive 對 race 類別 / consensus 演算法對 failure mode / financial control 對 risk 類別）
• 不適用：純概念 / 歷史介紹（不教 mitigation）、研究探討（讀者預期自行 explore mechanism）
• 邊界：「對位驗證」≠「列出每個攻擊變體」——mechanism 層列到攻擊行為的根 mechanism 即可、不必列所有 surface 變體；判別準則是「reader 能不能用這個 mechanism 描述去判斷新變體攻擊是否在 mitigation 覆蓋內」
• 過度對位反例：每個 mitigation 寫 mechanism + 前提 + 三層 scope qualifier + 五種失效訊號、文章變 audit checklist、不是教學；mitigation 對位的投資量級對應 mitigation 在系統的責任比重——核心 mitigation（auth / crypto primitive）值得三層完整對位、輔助 mitigation（log redaction / banner notice）只到 mechanism 層即可

本卡是資安 audit 第二個維度（mitigation 對位）、配 #101 threat model 明確性、後續 #103 context-dependence、#104 citation 形成完整 audit dimension 集合。

資安 mitigation 的有效性不是 mitigation 本身決定的、是 mitigation × deployment 條件決定的。 同一個 mitigation 在不同 deployment / config / scale / runtime 條件下、強度光譜從「完整擋」到「等同沒部署」都可能。寫作時忽略 deployment 變數、讀者實作時用最直覺條件詮釋、實際部署條件不對 mitigation silent 失效。

差別在於：reader 在實作 review 階段有沒有 context 變數可檢查。

情境

資安 mitigation 在文獻 / 標準 / 教學裡常被描述成「方法 → 防什麼 threat」對應、跳過 deployment 條件這個變數。讀者讀完套到自己 deployment 上、條件可能不一致。常見的 context dimension 有四類：

Context 維度 1：Config 完整性

Mitigation 通常需要多個 config 同時成立才有效、單一 config 不夠：

1HTTPS 防中間人：成立條件 = TLS + HSTS + cert pinning（針對重要 endpoint）+ CT log monitoring
2                失效條件 = 只有 TLS、沒 HSTS → 第一次連線可被 downgrade
3                          沒 cert pinning → 受信任 CA 簽出假 cert 可繞過
4JWT 驗身分：    成立條件 = 簽章驗證 + 短 TTL + rotation + 安全儲存（HttpOnly cookie 或 secure storage）
5                失效條件 = 簽章對但 TTL 太長 → token 被竊後長期可用
6                          XSS 可讀取 → 簽章保護被繞過
7                          沒 rotation → 一次外洩永久暴露

寫「使用 HTTPS」「使用 JWT」是把 mitigation 縮成單一 control name、reader 預設 default config、實際要 5-7 個 config 同時對才完整。

Context 維度 2：Scale / 多實例

某些 mitigation 在單機 OK、多實例失效：

1Rate limit： 單實例 = local counter、per-IP rate 控管準確
2            多實例 = 每實例各自 count、攻擊者打不同實例可繞過 N 倍上限
3            修法 = 用 distributed counter（Redis / 共享 store）
4Session 失效：單實例 = local session store、invalidate 即時
5            多實例 = invalidate 訊號需 broadcast、舊 token 在其他實例還可用
6            修法 = 用 stateless token + revocation list 或 共享 session store

Reader 看到「rate limit 防 brute force」、實作時若不知道 deployment scale、單實例 OK / 多實例 silent 失效。

Context 維度 3：Runtime 環境

執行環境差異改變 mitigation 適用性：

1Cookie SameSite=Strict 防 CSRF：
2  瀏覽器環境 = 有效（瀏覽器強制執行）
3  Native app webview = 部分有效（依 webview 實作）
4  Mobile in-app browser = 不一定有效（看實作）
5  Server-to-server = 不適用（無 cookie / 無 SameSite 概念）
6CSP 防 XSS：
7  Modern browser = 有效
8  舊瀏覽器（IE / 非 evergreen）= partial 或無效
9  非 browser execution（Electron / native webview）= 看 implementation

Context 維度 4：Threat actor 能力

Mitigation 的 work factor 跟 threat actor 計算能力對應：

1bcrypt（work factor = 10）：
2  個人攻擊者 = 強保護
3  Nation-state（GPU farm / FPGA）= 弱保護、需提高 work factor 或換 argon2
4PBKDF2（100k iterations）：
5  2010 年 = 強
6  2026 年 = 弱（建議升級到 600k+ 或 argon2）

Threat actor 能力是 deployment 隨時間變化的變數、寫作時固定描述很快過時。

理想做法

每個 mitigation 段落明示三類條件：

三類條件模板

1[Mitigation X]
2- 成立條件：[X 發揮設計強度需要的 config / scale / runtime / 其他 control 配套]
3- 失效條件：[條件不對時 X 變成 etc 等同沒部署的具體情境]
4- Deployment 變數：[實作時要檢查的 dimension list]

例（rate limit 防 brute force）：

1per-IP rate limit
2- 成立條件：單實例部署 OR 多實例 + distributed counter（Redis / 共享 store）
3- 失效條件：多實例 + local counter、攻擊者輪流打不同實例繞過上限
4- Deployment 變數：實例數量、counter 部署位置（local / shared）、IP 來源真實性（NAT / proxy 後是否還能 distinguish）

例（HTTPS 防中間人）：

1HTTPS
2- 成立條件：TLS + HSTS（避免首連線 downgrade）+ 受信 CA chain + 在重要 endpoint 配 cert pinning
3- 失效條件：沒 HSTS → 首次連線 downgrade；CA 被攻陷 → 假 cert 可繞；no cert pinning + state-level CA 攻陷 → silent MITM
4- Deployment 變數：HSTS preload / max-age 設定、cert pinning 範圍（哪些 endpoint）、CA list 是否最小化、CT log monitoring 是否到位

Context 描述的層次規則

每個 mitigation 描述至少要有 deployment baseline 跟 stretch case：

baseline 給 reader 入門條件、stretch 給 reader 升級判準、trigger 讓升級成 actionable signal。

跟「規模改變可行性」的同骨

跟 #89 Dataset 規模改變什麼可行 同骨——#89 在 dataset / index / cache 維度、本卡在 mitigation / config / scale 維度：

1#89:    < 1MB 無腦處理 → 1-10MB O(N) 可行 → > 100MB 強制 index
2本卡：   單實例 local rate limit OK → 多實例需 distributed counter → 高 scale 需 token bucket + adaptive

「在 X 規模 / 條件下 Y 方法 OK」這個結構在資料處理跟資安都成立、是 deployment 變數驅動的工程光譜。

沒這樣做的麻煩

「正常條件下有效」silent 變成生產破口

讀者讀「使用 X 防 Y」、用自己 deployment 的 default config 實作、跑開發測試 OK、ship 進生產。生產可能是多實例 / 高 scale / 異常 runtime、X 在那條件下不成立、threat 進入。Mitigation 在開發環境 silent 失效、生產環境 silent 失效——兩階段都沒訊號、直到事件。

跟 #100 false sense of security 同病：context 沒寫、reader 用最直覺條件詮釋、condition mismatch 不會被 catch。

Mitigation 升級的時機不可 trace

威脅環境變化（actor 計算能力 / 攻擊變體 / scale 增長）需要 mitigation 跟著升級。Context 寫清楚的 mitigation 可 trace（bcrypt work factor 跟 actor 能力對應、定期 review）；context 含糊的 mitigation 不可 trace（「使用 bcrypt」變成 frozen「最佳實踐」、實際強度跟著時間 decay）。

跨環境 deployment 的 mitigation 假設衝突

同一份教學 / spec 套到不同 deployment（dev / staging / prod / 多區域 / 不同租戶）、若 context 沒寫、各 deployment 的 mitigation 強度差異被 silent。Audit 跨 deployment 時無法判定哪個強度最弱、整個系統的 baseline 取決於最弱 deployment、但沒人知道哪個是最弱。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安 mitigation 的所有論述（auth / crypto / 傳輸 / 防護 / scale-sensitive control）；任何「方法有效性受部署條件影響」的領域（concurrency primitive 在不同 memory model / DB transaction 在不同 isolation level / consensus 演算法在不同 network partition 假設）
• 不適用：純歷史 / 概念介紹（不教 mitigation deployment）、研究探討（讀者預期自行 explore condition）
• 邊界：「Context-dependence 顯式」≠「窮舉所有 deployment 排列組合」——只列 reader 直覺會誤判的 dimension（最常見 deployment 跟最常見變體）、不必涵蓋整個 deployment space；判別準則：「reader 用 default 條件詮釋會不會 silent 失效」——會 → 補 context、不會 → 不必補
• 過度條件化反例：每個 mitigation 列 deployment matrix（10 個 dimension × 5 個值 = 50 個 case）、文章變 deployment guide、不是教學；條件描述的投資量級對應 mitigation 在系統的責任比重——核心 control（auth / crypto）值得三類條件完整、輔助 control 只列 baseline + 一個 stretch case 即可

本卡是資安 audit 第三個維度（context-dependence）、配 #101 threat model + #102 對位、後續 #104 citation 形成完整 audit dimension 集合。

資安標準引用不是「這條 control 寫在 X 文件」、是「這條 control 在 X 版本 X 年份 X 語境下對 X actor 模型成立」。 五個變數任一變、引用就過時或扭曲。資安 best practice 衰退快、universal-flavored 引用（「OWASP 建議 X」「RFC 規定 Y」）會 silent 把過時或語境外的內容傳給 reader、產生 #100 false sense of security 的 citation 維度產地。

差別在 reader 在實作 review 階段有沒有版本變數可檢查、有沒有原文語境可驗證。

情境

資安標準群（OWASP / RFC / NIST SP 800 系列 / CIS Benchmark / PCI DSS / ISO 27001）有三個跟一般技術文獻不同的特性：

特性 1：Best practice 衰退速度快

加密 / hashing 領域是最典型例子：

11995-2005：MD5 是 password hashing 常見選擇
22005-2010：MD5 deprecated、改 SHA-1
32010-2015：SHA-1 弱、改 bcrypt
42015-2020：bcrypt 仍 OK、PBKDF2 100k iter 仍 OK
52020-2026：建議升 argon2id、PBKDF2 推 600k+、bcrypt work factor 推 12+

任何 2020 年寫的「使用 bcrypt 即可」教學在 2026 年仍部分成立、但 work factor 推薦值已 outdated。沒標年份的引用 reader 沒有 review trigger。

特性 2：原文常被引用扭曲

引用 chain 中常見的 drift：

1原文（OWASP Cheat Sheet）：In contexts where session fixation is a concern, consider regenerating the session ID upon login.
2中介轉述：OWASP says regenerate session ID upon login.
3進一步引用：OWASP requires session regeneration on every login.
4最終讀者：「OWASP 強制要求每次 login 都 regenerate session」

語意從「conditional 建議」滑成「universal 強制」、原文的 conditional context（「session fixation is a concern」）被丟。Reader 套用時把 conditional 當 unconditional、可能在不需要的地方加複雜度、或在需要的地方因為「我已經做了」跳過 threat model 重新評估。

特性 3：版本之間語意可能反轉

OWASP Top 10 / NIST SP 800 系列、版本之間的 control 重點會大幅調整：

1OWASP Top 10:
2  2017 → A1 Injection / A7 XSS
3  2021 → A03 Injection（含 XSS、合併）/ A08 Software and Data Integrity Failures（新類別）
4NIST SP 800-63B:
5  2014 版：強制 password 定期更換
6  2017 版：明示**不要**強制定期更換、除非有外洩證據

引用「NIST 建議定期更換 password」在 2014 對、2017 後是反向違反 NIST。版本不標 = reader 可能引用到反向版本。

特性 4：Internal citation 也是 citation

問題節點 / problem-node 框架的章節常用內部連結（[authentication] [session-invalidation] 等 knowledge-cards）作為「control-of-record」，把實作細節下放到子頁。這些內部連結等同 citation——指向「這個 control 由那一頁定義」、章節讀者在這層形成判斷、再決定是否點進去。

Internal citation 同樣有四個失效模式：

外部 citation 至少有版本號當 anchor、internal citation 連版本概念都沒有——更易 silent drift。所以 audit 跟 review trigger 對 internal 反而更嚴格。

理想做法

每個 security citation 加四個欄位：

四欄位引用模板

1[Citation X]
2- 標準 / 文件：[全名 + 版本 + 年份]
3- 原文 / quote：[原文一句、不轉述]
4- 引用 scope：[原文適用的 context / actor model / 前提條件]
5- Review trigger：[何時要 re-check 標準是否有新版]

例（password hashing）：

1- 標準：OWASP Password Storage Cheat Sheet（2024 update）
2- 原文：「Use Argon2id with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism」
3- Scope：Web 應用 password hashing、針對個人 / 組織 actor、不適用 nation-state actor 或 high-throughput verification
4- Review trigger：每 12 月 re-check OWASP cheat sheet 是否有新建議；GPU 算力翻倍時提前 re-check

例（session 管理）：

1- 標準：OWASP Session Management Cheat Sheet（2024 update）
2- 原文：「Session ID should be regenerated after any privilege level change (e.g., after a successful authentication or after a session token has elevated privileges)」
3- Scope：Web session ID rotation、conditional 在 privilege level change 時、不是「每次 request」也不是「每次 login」（對 already-authenticated session）
4- Review trigger：當 application 加入新的 privilege boundary（如 admin elevation）時 re-check

引用扭曲的 audit 流程

對章節既有引用跑驗證 pass：

11. 列出所有 citation（外部：標準 / RFC / CVE；內部：knowledge-cards 連結 / 跨章引用）
22. 對每條 citation 找一手來源、記錄 URL + 版本 + 年份（外部）/ 最後修改 + slug（內部）
33. 對比文中轉述跟原文 / 子頁定義、check 三類 drift：
4   - Conditional → unconditional drift（原文有條件、文中沒條件）
5   - Specific → general drift（原文限特定 context、文中講通用）
6   - Recommendation → mandate drift（原文是 consider / recommend、文中是 must / required）
74. drift 找到、補回原文 conditional / scope / language strength
85. 標版本跟 review trigger（外部）/ 標 last-checked + sync owner（內部）
96. 內部專屬 check：連結是否 broken（slug 改了 / 檔案移了）、子頁是否仍存在 / 仍 in scope

集合運算讓引用扭曲從「靠記憶」升級到「可驗證」。Internal citation 多兩個專屬步驟（broken link + slug drift）、跟 #93 URL slug 必須顯式定義為 fact 同骨——identifier 跨工具 / 跨檔案沒 fact 化、就會 silent broken。

Review trigger 的 cadence 設計

不同類型 citation 的 review cadence 不同：

跟 #91 升級 trigger 的量化設計 同骨——「之後再 review」不是 trigger、有 cadence + owner + threshold 才是 trigger。

沒這樣做的麻煩

過時 citation silent 變成過時實作

reader 信任引用、用 citation 內容實作、citation 過時後實作不知道、新 best practice 沒被採用。Crypto 領域最常見：MD5 / SHA-1 / 弱 PBKDF2 iteration / 過時 cipher suite 在生產系統留存幾十年的案例不少、原因常常是「教學 / spec 沒更新、實作跟著沒更新」。

跟 #100 false sense of security 同病、citation 維度的具體展現：reader 以為「我用了標準推薦」就安全、實際標準早改、自己用的是 deprecated 版本。

扭曲 citation 把 conditional 變強制 / 把 specific 變通用

引用扭曲的後果有兩面：

• Conditional → unconditional：reader 在不需要的地方加複雜度、團隊成本上升、卻不解決真 threat
• Specific → general：reader 把特定 context 的 control 套到不同 context、可能 silent 失效

兩面都讓 mitigation 跟 threat 對位錯誤（#102 mitigation-threat-alignment）。

引用 chain 越長、扭曲累積越嚴重

教學 → 教學 → 教學 的 chain 中、每一層轉述都可能 drift。citation 沒回到一手原文、整條 chain 共享同一個扭曲、攻擊者繞過扭曲版的 mitigation 一次、所有採用該 chain 的 implementation 都中。citation 的時效跟精確不是個別文章問題、是 ecosystem 問題——一手原文 + 版本 + 原文 quote 是 minimum cost 的修法。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安內容引用標準（auth / crypto / 傳輸 / 防護 / 合規）；內部 citation（knowledge-cards 連結、跨章 / 跨模組引用作為 control-of-record）；任何 best practice 衰退快、版本之間語意會反轉的領域（cloud security 配置、container 安全、特定 framework 的安全 idiom）
• 不適用：純歷史 / 概念介紹（不依賴 current best practice）、學術 retrospective（討論 historical 標準時版本本身是內容）
• 邊界：「citation 時效跟精確」≠「窮舉所有版本變更」——只列當前文章涵蓋 scope 的 citation、追到一手 + 版本 + scope qualifier 即可；判別準則：「如果這條 citation 過時或語境變、reader 會做錯什麼？」——會做錯 → 補完整四欄位；不會做錯（純歷史 reference）→ 標年份即可
• 過度引用反例：每段話都附 citation 鏈 + 原文 quote + 三條 review trigger、文章變 footnote-driven、reader 讀不下去；citation 投資量級對應該段對 reader 實作的影響——核心 mitigation 段值得四欄位完整、background 段標版本 + URL 即可

本卡是資安 audit 第四個維度（citation）、配 #101 / #102 / #103 形成完整 audit dimension 集合（threat / mitigation / context / citation）。後續 #105 audit recommendation 層級 把四維度的 weakness 統合成 recommendation 決策。

資安 audit 的 recommendation 是 ship 決策、不是評語。 把每個 weakness trace 到具體 tier、輸出可被 build process / publish gate 引用——不該停在「這裡可改善」的軟性建議。四個 tier 是 monotonic decision shape：

第四層是資安 audit 跟一般學術 peer review 的關鍵差異——學術 reject 會給投稿者改寫機會、本 audit 的 withdraw 是「保留 = 增加生產系統 risk」的硬決策。跟 #76 incremental shipping criteria 反向：可逆內容可分批 ship 改善、不可逆 risk 內容不能。

情境

audit 報告若只給「找到 N 個問題」的 flat list、團隊收到後無法決策、最後常變成「慢慢改」、article ship 跟 audit 改善的 timeline 完全脫鉤。Tier 化的 recommendation 把 weakness 轉成決策訊號：

 1Flat list（沒層級）：
 2- 第 3 段沒寫 threat model boundary
 3- 第 5 段 mitigation 沒寫 mechanism
 4- 第 7 段引用 OWASP 沒標版本
 5- 第 9 段 bcrypt work factor = 10、針對 nation-state 弱
 6
 7決策結果：「都有問題、找時間改」、實際上幾個月不會動
 8
 9Tiered（分層）：
10- Withdraw: 第 9 段 bcrypt work factor 描述會直接讓 reader 用 weak setting、必須改寫或移除
11- Major revise: 第 5 段 defense theater、整段重寫 mechanism + 前提
12- Minor revise: 第 3 段補 threat model 對稱、第 7 段補 OWASP 版本
13
14決策結果：第 9 段必須現在改、第 5 段下個 sprint 改、第 3/7 段順手補

層級給的是「先做什麼 / 什麼擋 ship / 什麼可緩」的明確排序、不是改善優先序的軟建議。

理想做法

四 tier 判準

每個 weakness 套這個決策樹：

 1Q1：reader 照這段實作會不會主動產生破口？
 2  是 → Withdraw（不可保留）
 3  否 → Q2
 4
 5Q2：weakness 是結構性（多 dimension 同時失效）還是局部（單一 dimension 缺）？
 6  結構性 → Major revise
 7  局部 → Q3
 8
 9Q3：補完 weakness 的 cost 是「補一句 / 一表」還是「重寫一段」？
10  一句 / 一表 → Minor revise
11  重寫一段 → Major revise
12
13Q4：weakness 在容忍範圍（背景段 / 低 stakes 段、reader 不會直接照做）？
14  在 → Accept（可選 minor 但不要求）
15  不在 → 走 Q3

各 tier 的 fix 模式

Withdraw 的具體訊號

什麼狀態算 withdraw？四個訊號：

1. 過時 crypto / hashing primitive 沒 deprecation 標記：教 MD5 / SHA-1 / 弱 PBKDF2 但沒明示「這是過時、不要用」
2. 扭曲 citation 改變原文語意：把 OWASP conditional 引成 unconditional、或反向違反現行標準（NIST 的 password 定期更換 case）
3. 違反 current best practice 的步驟說明：教讀者主動關閉 mitigation（disable HSTS / CSP / SameSite）作為 workaround、沒明示「workaround 引入的新 risk」
4. Defense theater 例子當示範：用名稱層 mitigation 對位（rate limit「擋」brute force）作為步驟、reader 照做不擋實際 mechanism

四訊號的共通：reader 照做後實作會主動 worse than not having read。Withdraw 不是嚴格、是 risk-asymmetric（#99）下的必要決策。

Audit report 輸出格式

學術 peer review 的格式對應到本 audit：

 1# Audit Report: <章節 / 文章 title>
 2
 3## Summary
 4<1-2 句：主要 audit 結論 + 整體 tier>
 5
 6## Strengths
 7- <段 / dimension 跟其優點>
 8
 9## Weaknesses by dimension
10
11### Threat model（[#101](../threat-model-explicitness/)）
12- [Tier]: 段 N、[具體 weakness 描述]、[fix 建議]
13
14### Mitigation 對位（[#102](../mitigation-threat-alignment/)）
15- ...
16
17### Context-dependence（[#103](../mitigation-context-dependence/)）
18- ...
19
20### Citation（[#104](../security-citation-currency-and-precision/)）
21- ...
22
23## Blocking conditions
24<必須 fix 才能 ship 的 weakness 清單、按 tier 排序>
25
26## Recommendation
27<Accept / Minor revise / Major revise / Withdraw + 整體決策說明>

格式跟學術 peer review 同骨、欄位對應 audit dimension（#101-104）、輸出可直接餵 ship gate 工具。

沒這樣做的麻煩

Audit 變評語、改善 timeline 跟 ship 完全脫鉤

flat list 的 audit 給「找到問題」、team 把問題列入 backlog、backlog 永遠排不到上面（#72 高 ROI 無外部觸發會被結構性跳過）。tier 化讓 audit 從「評語」變「ship 決策 input」、跟 timeline 強耦合。

Withdraw-level 內容繼續 ship、生產系統 risk 持續累積

最危險的 case 是 audit 找到 withdraw-level weakness（過時 crypto、扭曲 citation）但用 minor / major 處置——讓內容繼續存在並擴散。教學擴散 = silent gap 集體放大（#100 false sense of security），withdraw 是 cut-off 訊號、不是嚴格、是必要。

各 tier 之間的決策邏輯模糊、reviewer 之間判準不一致

沒明確 tier 判準、不同 reviewer 對同一個 weakness 給不同建議——有人覺得「補一行就好」（minor）、有人覺得「整段重寫」（major）、有人覺得「移除」（withdraw）。決策不一致 = audit 失去結構性 value、退化成個人意見集合。tier 判準（決策樹四問題）讓判準可重現、跨 reviewer 收斂。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安內容 audit 的產出格式（章節 audit / 文章 audit / 跨章節 review）；任何「reader 照做後錯誤不可逆」的高 stakes 領域 audit（concurrency 正確性、distributed consistency、financial / medical 計算）
• 不適用：一般技術內容 audit（不需要 withdraw tier、accept / minor / major 三層即可）、研究探討文章的 review（學術 reject 跟 withdraw 語意不同）
• 邊界：「Withdraw」≠「全文重寫」——可以是「移除有問題的段 + 加 deprecation 標 + redirect 到 current best practice 段」、不必整篇重做；判別準則：「reader 看到這個處置版本後、會不會用過時 / 扭曲版本實作？」——不會 → withdraw 處置 OK、會 → 需要更深的處置（移除整段 / 整篇）
• 過度 tier 化反例：把每個段都評 tier、文章變評分表、reviewer 投資爆炸；tier 投資量級對應內容對 reader 實作的影響——核心 mitigation 段需 tier、background 段直接 accept 即可

本卡是資安 audit 系列（#99-105）的決策面收尾、把 #101-104 四個 dimension 的 weakness 統合成 ship 決策。後續對應的 skill reference（auditing-articles.md）會以本卡的 tier + report 格式為輸出模板。