匯出所有 security group 與規則

稽核的第一步是把當前所有 SG 和它們的規則拉出來存成可查詢的 JSON。這份 JSON 是後續所有分析的輸入，也是「稽核那天環境長什麼樣」的快照。

 1aws ec2 describe-security-groups \
 2  --query 'SecurityGroups[].{
 3    GroupId:GroupId,
 4    GroupName:GroupName,
 5    VpcId:VpcId,
 6    Description:Description,
 7    IngressRules:IpPermissions,
 8    EgressRules:IpPermissionsEgress,
 9    Tags:Tags
10  }' \
11  --output json > sg-inventory-$(date +%Y%m%d).json

這份檔案通常幾百 KB 到幾 MB，存進 repo 的 inventory/ 目錄，方便日後比對變化。如果帳號有多個 region，每個 region 各跑一次並標明 region。

用 jq 快速看有多少 SG 和總規則數：

1jq 'length' sg-inventory-*.json
2jq '[.[].IngressRules | length] | add' sg-inventory-*.json

找出 0.0.0.0/0 全開的入站規則

0.0.0.0/0 入站代表允許整個網際網路連到這個埠。對外 ALB 的 80/443 開 0.0.0.0/0 是設計意圖，但資料庫埠（5432、3306、6379）、SSH（22）或管理埠開 0.0.0.0/0 是需要收斂的目標。

1jq -r '.[] | select(.IngressRules[]?.IpRanges[]?.CidrIp == "0.0.0.0/0") |
2  {GroupId, GroupName, OpenPorts: [.IngressRules[] |
3    select(.IpRanges[]?.CidrIp == "0.0.0.0/0") |
4    "\(.FromPort // "all")-\(.ToPort // "all")/\(.IpProtocol)"
5  ]}' sg-inventory-*.json

輸出會列出每個有全開規則的 SG 和對應的 port 範圍。對每一條命中，判斷：

IPv6 的 ::/0 也要一併查：

1jq -r '.[] | select(.IngressRules[]?.Ipv6Ranges[]?.CidrIpv6 == "::/0") |
2  .GroupId' sg-inventory-*.json

找出未使用的 security group

未使用的 SG 是沒有任何網路介面（ENI）掛載的 SG。它不影響任何正在運行的資源，但佔用 SG 配額（每個 VPC 預設上限 2500 個），而且它的規則會讓稽核清單更長、更難判讀。

1aws ec2 describe-network-interfaces \
2  --query 'NetworkInterfaces[].Groups[].GroupId' \
3  --output text | tr '\t' '\n' | sort -u > sg-in-use.txt
4
5jq -r '.[].GroupId' sg-inventory-*.json | sort -u > sg-all.txt
6
7comm -23 sg-all.txt sg-in-use.txt > sg-unused.txt
8cat sg-unused.txt

sg-unused.txt 裡列出的就是當前沒有任何 ENI 引用的 SG。注意幾個例外：

• default SG：每個 VPC 都有一個 default SG，即使未使用也無法刪除，可以跳過
• 被其他 SG 引用：某個 SG 雖然沒有掛在任何 ENI 上，但被另一個 SG 的入站規則引用為 source — 刪除它會讓引用方的規則失效
• 被 launch template 或 auto-scaling group 引用：新啟動的實例會套用這個 SG，刪了之後新實例啟動會失敗

依賴檢查：刪除前確認沒有間接引用

直接刪一個 SG 之前，確認沒有其他資源引用它。AWS 在 SG 被引用時會擋住刪除（報 DependencyViolation），但提前知道引用方可以避免白跑一趟。

 1SG_ID="sg-0abc123"
 2
 3# 哪些 SG 的入站規則引用了這個 SG 作為來源
 4jq -r --arg sg "$SG_ID" '.[] |
 5  select(.IngressRules[]?.UserIdGroupPairs[]?.GroupId == $sg) |
 6  "\(.GroupId) (\(.GroupName)) 的入站規則引用了 \($sg)"' sg-inventory-*.json
 7
 8# 哪些 ENI 掛了這個 SG
 9aws ec2 describe-network-interfaces \
10  --filters Name=group-id,Values=$SG_ID \
11  --query 'NetworkInterfaces[].{Id:NetworkInterfaceId,Desc:Description,Status:Status}' \
12  --output table
13
14# 哪些 RDS instance 使用這個 SG
15aws rds describe-db-instances \
16  --query "DBInstances[?VpcSecurityGroups[?VpcSecurityGroupId=='$SG_ID']].[DBInstanceIdentifier]" \
17  --output text
18
19# 哪些 ELB 使用這個 SG
20aws elbv2 describe-load-balancers \
21  --query "LoadBalancers[?SecurityGroups[?contains(@,'$SG_ID')]].[LoadBalancerName]" \
22  --output text

