資安教學的審查標準要對應風險不對稱
核心原則
資安教學內容的 audit 標準不該由「讀者讀不讀得懂」決定、該由「讀者照做後系統會不會出破口」決定。 讀懂是學習端的成本、破口是生產端的代價、兩者級數不同。
| 教學類型 | 寫不清楚的代價 | 代價發生位置 | 可逆性 |
|---|---|---|---|
| 一般工程教學（layout / refactor / debug） | 讀者學不會、要重學 | 學習端 | 可逆（再學一次） |
| 資安教學（auth / crypto / 防護 / 標準引用） | 讀者以為學會、實作時留破口 | 生產端 | 不可逆（破口被利用） |
級數不對稱的後果：一般教學的 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
- Threat model 對稱性：講「防 X」必須寫「不防 Y」、形成對稱論述（見 #101 threat-model-explicitness）
- Mitigation 對位驗證：防護措施跟 threat 的對應鏈要可驗證、不能只是「業界常用」（見 #102 mitigation-threat-alignment）
- Context-dependence 顯式化：mitigation 在不同 deployment 的有效性差異要寫出來、不假設讀者知道（見 #103 mitigation-context-dependence）
寫作流程的差異
| 階段 | 一般教學 | 資安教學 |
|---|---|---|
| 草稿 | 寫得通、有 reasoning | + 列 threat model 範圍 + 列「不在範圍內的 threat」 |
| Review | 多 pass review（#83） | + audit pass（reviewer 視角找 false sense of security） |
| 引用 | 引用即可 | + 標版本 + 驗證引用句意沒被扭曲 + 確認當前版本仍是 best practice |
| 完稿 | 讀者讀完能套用 | + 讀者實作後的正確性可被反向驗證 |
沒這樣做的麻煩
False confidence 在生產系統累積
讀者讀完含糊論述、心理上覺得「學到防護方法了」、實作時用最直覺的詮釋。當實作有 gap 時、讀者不會警覺——因為「我學過了 / 我做了」。等同 #82 字面攔截 vs 行為精煉 在資安領域的具體展現：教學含糊 = hook 規則太粗、看似有保護、實際抓不到行為層的破口。
最危險的是：含糊的資安教學比沒讀過更糟。沒讀過的人會去查標準、會問人；讀過含糊版的人會跳過驗證、直接 implement。
破口的可利用窗口跟教學擴散同步放大
含糊的資安內容若被多個團隊 / 文章引用、所有下游 implementer 都繼承同一個 silent gap。攻擊者只要找到原始教學的 misinterpretation pattern、就可以批量利用所有 implementation。一般教學的錯誤是 個別讀者的學習成本、資安教學的錯誤是 系統性風險面擴大。
後續修補無法 trace 到原文
當下游事故發生、回溯到「讀者照某教學實作」時、含糊的原文難以判定是「教學錯」還是「讀者誤解」——因為含糊本身就是 ambiguity 來源。理想的資安教學應該讓「實作 vs 教學」可以被 1:1 對照、出問題時找得到 root cause。
跟其他抽象層原則的關係
| 原則 | 關係 |
|---|---|
| #82 字面攔截 vs 行為精煉 | 本卡是 #82 在資安寫作的領域具體化 — false confidence 透過含糊教學在實作端展現、是 #82 ceiling pattern 的高風險版本 |
| #92 視覺手段對齊錯誤層次 | 層次錯位 sibling — #92 是「呈現工具 vs 內容層次」、本卡是「審查標準 vs 內容風險」、同骨不同維度 |
| #67 寫作便利度跟意圖對齊反相關 | 資安寫作最便利（通用敘述 / 省略邊界 / 不標版本）跟意圖對齊（精確 threat / boundary / 標準）反向、本卡是 #67 在資安領域的具體展現 |
| #76 分批 ship | 反面對照 — #76 的三軸切分（可見性 / 風險 / 驗證）適合可逆內容；資安錯誤是不可逆 / 系統層、分批 ship 邏輯不適用、要在 ship 前就把 audit 跑完 |
| #80 Yes/No 二選 collapse | 「教 X 防護方法」單軸描述是把 threat model 多維度 collapse 成 1 維、跟 #80 同骨——資安教學預設要保留多維度（防什麼 / 不防什麼 / 在哪些 deployment 條件） |
| #90 L1+L2 訊號一致性 | Silent fallback 即 false confidence、本卡是同類議題在「教學跟實作」之間的一致性問題、訊號要對齊讀者實作端 |
判讀徵兆
| 徵兆 | 該做的事 |
|---|---|
| 章節用「能擋」「能防」「可以避免」、後面沒接 threat model 範圍 | 補對稱論述：寫「擋 X」也寫「不擋 Y」 |
| 引用 OWASP / RFC / NIST、沒標版本 / 年份 | 補版本標記 + 確認該版本仍是 current best practice |
| Mitigation 寫得通用、沒拆 deployment 條件 | 補 context-dependence、列 deployment 變數對 mitigation 有效性的影響 |
| 章節結束讀者會說「我學會 X 防護了」、但你不知道他實作會不會出錯 | Audit bar 還停在 readability、要升級到 verifiability |
| 「之後讀者實作有疑問再說」 | 是 #72 結構性跳過、補 audit trigger |
| 標題 / index hook 用通用詞（「資安最佳實踐」「防護方法」）、正文寫得精準 | Metadata surface 漏判（#97）、入口層的含糊會讓正文精準度被誤導 |
適用範圍與邊界
- 適用：資安內容（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、確立「為什麼資安寫作需要學術級審查標準」的論證基底。