弱點揭露與修補管理

弱點的揭露與協調

一位學生使用選課系統時注意到，改動網址中的編號可以看到其他同學的資料（第 10 課）。接下來的處理方式會影響許多人：直接公開可能讓更多人利用這個問題，繼續試探可能觸法，不告知校方則問題會一直存在。

協調揭露（coordinated vulnerability disclosure）是目前常用的作法：發現者先通知廠商或系統管理者，雙方協調修補時程，修補完成後再公開說明。早期文獻常稱為「負責任揭露」（responsible disclosure）。依 CERT/CC 的指南，過程涉及發現者、廠商、協調單位與系統部署者，協調單位在雙方無法直接溝通時協助傳遞資訊。

組織可以發布 security.txt（放在網站的 /.well-known/ 路徑下）說明回報管道與揭露政策。臺灣的 TWCERT/CC 參與 CVE 計畫並擔任編號管理者（CNA），也提供協調揭露的管道。

發現他人系統弱點時的作法。 善意的動機並不等於獲得授權。《刑法》第 358 條規定無故輸入他人帳號密碼、破解保護措施或利用系統漏洞而入侵他人電腦者的刑責；第 359 條規定無故取得、刪除或變更他人電磁紀錄致生損害者的刑責；第 363 條規定第 358 至 360 條之罪須告訴乃論。「無故」的判斷要依個案認定。以上為條文摘述，不構成法律意見（第 1 課）。

一般原則是：

• 看到問題就停止，不繼續擴大測試，不存取或下載他人資料
• 記下時間、網址與觀察到的現象，內容足以讓對方重現即可
• 透過官方管道回報：security.txt、揭露政策、學校資安窗口；校園網路另有臺灣學術網路危機處理中心（TACERT）的資安通報窗口；找不到窗口時可洽 TWCERT/CC
• 給對方修補的時間，不以公開或付款作為要求的條件
• 想要深入研究時，在自己架設的環境中重現，或參加有明確授權範圍的計畫

CVE、CWE 與 CVSS

三個常見的縮寫各自回答不同的問題：

• CVE：這是哪一個已知弱點。例如 CVE-2014-0160（OpenSSL 的 Heartbleed）
• CWE：這屬於哪一類軟硬體缺陷。例如 CWE-89（SQL 注入）、CWE-862（缺少授權）
• CVSS：這個弱點本身的嚴重程度。例如 7.5（高）

CVE 為公開揭露的弱點提供共同的編號，讓不同廠商與工具指的是同一件事。CWE 是社群維護的缺陷類型清單。

CVSS v3.1 的基準分數由八項指標計算：可利用性（攻擊途徑、複雜度、所需權限、使用者互動）、影響（機密性、完整性、可用性），以及範圍（弱點的影響是否跨越原本的安全邊界）。公式如下，權重見規格第 7.4 節：

ISS = 1 - (1 - C) × (1 - I) × (1 - A)
Exploitability = 8.22 × AV × AC × PR × UI

範圍不變：
Impact = 6.42 × ISS
BaseScore = Roundup(min(Impact + Exploitability, 10))

範圍改變：
Impact = 7.52 × (ISS - 0.029) - 3.25 × (ISS - 0.02)^15
BaseScore = Roundup(min(1.08 × (Impact + Exploitability), 10))

Roundup 是無條件進位到小數第一位。影響為 0 時分數為 0。等級：0.1～3.9 低、4.0～6.9 中、7.0～8.9 高、9.0～10.0 嚴重。

版本現況。 CVSS v4.0 於 2023 年 11 月發布，評分改以 MacroVector 查表與內插計算。主要差異包括：取消範圍（Scope），改為分開評估弱點所在系統與後續系統的影響；基準指標新增攻擊條件（Attack Requirements）；原本的時間指標調整為威脅指標（Threat）；新增不影響分數的補充指標（Supplemental）。分數要標明組成，例如 CVSS-B（只有基準）、CVSS-BT、CVSS-BTE。目前 v3.1 與 v4.0 並存，同一筆 CVE 可能有不同版本的分數，閱讀時要確認版本。本課以公式公開、方便驗算的 v3.1 練習。

CVSS 基準分數的限制

FIRST 的 v4.0 使用指南表示，基準分數衡量的是嚴重程度而不是風險，不應單獨用於評估風險。常見的限制如下：