如果所有查詢都回傳空，這個 SG 可以安全刪除。

清理流程：標記 → 通知 → 等待 → 刪除

批量清理不是一次 delete-security-group 的事。安全的流程有四步：

標記候選

對每個要清理的 SG 加一個 tag 標明狀態和預定刪除日期：

1aws ec2 create-tags \
2  --resources sg-0abc123 sg-0def456 \
3  --tags Key=cleanup-status,Value=pending-deletion \
4         Key=cleanup-date,Value=2026-07-10 \
5         Key=cleanup-reason,Value="unused-no-eni-no-reference"

通知

如果 SG 有 owner tag，通知該 owner：「這個 SG 預計在 cleanup-date 刪除，如果仍在使用請回報」。如果沒有 owner tag（多數需要清理的 SG 都沒有），在團隊頻道公告清理清單。

等待

給 7-14 天的寬限期。期間如果有人回報某個 SG 仍在使用，把 cleanup-status 改成 retained 並補上正確的 owner tag。

刪除

寬限期過後，對仍是 pending-deletion 的 SG 執行刪除：

1for sg in $(aws ec2 describe-security-groups \
2  --filters Name=tag:cleanup-status,Values=pending-deletion \
3  --query 'SecurityGroups[].GroupId' --output text); do
4  echo "Deleting $sg"
5  aws ec2 delete-security-group --group-id $sg 2>&1
6done

DependencyViolation 代表有遺漏的引用，跳過該 SG 並重新調查。

自動化持續治理

手動稽核適合第一次清理，持續治理靠自動化：

AWS Config 規則

restricted-ssh 和 restricted-common-ports 是 AWS Config 的 managed rule，啟用後會持續監控 SG 規則，新增的 0.0.0.0/0 規則會在幾分鐘內被標記為 non-compliant。

Prowler 定期掃描

在 CI 排程中定期跑 Prowler，掃描結果存進 repo 作為趨勢追蹤：

1prowler aws --services ec2 --checks ec2_securitygroup_allow_ingress_from_internet_to_any_port \
2  -M json-ocsf -o inventory/prowler/

PR 流程攔截

模組七的 checkov/tfsec 護欄在 PR 階段攔截新增的 0.0.0.0/0 規則。這是把治理從「事後稽核」推到「事前攔截」的關鍵一步：稽核能發現已存在的問題，PR 護欄能阻止新問題被引入。

AWS Security Hub 啟用 Foundational Security Best Practices 標準後，會自動聚合 SG 相關的合規 finding 並提供統一 dashboard，適合作為管理層報告的來源。Security Hub 整合了 Config rules 和 Prowler 各自能發現的問題，提供單一窗口追蹤合規趨勢。

稽核節奏

第一次稽核最花時間（半天到一天，取決於 SG 數量）。之後的節奏取決於環境變動速度：

稽核產出一份報告：SG 總數、0.0.0.0/0 規則數、未使用 SG 數、上次稽核以來的變化。這份報告可以作為治理進度的量化指標，納入月報。

跨分類引用

• → 網路地基 — security group 設計：SG 的設計原則（最小開放、group 互相引用）
• → infra 走 PR 流程：checkov/tfsec 在 PR 階段攔截 0.0.0.0/0
• → 治理好習慣 — tagging：tag 是識別 SG owner 和清理候選的依據

五種查詢場景各自需要不同的事件類型、欄位和查詢模式。每種場景的查詢模式也決定了需要 SQLite 層還是 PostgreSQL 層（見 功能分層與 Backend 選擇）。

Debug 查詢

Debug 查詢回答「問題出在哪」。觸發時機是使用者回報問題或 error alert 觸發後，開發者需要還原問題的 context。

查詢場景

剛才使用者回報的問題

查詢模式：用 session_id 過濾，拉出該 session 的全部事件，按時間排序。

1-- SQLite
2SELECT type, name, ts, data
3FROM events
4WHERE session_id = 'abc-123'
5ORDER BY ts;

需要的事件欄位：session_id（關聯同次使用的事件）、ts（排序）、error 的 stack trace 和 step（定位失敗點）。

這個 error 多常發生

查詢模式：按 error name 分群計數，看時間趨勢。

1-- SQLite
2SELECT name, COUNT(*) as count,
3       strftime('%Y-%m-%d', ts) as day
4FROM events
5WHERE type = 'error'
6  AND ts >= datetime('now', '-7 days')
7GROUP BY name, day
8ORDER BY day, count DESC;

需要的事件欄位：type=‘error’、name（分群鍵）、ts（時間分桶）。

需要的事件

Alerting 查詢

Alerting 查詢回答「需要注意嗎」。分兩種機制：rule engine 的即時評估（事件到達時逐筆比對規則）和事後查詢的趨勢分析。

