安全指標能將主觀的評估轉化為客觀的、可量化的數據。如果沒有指標，組織就無法回答以下基本問題：我們變得更安全了嗎？我們在安全上的投資獲得回報了嗎？我們接下來應該把重點放在哪裡？
有效的安全指標必須具備以下特性：
| 屬性 | 說明 |
|---|---|
| 可衡量性 (Measurable) | 能夠透過自動化或手動的資料收集將其量化 |
| 可執行性 (Actionable) | 能夠驅動決策與行為的改變 |
| 相關性 (Relevant) | 與業務目標及安全目標保持一致 |
| 及時性 (Timely) | 在需要做決策時能及時提供資訊 |
| 可重複性 (Repeatable) | 一致的方法論能在不同時間點產生具可比性的結果 |
OKR 提供了一個目標設定框架，將高階目標與可衡量的結果連結起來
KPI 是追蹤特定安全目標進度的量化測量指標：
(e.g., criticality level, average remediation time, complexity, Key Performance Indicators (KPI), objectives and key results)
產品指標（Product Metrics
衡量軟體本身的安全性狀況：
| 指標 | 說明 | 範例 |
|---|---|---|
| 漏洞密度（Vulnerability density） | 每千行程式碼（KLOC）中的漏洞數量 | 每 KLOC 有 2.3 個漏洞 |
| 依嚴重程度分類的未修復漏洞數量（Open vulnerability count by severity） | 目前尚未解決的漏洞數量 | 0 個嚴重（Critical）、3 個高風險（High）、12 個中風險（Medium） |
| 缺陷移除效率（Defect Removal Efficiency, DRE） | 在正式上線前被發現的缺陷比例 | 95% DRE（在開發／測試階段發現，而非正式環境） |
| 程式碼覆蓋率（Code coverage） | 安全性測試實際執行到的程式碼比例 | 78% 的安全性測試覆蓋率 |
| 第三方元件風險（Third-party component risk） | 已知具有 CVE（常見漏洞與曝險）的相依套件數量 | 4 個相依套件具有已知的高風險 CVE |
複雜度指標 (Complexity Metrics)
複雜度與安全風險息息相關 — 越複雜的程式碼往往潛藏越多的漏洞：
| 指標 | 說明 |
|---|---|
| 循環複雜度 (Cyclomatic complexity) | 程式碼中線性獨立路徑的數量；數值越高 = 需要測試的路徑越多，潛在錯誤也越多 |
| 耦合度 (Coupling) | 模組之間相互依賴的程度；高耦合度會擴大漏洞的爆炸半徑 (blast radius) |
| 程式碼變動率 (Code churn) | 程式碼變更的頻率；安全攸關區域的高變動率需要額外的審查 |
| 攻擊面大小 (Attack surface size) | 進入點、介面與暴露服務的數量 |
(e.g., reports, dashboards, feedback loops)
| 目標 | 說明 |
|---|---|
| 可視性 (Visibility) | 讓所有利害關係人都能清楚了解目前的安全性狀況 |
| 責任歸屬（Accountability） | 證明各項安全活動確實有被執行 |
| 決策支援 (Decision support) | 為基於風險評估的商業決策提供數據支持 |
| 趨勢分析 (Trend analysis) | 呈現一段時間內安全性的改善或惡化趨勢 |
| 合規性證據 (Compliance evidence) | 證明符合法規與相關標準的要求 |
| 資源合理化 (Resource justification) | 為安全工具、人員與流程的投資背書並提供依據 |
Google 如何縮短平均修復時間 (MTTR)：簡化事件應變程序的六種方法
https://cloud.google.com/discover/how-to-reduce-mttr?hl=zh-TW
iThome鐵人賽
看影片追技術