弱點掃描報告怎麼看？
高中低風險判讀、修補時限與複測

弱點掃描報告要先看「掃了什麼」，再看「掃到什麼」：範圍、工具版本、是否登入後掃描這三件事沒對清楚，後面的高中低風險數字都沒有比較基礎。判讀風險時，報告上的 CVSS 分數只是起點，還要看弱點是否對外、是否已有公開的攻擊手法、系統的防護需求等級；排除誤報要有證據，不能只憑一句「我們有更新」。修補時限法規沒有給天數，要在契約裡約定；修補完用同一套設定複測，逐項列出每個弱點的最後狀態，才算結案。

這篇寫給政府機關的資訊承辦人，以及負責機關系統維運的廠商。公部門網站代管要符合哪些規範那篇，把「弱點掃描報告與修補紀錄」列為稽核常調閱的 7 項佐證之一，也提到契約要寫修補時限；本文接著寫報告本身怎麼讀、誤報怎麼排除、修補後怎麼複測。系統層的整體防護框架見警政系統上雲安全嗎。

弱點掃描報告怎麼看？先確認範圍，再看風險數字

一份弱點掃描報告通常分成三段：掃描設定、風險摘要、弱點明細。多數人直接翻到摘要看「高風險幾項」，但摘要的數字只有在掃描設定正確時才有意義。同一個系統，換一個掃描範圍或改成不登入掃描，高風險數量可以從兩位數變成零，這不是系統變安全了，而是掃描器看不到了。拿到報告，先對下面五項：

要確認的項目	看什麼	沒對清楚會怎樣
掃描範圍	列出的 IP、網址與連接埠，是否涵蓋這個系統的全部對外服務、後台與 API	後台或測試站沒掃到，報告乾淨但風險還在
工具與弱點特徵庫日期	掃描工具名稱、版本，以及弱點特徵庫（plugin／signature）更新到哪一天	特徵庫太舊，近期公布的弱點一項都不會出現
是否登入後掃描	有沒有提供帳號讓掃描器登入系統或主機後再檢查	只掃登入頁，看不到登入後的功能頁與主機上的套件版本
掃描時間與期間	開始與結束時間、是否中途被防火牆或 WAF 擋下	掃到一半被擋，報告看起來項目很少
排除項目	有沒有被刻意排除的主機、路徑或檢測項目，以及排除理由	排除清單沒有書面紀錄，稽核時說不清楚

範圍對清楚之後，再看明細。每一筆弱點通常會有：弱點名稱、CVE 編號（公開弱點的國際編號）、CVSS 分數與風險等級、受影響的主機與連接埠、掃描器判定的證據，以及建議的處理方式。判讀的重點在「證據」這一欄：掃描器是實際送出測試請求、看到有問題的回應，還是只讀到版本號就推論有弱點？兩種的可信度差很多，下一節排除誤報時會用到。

高中低風險怎麼判讀？CVSS 分數只是起點

多數掃描工具用 CVSS（通用弱點評分系統）給分，再換算成風險等級。CVSS 3.x 的換算方式如下，有些報告會把「嚴重」併進「高」，所以會看到「高中低」三級或「嚴重、高、中、低」四級兩種寫法：

CVSS 3.x 分數	風險等級	報告上常見的標示
9.0～10.0	嚴重	Critical，或併入「高」
7.0～8.9	高	High
4.0～6.9	中	Medium
0.1～3.9	低	Low
0.0	無	Info／資訊，通常只是揭露資訊，不算弱點

CVSS 的基本分數描述的是「這個弱點本身有多嚴重」，不知道它在你的系統裡處在什麼位置。所以排修補順序時，要再加上四個因素：

1. 是否對外：對網際網路開放的服務，優先於只有內網或 VPN 才連得到的服務。同樣是 7.5 分，前者任何人都能嘗試，後者要先突破另一層。
2. 是否已有公開的攻擊手法或已知遭利用：弱點有沒有公開的利用程式、是否被列入已知遭利用的清單（例如美國 CISA 維護的 KEV 清單）。已經有人在用的弱點，分數再低也要往前排。
3. 系統的防護需求等級：依資通系統防護需求分級原則，系統被評為「高、中、普」哪一級。處理個資或執法資料的系統，同一個弱點的後果比形象網站嚴重。
4. 是否已有補償控制：例如應用程式防火牆已攔下這類攻擊、該功能已關閉。補償控制可以降低急迫性，但要寫進紀錄，而且不能取代修補。

誤報怎麼排除？要有證據，不是一句「已更新」

誤報最常見的來源是版本號推論：掃描器讀到伺服器回應的軟體版本，對照弱點資料庫，判定「這個版本有某某弱點」。但許多企業級 Linux 發行版會把安全修補「回移」（backport）到原本的版本裡，修好了，版本號卻不變。我們維運的主機使用 CloudLinux，屬於這一類發行版，掃描器只看版本號時，就可能把已修補的套件報成有弱點。反過來，也有不少高風險項目是因為伺服器把版本號直接回應給外界才被抓到；以本站為例，網站回應的伺服器標頭只有「LiteSpeed」，不帶版本號，也沒有回應 PHP 版本，掃描器就無法靠版本號推論。

判定誤報時，紀錄至少要有三樣東西：