查詢場景

Error 數量突然上升

查詢模式：最近 1 小時的 error 計數 vs 前一天同時段，偏差超過閾值則告警。

1-- SQLite
2SELECT COUNT(*) as recent_count
3FROM events
4WHERE type = 'error'
5  AND ts >= datetime('now', '-1 hour');

Rule engine 的即時版：每收到一筆 error 事件，遞增計數器，計數器超過閾值觸發動作。

特定 error 首次出現

查詢模式：收到 error 時查是否有歷史記錄。

1-- SQLite
2SELECT COUNT(*) FROM events
3WHERE type = 'error' AND name = ?
4  AND ts < ?;

結果為 0 代表首次出現 — 觸發「新 error 類型」告警。Sentry 的核心功能之一就是這個查詢。

Rule engine vs 事後查詢

Rule engine 逐筆評估，延遲在毫秒級，適合「error 出現就通知」。事後查詢用 SQL 聚合，延遲在秒到分鐘級，適合「過去一小時的 error 趨勢」。兩者互補 — rule engine 做即時告警、SQL 查詢做事後分析。

需要的事件

產品決策查詢

產品決策查詢回答「使用者怎麼用產品」。從簡單的功能使用率到複雜的 funnel 分析。

查詢場景

新功能有多少人用

查詢模式：按 event name 計數。SQLite 層即可。

1-- SQLite
2SELECT name, COUNT(*) as count,
3       COUNT(DISTINCT session_id) as unique_sessions
4FROM events
5WHERE type = 'event'
6  AND name LIKE 'new_feature.%'
7  AND ts >= datetime('now', '-7 days')
8GROUP BY name;

註冊流程在哪流失

查詢模式：session 級 funnel JOIN。需要 PostgreSQL 層。

 1-- PostgreSQL
 2WITH session_steps AS (
 3  SELECT session_id, name,
 4         ROW_NUMBER() OVER (PARTITION BY session_id ORDER BY ts) as step_order
 5  FROM events
 6  WHERE name IN ('signup.start', 'signup.email', 'signup.verify', 'signup.complete')
 7    AND ts >= NOW() - INTERVAL '30 days'
 8)
 9SELECT name, COUNT(DISTINCT session_id) as sessions
10FROM session_steps
11GROUP BY name
12ORDER BY MIN(step_order);

完整的 funnel 分析方法論見 從 collector 資料做基礎 funnel 分析。

需要的事件

安全審計查詢

安全審計查詢回答「有沒有非預期的存取」。重點是偵測異常模式而非單筆事件。

查詢場景

有沒有異常登入

查詢模式：auth 失敗事件按 session 分群計數，短時間內大量失敗 = 暴力破解嘗試。

1-- SQLite
2SELECT session_id, COUNT(*) as fail_count,
3       MIN(ts) as first_attempt, MAX(ts) as last_attempt
4FROM events
5WHERE type = 'error' AND name = 'auth.login.failed'
6  AND ts >= datetime('now', '-1 hour')
7GROUP BY session_id
8HAVING fail_count > 5;

誰存取了什麼敏感資料

查詢模式：敏感操作的 audit trail — 按時間列出所有敏感操作事件。

1-- SQLite
2SELECT ts, session_id, name, data
3FROM events
4WHERE type = 'event'
5  AND name IN ('data.export', 'admin.user_lookup', 'config.secret_read')
6ORDER BY ts DESC;

需要的事件

安全事件的取樣率必須是 1.0（全收）— 取樣會讓攻擊嘗試在統計上隱形。見 感測器生命週期管理 的取樣率設計段。

效能查詢

效能查詢回答「系統有多快」和「哪裡變慢了」。

查詢場景

P95 回應時間趨勢

查詢模式：時間分桶 + percentile 聚合。需要 PostgreSQL 層。

1-- PostgreSQL
2SELECT date_trunc('hour', ts) as hour,
3       percentile_cont(0.95) WITHIN GROUP (ORDER BY (data->>'duration_ms')::int) as p95
4FROM events
5WHERE type = 'metric' AND name = 'api.response.duration'
6  AND ts >= NOW() - INTERVAL '7 days'
7GROUP BY hour
8ORDER BY hour;

SQLite 沒有內建 percentile 函數。SQLite 層的替代方案是排序後取第 95% 位置的值，但在大資料量時效能差。

哪個版本變慢了

查詢模式：按 source.version 分群比較效能。

1-- SQLite / PostgreSQL
2SELECT source_version, AVG((data->>'duration_ms')::int) as avg_ms,
3       COUNT(*) as sample_count
4FROM events
5WHERE type = 'metric' AND name = 'api.response.duration'
6  AND ts >= datetime('now', '-7 days')
7GROUP BY source_version;