• 沒有資產資訊：相同弱點出現在公開的成績系統與隔離的測試機，基準分數相同
• 沒有利用情形：分數不會告訴你弱點是否正在被攻擊
• 評分者之間有差異：CVE-2025-32711 的 v3.1 分數，NVD 資料同時列出 Microsoft 的 9.3 與 NVD 的 7.5，差別在於範圍與完整性的判斷
• 高分不一定最急迫，中分也不一定不重要：成績匯出 API 的 6.5 屬於「中」，對學校的影響可能很大；Heartbleed 的 7.5 只到「高」，出問題的卻是廣泛使用的基礎元件

補充分數不足的資訊來源包括：

KEV 的收錄條件是已指派 CVE 編號、有可靠證據顯示已遭利用，以及有明確的修補或緩解方式。美國聯邦民間機關的修補期限原由 BOD 22-01 規定；2026 年 6 月的 BOD 26-04 取代了它，改以四項因素決定期限：是否對外、是否列入 KEV、能否自動化利用、技術影響的程度。這些指令只約束聯邦民間機關，CISA 也鼓勵其他組織參考。

查證的限度。 撰寫本課時 cisa.gov 無法以程式讀取，上一段依搜尋摘要與資安業者、媒體的轉述整理，收錄條件多來自 2021～2022 年的資料。實際內容請以 CISA 的官方頁面為準。

修補管理與依賴套件

修補管理是持續的流程：知道自己有哪些系統與軟體、取得弱點資訊、評估優先順序、測試並部署、確認修補生效。修補也有風險，可能造成服務中斷，所以高風險的系統要有測試與回復的程序。無法立即修補時，可以先採取緩解措施，例如暫時關閉功能或限制存取，並記錄期限。

許多弱點出現在依賴的第三方套件之中。軟體物料清單（SBOM，software bill of materials）是正式記錄軟體組成元件及其供應鏈關係的文件，讓組織在新弱點公布時能較快查出受影響的系統。SBOM 只提供清單，不會修補問題，也需要持續更新。

Heartbleed 與 Log4Shell 的教訓

以下兩個案例只討論影響與教訓。

Heartbleed（CVE-2014-0160，2014）。 OpenSSL 1.0.1 至 1.0.1f 的 TLS 實作錯誤，使遠端可以讀取伺服器部分記憶體，其中可能包含私鑰、帳號密碼與工作階段資料（官方說明網站）。這個案例的教訓有三點：

• 更新軟體只能阻止之後的外洩。私鑰可能已經外洩，所以還要撤銷舊憑證、產生新金鑰、使工作階段失效，並請使用者更換密碼
• 說明網站指出，利用過程不會在日誌留下異常痕跡，所以無法由日誌確認是否曾遭攻擊（第 16 課：沒有告警不代表沒有事件）
• 廣泛使用的基礎元件出現問題時，影響範圍遠大於單一分數所呈現的

Log4Shell（CVE-2021-44228，2021）。 Java 日誌函式庫 Apache Log4j 2 的弱點，受影響版本會依日誌訊息內容連線到外部服務，可能導致遠端執行程式。Apache 的公告列出 CVSS 10.0，修補版本為 2.3.1（Java 6）、2.12.2（Java 7）、2.15.0（Java 8 以上）。NVD 紀錄顯示 CISA 在 2021 年 12 月 10 日就將它列入 KEV。這個案例的教訓有兩點：

• 許多組織無法立即回答「我們哪些系統用了這個套件」，因為它常常是間接依賴，這是 SBOM 受到重視的原因之一
• 公告之後的第一個修補版本未必是最後一版：2.15.0 之後又公布 CVE-2021-45046（公告說明 2.15.0 的修補在部分非預設設定下不完整），Java 8 以上需要再升級到 2.16.0，之後還有其他相關弱點。修補管理要持續追蹤

重點整理

• 協調揭露：先通知、協調修補、修補後公開；發現他人系統的問題時應停止操作，透過官方管道回報，善意不等於授權
• CVE 指特定弱點，CWE 指缺陷類型，CVSS 描述弱點本身的嚴重程度
• CVSS v3.1 與 v4.0 並存，閱讀分數要確認版本；基準分數不等於風險
• 修補順序要綜合已知遭利用的紀錄（KEV）、遭利用機率的估計（EPSS）、資產重要性與對外程度
• 修補後還要處理可能已經外洩的金鑰與憑證；SBOM 有助於查出受影響的系統，但它本身不會修補問題

下一課討論一種目前沒有完整解法的弱點：提示注入。