• 依據：例如發行版的安全公告編號、套件的變更紀錄裡寫明已修補該 CVE。
• 驗證：主機上實際安裝的套件版本，或用掃描器的測試請求手動重現、確認沒有問題的結果。
• 判定人與日期：誰判定、誰覆核。誤報判定由維運廠商提出、機關承辦確認，不要由同一個人自己判自己。

每一筆弱點最後只會落在四種狀態之一：確認存在待修補、判定誤報、風險接受、補償控制中。其中「風險接受」要由機關書面簽核，寫明理由與重新檢視的日期，不是廠商可以自己決定的事。

政府系統弱點掃描多久做一次？依責任等級與防護需求

政府系統的弱點掃描頻率，法源是資通安全管理法授權訂定的《資通安全責任等級分級辦法》。以 2026 年 1 月 7 日修正的附表為準，公務機關的「安全性檢測」規定如下：

責任等級	弱點掃描	滲透測試
A 級公務機關	全部核心資通系統每年辦理二次	全部核心資通系統每年辦理一次
B 級公務機關	全部核心資通系統每年辦理一次	全部核心資通系統每二年辦理一次
C 級公務機關	全部核心資通系統每二年辦理一次	全部核心資通系統每二年辦理一次
D、E 級	應辦事項未列安全性檢測

資料來源：全國法規資料庫《資通安全責任等級分級辦法》附表一、三、五、七、八（2026-01-07 修正）。特定非公務機關另見附表二、四、六，實際適用以最新公告條文為準。

讀這張表要注意兩件事。第一，責任等級的要求對象是「核心資通系統」，一個網站或系統算不算核心，由機關判斷；不是核心系統，不代表不用掃，而是回到下一段的防護基準。第二，附表十的《資通系統防護基準》依系統本身的防護需求等級，在「測試階段」另有要求：防護需求等級「中」以上的系統要執行弱點掃描，「高」還要再執行滲透測試。也就是說，責任等級決定機關整體多久掃一次，防護需求等級決定每個系統上線前要做到什麼程度。

表上的頻率是下限。實務上還有三個時間點應該加掃：新系統上線前、改版或重大更新後、重大弱點公布時。第三種最常被忽略，例如網站使用的框架或元件公布了嚴重弱點，不該等到下一次排定的掃描才確認自己有沒有中。系統版本與元件清單平時有維護的話，這種確認只要比對清單就能完成；元件版本該怎麼追，PHP 的部分，哪些版本已經不再收到安全性更新，可參考PHP 版本怎麼選。

修補時限怎麼訂？複測與結案條件寫進契約

法規對修補的要求是原則性的：分級辦法附表寫「知悉資通安全弱點時，應適時修補或採行緩解措施」，附表十的防護基準要求定期確認漏洞修復狀態，且漏洞修復應測試有效性及潛在影響。幾天內要修完，法規沒有給數字，要由機關在契約或維運規範裡約定。約定時，下面五項要一起寫，只寫天數的條款很難驗：

條款	要寫清楚什麼	沒寫會怎樣
起算點	從報告交付日、機關通知日，還是弱點公布日起算；以日曆天或工作天計	雙方對「逾期」的認定不同，扣款或考評時起爭議
分級時限	嚴重、高、中、低各自的修補期限，以及對外且已知遭利用的弱點是否另訂較短期限	所有弱點同一個期限，急的拖、不急的趕
無法如期修補時	原廠未釋出更新或修補會影響業務時，改採哪些緩解措施、誰簽核風險接受、多久重新檢視	弱點長期掛在報告上，每次稽核都重講一次理由
修補前的測試	修補先在測試環境驗證，正式環境更新前要有備份與退回方式	為了修弱點把系統更新壞，造成停機
複測與結案	複測方式、複測報告格式、每筆弱點的結案條件	交一份新報告就算結案，原本的弱點有沒有修好說不清楚

天數本身本文不提供建議值，因為合理的期限取決於系統是否對外、維運人力與變更管理流程；但順序是明確的：對外、已知遭利用的高風險弱點最先處理，其他依風險等級排下去。回應時效與逾期扣款的整體訂法，可以和警政系統維運 SLA的分級回應一起設計；要寫進標案規格書的話，條文怎麼寫得驗得到，見科技執法標案規格書怎麼寫。

六項都有，這份報告拿去應付稽核就不必再補件；把它做成每次掃描固定的格式，承辦人輪調時也有東西可以交接。系統換廠商時，歷次弱掃報告與修補紀錄同樣要列入移交，做法見科技執法系統換廠商怎麼交接；系統驗收時要不要附弱掃與複測報告，可以參考科技執法系統驗收怎麼驗的佐證文件清單。

瑪尼國際成立於 2004 年，深耕資訊服務逾 20 年、服務逾 500 家企業，並以協力廠商身分參與全台多個縣市警察局交通隊的入案系統建置與維運。科技執法與民眾檢舉這類對外服務的系統，弱點處理的速度直接影響機關的稽核結果；我們的做法是把系統元件版本清單與修補紀錄當成平常的維運工作，而不是收到報告才開始查。主機放在中華電信光纖機房，由我們負責網站代管與作業系統更新，前台與後台的網頁設計也可以一併規劃；從程式、資料庫到主機由同一組人負責的一條龍服務，弱點報告上的每一筆都有明確的處理人。

常見問題