需要的事件

查詢 → 事件反推表

設計事件時用這張表反向確認：每種查詢場景需要什麼事件、什麼欄位、什麼 storage 層級。

這張表和 事件枚舉與補齊檢查 的事件表互補 — 事件枚舉從操作端正向推導「要收什麼」，本表從查詢端反向確認「收的夠不夠」。

下一步路由

• 從操作端正向推導事件 → 事件枚舉與補齊檢查
• 動機和事件的對應關係 → 動機驅動的事件設計
• SQLite vs PostgreSQL 的查詢能力分界 → 功能分層與 Backend 選擇
• Rule engine 的即時評估 → Rule engine 設計

概念位置

CloudTrail 在 infra 治理裡的角色是「發生了什麼」的最後防線。人工變更日誌記錄「為什麼改」，CloudTrail 記錄「改了什麼」— 兩者一起才能從事故回推到可回退的操作。

CloudTrail 預設記錄 management event（建立、修改、刪除資源的 API 呼叫）並保留 90 天可查閱。要長期保存或記錄 data event（S3 物件存取、Lambda 呼叫等更細粒度的操作），需要建立 trail 並指定 S3 bucket 儲存。

可觀察訊號

以下狀況指向 CloudTrail 的使用場景：

• 事故排查需要回答「誰在過去 24 小時改過這個 security group」— CloudTrail 的 LookupEvents API 可以按事件名稱、資源類型或使用者名稱查詢
• 安全稽核要求提供「過去 90 天內所有 IAM policy 變更的紀錄」— CloudTrail 是標準的證據來源
• 發現不預期的資源變更（drift），需要確認是人為操作還是自動化觸發 — CloudTrail 的 userIdentity 欄位區分人類使用者和 assume-role 的服務

設計責任

使用 CloudTrail 時要決定：

• 保留期限：預設 90 天免費查閱；超過需要建 trail 存到 S3，費用是 S3 儲存成本
• 事件範圍：management event 預設開啟；data event（S3 物件讀寫、Lambda invoke）要額外設定，且量大時儲存成本可觀
• 跨帳號整合：多帳號架構下，Organization trail 可以把所有帳號的事件集中到一個 S3 bucket
• 存取控制：CloudTrail 的 S3 bucket 本身要限制存取 — 能修改稽核日誌等於能掩蓋操作痕跡

鄰卡

• IAM — CloudTrail 記錄的是 IAM 身分的 API 呼叫
• Drift — CloudTrail 是追查 drift 來源（誰手動改了什麼）的工具

Credential 掃描與處理

寫死在程式碼裡的 credential 是接手後最先要掌握的風險面。資料庫密碼、API key、SMTP 帳號這些值如果散落在多個 PHP 檔案裡，每一個都是外洩路徑。

掃描方式

用 grep 對整個 codebase 搜尋常見的 credential 關鍵字：

1grep -rn "password\|passwd\|secret\|api_key\|app_key\|mysql_connect\|mysqli_connect\|PDO(" \
2  --include="*.php" .

常見的集中位置是 config.php、wp-config.php、database.php、settings.php，以及專案根目錄的 .env。但 legacy 專案的 credential 經常散落在意想不到的地方——寫在某個 helper function 的預設參數裡、硬編碼在 cron job 的 PHP 檔案裡、或藏在某個很久沒改的 email 發送模組裡。grep 的涵蓋範圍應該是整個專案目錄，不只是已知的 config 檔案。

如果專案已經在本地 Git repo（見主文的快照步驟），檢查 Git 歷史裡有沒有曾經存在但後來被刪除的 credential：

1git log --all -p -- '*.php' | grep -i "password\|secret\|api_key" | head -30

歷史裡的 credential 無法從 Git 裡真正移除（rewrite history 可以但成本高），所以找到的 credential 都要列入輪替清單。

處理方式

掃描結果彙整成一張清單，每筆記錄：credential 類型、所在檔案、用途、是否可輪替。處理優先序：

把 credential 從 code 移到 .env 後，用 getenv('DB_PASSWORD') 或框架的 config 機制讀取。.env 加進 .gitignore，prod 的 .env 透過 FTP 單獨上傳、不進版本控制。

PHP 版本與已知漏洞

PHP 版本決定了這個專案暴露在什麼層級的平台風險下。已結束安全支援（EOL）的 PHP 版本不代表「馬上會被攻擊」，但代表任何未來被發現的漏洞都不會得到官方修補。

版本確認

在站台放一個 phpinfo.php，瀏覽後記錄版本號，完成後立刻刪除（phpinfo() 輸出含伺服器路徑與配置細節，留在 prod 上是資訊外洩）：

1<?php phpinfo(); ?>

