資安報告滿頁紅字，卻沒人要修？高中低不是你的待辦順序

拿到一份資安報告，最危險的瞬間不一定是看到「高風險」，而是會議結束後，大家都以為另一個人會處理。老闆看到紅字想趕快清零，工程師說要排版本，外包廠商說不在維護範圍；一個月後，檔案還在，負責人卻沒定下來。這是本文的假設情境，不是奧微客戶事故。

企業主不必背完評分公式，但要問得出：這項問題在哪個系統、什麼條件下能被利用、會傷到哪段營運，以及誰要交回修補證據。高中低能幫你理解問題，不能代替這四個答案。

紅字說的是什麼，不是什麼

不少報告會使用 CVSS，也有服務商採自己的分級。先問清楚規則，再解讀顏色；不能看到「高」就假定不同報告用了同一把尺。FIRST 的 CVSS v4.0 規格把分數分為無、低、中、高、嚴重：0.0、0.1～3.9、4.0～6.9、7.0～8.9、9.0～10.0。這是該標準的技術嚴重度區間，不是台灣企業共通的法定修補期限。FIRST 規格

更重要的是，FIRST 明確提醒：CVSS 基礎分數衡量嚴重度，不能單獨用來評估風險。威脅變化與你自己的環境仍要補進判斷。報告若只寫一個數字，要求補上版本、評分向量與評估前提，才知道數字怎麼來。FIRST 使用指南

你的工作不是把所有紅字一口氣吞下，而是確認哪些發現真的適用於現行系統。產品版本、功能是否啟用、入口是否可到達、需要什麼權限，都應有對應證據。沒有資料就記「待確認」，不要把不確定自動解讀成安全，也不要讓一個顏色把問題說完。

同樣高風險，可能是兩張不同的處置單

想像兩個假設發現：一個在已下線的測試機，另一個在每天處理訂單的對外系統。即使標成同級，資產現況、接觸途徑與中斷代價也不同。這不是說測試機的問題可以不管，而是你要確認它是否真的隔離、是否仍存有資料，以及誰能證明已下線。

有些報告另列 EPSS。FIRST 將它描述為估計已公開 CVE 未來 30 天遭實際利用機率的模型；它不是你公司被駭的機率，也不取代資產現況與影響評估。FIRST EPSS

所以，別把不同指標湊成一個「越大越快修」的排行榜。先請檢測方說清楚技術依據，再由系統與業務負責人補上公司情境。以下是本文原創的交接表，不是 CVSS 計算公式或官方認證程序。

把風險等級翻成可追蹤的工作

這張表的用途，是讓檢測方、工程師、外包廠商與主管對同一項工作說同一種話。日期應依實際風險、修補可行性與適用契約決定，不能把文章中的管理建議當法律要求。若有遭入侵跡象，還要啟動相符的事件應變，不是把它當一般改版等待。

暫時擋住，不等於問題消失

修補可能需要停機或測試，先限制入口、停用相關功能或縮小權限，可以作為經評估的暫時措施。但誰批准、措施保護哪個範圍、什麼時候再檢查，都要留紀錄。不能只說「我們有防火牆」，就把問題從清單刪掉；也不能為了報告好看，跳過變更測試直接上線。

如果公司沒有人能把檢測結果接成這些處置資料，可以先從 智盾資安服務 了解網站、內部系統、資料庫與程式源碼四面向檢測，以及 AI 輔助滲透測試加人工驗證、風險分級報告與優先修補建議。奧微是軟體開發團隊，也可協助程式修補；這不代表代管所有系統、保證零漏洞或固定期限結案。

下次開報告會議，先問這三句

第一句：「這個等級用的是哪套規則，證據與成立前提在哪裡？」第二句：「以我們現在的系統，它影響哪段業務，還有哪些事沒確認？」第三句：「誰在約定日期交什麼，誰負責複驗？」

報告可以很厚，交接不能模糊。你要的不是一張紅字變少的封面，而是一條從發現、決策、修補到驗證都找得到人的紀錄。未修項目也應有明確責任與理由，不能靠把等級調低來消失。

本文由提供資安檢測與軟體開發服務的奧微軟體撰寫，與所介紹服務有商業關係。資料查核日：2026-10-12。本文為一般防守管理建議，不是個別系統安全保證或法規、合約適用性判定。