或在 cPanel / Plesk 的 PHP 設定頁面直接查看。

版本風險對照

版本升級是獨立的工程專案——可能會觸發函式棄用警告、行為變更、甚至語法不相容。盤點階段的任務是記錄版本和風險等級，升級規劃放在穩定維運之後。

常見的 PHP 安全漏洞模式

Legacy PHP 專案最常見的四類漏洞都可以用 grep 做初步掃描。掃描結果是候選清單、不是確認的漏洞——每個命中都需要讀上下文確認是否有防護。

SQL injection

任何把使用者輸入直接拼接到 SQL 查詢裡的寫法都是 SQL injection 的候選：

1# 找使用 mysql_query / mysqli_query 但沒有 prepare/bind 的查詢
2grep -rn "mysql_query\|mysqli_query" --include="*.php" . | grep -v "prepare\|bind_param"
3
4# 找字串拼接的 SQL 查詢
5grep -rn "query.*\\\$_GET\|query.*\\\$_POST\|query.*\\\$_REQUEST" --include="*.php" .

修法是改用 prepared statement（PDO 或 mysqli 的 prepare + bind_param）。如果 codebase 大量使用 mysql_* 函式（PHP 7.0 已移除），這本身就是版本升級的阻礙——需要同時處理。

XSS（跨站腳本）

把使用者輸入直接輸出到 HTML 而沒有跳脫：

1# 找直接 echo/print 使用者輸入的地方
2grep -rn "echo.*\\\$_GET\|echo.*\\\$_POST\|echo.*\\\$_REQUEST\|echo.*\\\$_COOKIE" --include="*.php" .
3
4# 找 PHP 短標籤輸出
5grep -rn "<?=.*\\\$_" --include="*.php" .

修法是所有輸出都經過 htmlspecialchars($var, ENT_QUOTES, 'UTF-8')。模板引擎（如 Twig、Blade）預設會做跳脫，使用模板引擎的專案 XSS 風險較低。

檔案包含（File Inclusion）

把使用者輸入當作 include 或 require 的路徑：

1grep -rn "include.*\\\$_\|require.*\\\$_\|include_once.*\\\$_\|require_once.*\\\$_" --include="*.php" .

這類寫法讓攻擊者可以指定載入任意檔案（本地或遠端）。修法是用白名單限制可載入的檔案路徑。

檔案上傳

檢查上傳處理的三個面向：副檔名驗證（只允許白名單）、上傳目錄是否可執行 PHP（不應該）、檔案大小限制。

1# 找上傳處理程式碼
2grep -rn "move_uploaded_file\|\\\$_FILES" --include="*.php" .

每個命中的上傳處理都要確認：有沒有驗證副檔名（黑名單不夠、要白名單）、上傳目錄有沒有 .htaccess 禁止 PHP 執行（見下節）、有沒有重新命名上傳的檔案（避免覆寫攻擊）。

Session 管理

1# 找 session 相關設定
2grep -rn "session_start\|session_regenerate_id\|session\.cookie_httponly\|session\.cookie_secure" --include="*.php" .

確認：登入成功後有沒有呼叫 session_regenerate_id(true) 防止 session fixation、session.cookie_httponly 是否為 on（防止 JavaScript 讀取 session cookie）、session.cookie_secure 在 HTTPS 站台是否為 on。

.htaccess 安全設定

無 SSH 的 Apache 環境中 .htaccess 是可用的伺服器端安全防線。盤點時確認這些設定是否存在，缺少的補上。

基礎安全設定

 1# 禁止目錄列表 — 防止瀏覽上傳目錄的檔案清單
 2Options -Indexes
 3
 4# 阻擋敏感檔案的 HTTP 存取
 5<FilesMatch "\.(env|local|bak|sql|log|ini|conf|yml|json|lock|md)$">
 6    Require all denied
 7</FilesMatch>
 8
 9# 阻擋隱藏檔案與目錄（.git、.env 等）
10<IfModule mod_rewrite.c>
11    RewriteEngine On
12    RewriteRule (^\.|/\.) - [F]
13</IfModule>
14
15# 強制 HTTPS
16<IfModule mod_rewrite.c>
17    RewriteCond %{HTTPS} off
18    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
19</IfModule>

上傳目錄的 PHP 執行禁令

在上傳目錄（如 uploads/、wp-content/uploads/）放一個獨立的 .htaccess：

1# 禁止此目錄下的 PHP 執行
2php_flag engine off
3
4# 只允許靜態檔案類型
5<FilesMatch "\.(?!jpg|jpeg|png|gif|pdf|webp|svg|css|js)">
6    Require all denied
7</FilesMatch>

這條設定讓即使攻擊者成功上傳了 .php 檔案，也無法透過 HTTP 請求觸發執行。

安全 header

 1# 防止 MIME type sniffing
 2Header set X-Content-Type-Options "nosniff"
 3
 4# 防止 clickjacking
 5Header set X-Frame-Options "SAMEORIGIN"
 6
 7# XSS 防護（現代瀏覽器多已內建、但舊站加上無害）
 8Header set X-XSS-Protection "1; mode=block"
 9
10# Referrer 資訊控制
11Header set Referrer-Policy "strict-origin-when-cross-origin"

檔案權限

無 SSH 環境的權限控制能力有限——多數情況下透過 FTP client 檢查和調整。

777 權限（所有人可讀寫執行）在多租戶主機上等於同一台伺服器的其他租戶也能讀寫這些檔案。如果發現任何目錄或檔案是 777，立刻改回 755/644。FileZilla 在檔案上按右鍵 → 「File permissions」可以查看和修改。

外部依賴的安全性

Composer 管理的依賴

如果專案使用 Composer，在本地跑一次已知漏洞檢查：

1composer audit

這條指令比對 composer.lock 裡的每個套件版本與 Packagist 的安全公告資料庫，列出有已知 CVE 的套件。

手動管理的依賴

沒有 Composer 的 legacy 專案可能直接把第三方程式碼複製進專案目錄。常見的高風險依賴：

JavaScript CDN 引用

檢查 HTML 裡引用的外部 JavaScript CDN 連結，確認：使用 integrity 屬性（Subresource Integrity）防止 CDN 被竄改、引用的 CDN 是否仍在維護。

掃描工具

除了手動 grep，可以用工具做自動化掃描。這些工具都從本地或外部執行，不需要在 prod 伺服器上安裝任何東西。

WordPress 站台的掃描指令：

1# WPScan 掃描（從本地執行、掃描遠端站台）
2wpscan --url https://example.com --enumerate vp,vt,u
3# vp = vulnerable plugins, vt = vulnerable themes, u = users

所有掃描結果存進 repo 的 security-audit/ 目錄，標上日期。這份報告是後續修補計畫的輸入，也是向管理層說明安全狀態的依據。

跨分類引用

• → 無 SSH 的 FTP / 面板管理環境接管：本文的前置步驟（程式碼與資料庫快照）
• → 資料庫備份與變更管理：SQL injection 修復前先備份，避免修補過程造成資料遺失
• → 無 SSH 環境的監控與告警：安全事件的持續偵測與錯誤追蹤
• → 模組二：身分與憑證地基：credential 管理的系統性設計
• → Backend 模組七：資安與資料保護：應用層安全的完整討論

資安教學內容的 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 格式為輸出模板。

當跑 multi-reviewer parallel audit（4-reviewer / N-reviewer）、最 high-priority 不是 單一 reviewer flag 的 most severe finding、是 多個 reviewer 從不同軸獨立 flag 的同一 finding。

直覺：

• 單 reviewer flag P0 finding 是 該軸的判斷
• 跨 reviewer convergence flag 是 多軸共同 hit 同一點、信號收斂

機制：N 個獨立 axis 隨機 hit 同一 finding 的機率隨 N 指數下降 — 兩個 axis 偶然 hit 同點機率低、三個 axis hit 同點機率更低。所以 convergence 排除 單 reviewer 主觀 / 偏好 bias、留 系統性 issue。

Case：MySQL 4-reviewer audit

跑 4-reviewer audit（A 寫作規範 / B 跨檔一致性 / C 技術準確性 / D 結構性質疑）對 MySQL 17 篇：

2 軸 convergence 的 finding（缺 weight + frame uniformity）信號特別強 — 兩個 reviewer 從不同 audit 維度（寫作規範軸 vs 跨檔一致性軸）獨立判斷出同一 issue。

對比：PlanetScale FK 是 單 reviewer 找到的 highest-severity finding（invalidates 整段 Phase 1 audit premise）、但是 單軸 flag。

兩種都 P0、但 priority weighting 應該不同：

• 2 軸 convergence finding：structurally important、是 batch level pattern
• 單軸 high-severity finding：technically critical、specific issue

機制：為什麼 convergence 比 severity 重要

1. 單 reviewer flag 有 axis-specific bias

每個 reviewer 用特定 audit 軸（寫作規範 / 一致性 / 技術 / 結構）。單軸 flag 帶該軸的 judgment preference：

• Reviewer A 偏好 寫作風格規範、可能 flag 過嚴
• Reviewer C 偏好 technical correctness、可能 flag 一些 正確但 niche 議題

單軸 flag finding 可能是 該軸 perspective 的 P0、其他軸 perspective 不重要。

2. 跨 axis convergence 排除 axis-specific bias

當兩個 reviewer 從 不同 axis 獨立 flag 同 finding、表示這個 issue 對 多種 judgment perspective 都 reachable — 是 系統性 pattern、不是單一 perspective 的偏好。

舉例：「4 篇 migration playbook 缺 weight」

• Reviewer A 從 寫作規範 角度 flag：missing frontmatter required field
• Reviewer B 從 跨檔一致性 角度 flag：13 篇 deep article 有 weight、4 篇 migration 沒有、不對齊

兩個獨立 reasoning path 到同一 finding、信號收斂、是 結構性問題。

3. Convergence finding 修一次解決多 reviewer flag

實作層：

• 單軸 P0：修 → 解決 1 個 reviewer 的 flag
• 雙軸 convergence：修 → 解決 2 個 reviewer 的 flag

ROI 上 convergence finding 修法效率 2x。

4. Convergence 揭露 audit framework blindspot 的補集

如果某 finding 所有 reviewer 都沒 flag、可能：

• 沒問題（true negative）
• 所有 axis 都看不到（structural blindspot）

如果某 finding 只一 reviewer flag、可能：

• Niche but real（axis-specific catch）
• Axis-specific bias

如果某 finding 多 reviewer flag、強：

• 多 axis 收斂 → 高度 likely true positive
• 排除 axis-specific bias

修法：Cross-reviewer convergence matrix

1. Multi-reviewer audit 後做 convergence matrix

收齊 N 個 reviewer report 後、不是 merge findings list、是建 matrix：

1Finding          | Reviewer A | Reviewer B | Reviewer C | Reviewer D | Convergence
2─────────────────┼────────────┼────────────┼────────────┼────────────┼────────────
3Missing weight   |     P0     |     P0     |            |            |    **2**
4Frame uniformity |     P1     |            |            |     -      |    **2**
5FK claim 過時    |            |            |     P0     |            |    1
6CTE version 錯   |            |            |     P0     |            |    1
7Conn memory 衝突 |            |     P0     |            |            |    1

Convergence column 自動標 priority bump — 2+ 列為 首要 fix、1 列為 依 severity 處理。

2. Priority list 按 convergence 排序、不是純按 severity

修法 priority：

1. 2+ convergence finding（系統性 pattern）— 必修、高 ROI
2. 單軸 + 高 severity finding（如 FK claim 過時 invalidates premise）— 必修、specific
3. 單軸 + 中 severity finding（如 CTE version 錯）— 修、ROI 中等
4. 單軸 + 低 severity finding — 可選

3. Convergence 揭露的 pattern 寫進 retro

2+ convergence finding 通常是 寫作流程 / 模板 級議題、修了該 case 還要回頭看 為什麼會系統性發生：

• Missing weight：寫 migration playbook 模板沒有 weight、是 template gap
• Frame uniformity：「5 個踩雷」frame 在所有 article 重複、是 frame template too rigid

把這些 pattern 寫進 retro / report card、未來不再踩。

跟既有原則的關係

• Sibling Coverage Asymmetry Blindspot in Priority：本卡是 audit finding 的 priority weighting、那卡是 batch coverage 的 priority weighting、不同 layer
• Multi-Pass Review Frame Granularity Blindspot：multi-pass 是 同 reviewer 多輪、本卡是 多 reviewer 平行、不同模式

反向驗證

不該誤用：

• Convergence > severity 不是絕對 — 單軸高 severity finding（如 invalidates premise）仍是必修、不該因為「只一軸 flag」延後
• N=1 reviewer audit 不適用本卡 — 至少 2 個 reviewer 才有 convergence 概念
• 2 個 reviewer 用 同樣 axis 都 flag 不算 convergence — 必須 不同 axis 才是真正收斂
• Reviewer 之間 互相看過彼此 report 後再 flag 不算 convergence — 必須 獨立 parallel 跑

觸發再評估

• N-reviewer audit 跑超過 5 輪後、check convergence finding 的 follow-up rate 是否真比單軸 finding 高
• 出現 3 軸以上 convergence 的 finding 時、是否 trigger framework-level review（不只是 content fix）
• 累積足夠 reviewer convergence case 後、考慮抽出 axis design 原則：哪些 axis 組合的 convergence 最 informative

本文的判讀錨點是：audit logging 要服務於 investigation 與 compliance。Slow query log、general log、binary log、error log、managed service audit log、plugin audit log 各自承擔不同證據，不應混成同一種 log。

Event Taxonomy

Event taxonomy 的核心責任是定義要蒐集哪些資料庫事件。

事件分類要對應 alert。DDL 可以進 release audit；failed login 可以進 security alert；sensitive read 要連到 support ticket 或 break-glass 流程。

Log Sources

Log sources 的核心責任是選出合適來源。

General log 在 production 要謹慎使用。它能提供完整 SQL，但 volume、PII 與成本都高；通常只用短時間 incident window 或測試環境。

SIEM Pipeline

SIEM pipeline 的核心責任是把 database event 轉成集中查詢與告警。

Normalization 要避免把完整 SQL 直接送進 SIEM。對敏感系統，可保留 query fingerprint、table、operation、row count、actor 與 ticket id，而非 literal value。

Alert Rules

Alert rules 的核心責任是把高風險事件變成可行動訊號。

Alert 要有 owner 與 runbook。只把 log 送進 SIEM，缺少 triage rule，incident 時仍然難以快速定位。

Retention and Privacy

Retention and privacy 的核心責任是讓 audit log 同時可用與合規。Audit log 可能包含帳號、IP、SQL、table name、literal value 與 PII；保存時間越長，保護責任越重。

Retention policy 要定義：

1. 保存天數與 storage class。
2. 哪些欄位可被 masked。
3. 誰能查 audit log。
4. Legal hold 如何覆蓋一般 retention。
5. Export 到外部 SIEM 的資料邊界。

Audit log 本身也要納入 access control。能查敏感 audit 的人，通常也能推斷敏感資料活動。

下一步路由

Audit log + SIEM 完成後，加密與憑證讀 Encryption / TLS / Key Management；備份事故讀 PITR / Backup；安全治理讀 Data Protection。

本文的判讀錨點是：資料庫安全是 application auth 的下游防線。Application 仍要負責身份、session、租戶與 workflow；PostgreSQL security layer 負責在資料邊界補上 least privilege、tenant isolation 與 forensic evidence。

Role and Grant Baseline

Role and grant baseline 的核心責任是把人、服務、migration 與分析查詢分開。Production database 至少要區分 application role、migration role、read-only role、admin role 與 replication / CDC role。

Grant review 要以 schema ownership 開始。Tables、sequences、functions、views、extensions 都有權限面；只管 table grant 會漏掉 sequence update、function execution 與 extension 使用。

Row Level Security

Row Level Security 的核心責任是在資料庫層 enforce row visibility。PostgreSQL 官方 RLS 文件描述 policy 可限制 normal query 返回、insert、update、delete 的 row；這讓 tenant boundary 可以在 database 層多一道 guard。

RLS policy 要有 positive allow rule。每張啟用 RLS 的 table 都要有測試：同 tenant 可讀、跨 tenant 隔離、insert tenant mismatch 被擋、admin / support 例外被記錄。

1ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
2
3CREATE POLICY tenant_isolation ON invoices
4USING (tenant_id = current_setting('app.tenant_id')::uuid)
5WITH CHECK (tenant_id = current_setting('app.tenant_id')::uuid);

這段 policy 依賴 application 在 transaction 內設定 app.tenant_id。使用 connection pooler 時，設定必須跟 transaction boundary 對齊，避免 session state 漂移。

Audit Logging

Audit logging 的核心責任是把敏感資料操作轉成可查詢證據。PostgreSQL 原生日誌可以記錄連線、DDL、錯誤與慢查詢；pgAudit 這類 extension 則補強 session / object audit。

Audit log 要能進入 SIEM 或集中 log。只留在 database host 上，事故後查詢成本高；正式 runbook 要定義 retention、masking、access control 與 alert。

PII and Data Protection Boundary

PII and data protection boundary 的核心責任是把 database 權限和資料保護策略接起來。RLS 可以限制 row visibility，但 PII 的保護還需要 masking、tokenization、encryption、retention 與 deletion evidence。

Column-level grant 和 masking view 適合 read-only analyst。Application role 通常需要明文處理 workflow；analyst / support role 則應走 restricted view。

Operational Evidence

Operational evidence 的核心責任是讓安全設定可驗證。每次 release 或權限變更後，要跑固定檢查。

1. Role matrix：每個 role 的 schema / table / sequence / function grant。
2. RLS test：tenant A / tenant B / support / admin 的可見性測試。
3. Audit sample：DDL、sensitive read、failed access 是否進 log。
4. Pooler compatibility：SET LOCAL app.tenant_id 是否跟 transaction 對齊。
5. Break-glass drill：emergency access 是否可申請、可回收、可審查。

Evidence 要保存在 release artifact。Security 設定只有文件描述時，incident 後難以證明它真的生效。

Failure Modes

Failure modes 的核心責任是把 database security 常見事故提前列出。

RLS bypass 要特別審查 table owner 與 superuser path。正式 application 連線應使用 dedicated role，並避免使用 table owner role 執行一般 request。

下一步路由

Security / RLS / audit logging 完成後，權限與 PII 治理讀 Data Protection；connection state 風險讀 Connection Pooler Comparison；實作演練可放進 Schema Migration Evidence Lab 的 release gate。