弱點掃描是用工具把系統對照已知弱點的清單，列出哪裡版本過舊、缺修補、設定錯誤。滲透測試是由人模擬攻擊者，把找到的幾個弱點接起來，看最後能拿到多大的權限。前者說明系統有哪些弱點，後者說明攻擊者能否進入系統、最遠走到哪裡。
這篇依三類資料寫：全國法規資料庫的《資通安全責任等級分級辦法》（民國 115 年 1 月 7 日修正版，2026-11-04 查核）、美國 NIST 的測試指引，以及開發團隊配合教育部專案的經驗。
弱點掃描
- 辨識系統作業系統、應用程式、開放的通訊埠
- 對照已知弱點資料庫過期版本、缺漏修補、錯誤設定
- 列出清單誤報率高，要有人判讀
滲透測試
- 找出可能的標的常從弱點掃描的結果開始
- 串接多個弱點模擬真實攻擊
- 看能走到哪裡能拿到多大權限，防守者能否偵測
依 NIST SP 800-115 意譯整理。
弱點掃描和滲透測試的差別
NIST SP 800-115 把兩者分得很清楚。這份文件是 2008 年 9 月發行的，工具與手法後來變了很多，所以這篇只引用這份文件對兩種做法的定義與限制。NIST 頁面標示為 Final，未標示撤銷。
| 比較項目 | 弱點掃描 | 滲透測試 |
|---|---|---|
| 做法 | 用工具辨識主機上的作業系統、應用程式與開放的通訊埠，再對照掃描器內的已知弱點資料庫 | 評估者模擬真實攻擊，找出繞過系統安全機制的方法，常對真實系統與資料發動真實攻擊 |
| 能找出的內容 | 過期的版本、缺漏的修補、錯誤的設定 | 多個弱點組合後能取得多大的權限；攻擊者要多高的技術；防守者能不能偵測並回應 |
| 主要限制 | 誤報率高；要有懂網路與作業系統安全的人判讀；只看得到運作中系統的表面；說不出整體風險 | 勞力密集、需高度專業，可能損壞系統，要在通知與規劃後才做 |
兩者是前後接續的關係：滲透測試通常先靠通訊埠與服務辨識、弱點掃描，找出可能的標的。另外，多個低風險弱點組合起來可能變成高風險，掃描器看不出這件事，NIST 認為較可靠的方式是滲透測試。所以標案同時要求兩項並不重複，法規也把兩者分開列，頻率不同。
法規規定的檢測頻率
《資通安全責任等級分級辦法》第 2 條，把公務機關與特定非公務機關的責任等級由高到低分成 A 至 E 五級。第 6 條寫明，維運自行或委外設置、開發資通系統的機關，責任等級為 C 級；A 級與 B 級的情形在第 4、5 條。D、E 級的要求這裡不列。
附表把「弱點掃描」和「滲透測試」列為「安全性檢測」底下兩個獨立項目。同一欄還有網路架構檢視和幾項惡意活動檢視，另外列有「資通安全健診」。標案寫「資安檢測」時，要看清楚指哪幾項。
公務機關的頻率如下。特定非公務機關的附表二、四、六，同級頻率相同。
| 責任等級 | 弱點掃描 | 滲透測試 |
|---|---|---|
| A 級 | 全部核心資通系統每年辦理二次 | 全部核心資通系統每年辦理一次 |
| B 級 | 全部核心資通系統每年辦理一次 | 全部核心資通系統每二年辦理一次 |
| C 級 | 全部核心資通系統每二年辦理一次 | 全部核心資通系統每二年辦理一次 |
表裡最容易讀錯的是「全部核心資通系統」。頻率的對象是核心資通系統，沒有寫成機關的所有系統。哪些算核心，不由廠商決定；附表備註寫，共用性系統由主責設置、維護或開發的機關判斷。初次受核定、等級變更或核心資通系統異動後，自次年度起依附表辦理。
這張表是法規原文。實際照哪一級的頻率做，要看該機關核定的責任等級；標案需求書另有約定的話，以合約文字為準。
配合專案時實際遇到的事
教育部專案的資安檢測是主管機關的要求，由開發團隊配合。開發團隊是系統開發與維運的一方。拿到結果後，要有人看得懂、判斷得出、改得動。
掃描的範圍比標案文字寬
這個專案要配合的掃描，分成網頁、滲透、源碼、第三方元件、授權這幾類。只看標案裡「弱掃」兩個字，容易以為是對主機跑一輪工具，實際上源碼、第三方元件、授權狀況都在範圍內。估工與排程之前，要先問清楚範圍。
掃描結果有誤判，要逐項申覆
主機弱點掃描的結果裡，有誤判的項目。這類項目以申覆處理，一項一項來。這和 NIST 列的限制一致：掃描器誤報率高，會回報不存在的弱點，必須有人判讀。
真的有問題的項目另當別論：掃描結果裡的中、高風險項目，由開發團隊負責修補。
- 主機弱點掃描得到掃描結果
- 有人判讀掃描器誤報率高
- 誤判的項目申覆一項一項來
- 中、高風險項目修補由開發團隊負責
開發團隊的判斷是，這兩件事要寫進合約。判讀誤判要懂這套系統的人，修補要動程式的人，通常是同一個維運方，沒寫清楚就沒有人知道誰先動。
檢測只是資安配合的其中一塊
同一個專案裡，開發團隊配合的資安工作還有這些：
- 資安院弱點通報（VANS）的比對，以及名單上高風險軟體的更新。
- 行政院國家資通安全會報的網路攻防演練：配合填寫自評檢核表與防護軟體安裝情形調查。
- 營運持續計畫（BCP）的還原演練。
- 政府組態基準（GCB）的導入，日誌以 syslog 傳送。
- 端點檢測與防護軟體部署：端點檢測 SOP、防毒軟體安裝與事件處置。
- 資訊安全管理制度（ISMS）表單與稽核文件的維護。
檢測方與開發維運方的分工
開發系統、檢測與出具報告由不同的人做，結果的參考價值才高。系統由開發團隊開發或維運時，檢測由機關或檢測廠商進行，開發團隊配合讀報告、判斷誤判、申覆與修補。這類配合工作可以寫進專案範圍或年度維運，見專案後的維運與資安配合。
委外時，合約前要向廠商確認的事
這份清單是開發團隊的判斷，不是法規條文。標案或主管機關要求弱掃、滲透時，合約前先向廠商問清楚。
- 掃描的執行者：廠商自己跑、機關指定的檢測廠商，或主管機關統一辦理。誰做，決定了後面幾項誰說了算。
- 報告的收件方：交給機關、廠商，或兩邊都有；原始結果和整理過的版本，要寫明誰看得到哪一份。
- 誤判的申覆方：判斷是否為誤判要懂這套系統的人；申覆的窗口與決定權在誰，先講好。
- 修補時限的負責方：中、高風險項目的修補期限，以及延誤算誰的，都要有人承接。
- 施測的環境：測試環境或正式環境，要先決定。NIST 提醒滲透測試可能損壞系統，須在通知與規劃後進行。要在正式環境測，就先講好時段、通知對象與回復方式。
另外要寫明受測範圍，教育部專案就分了好幾類。系統裡若接了 AI 問答這類功能，那一塊是否算受測範圍也要寫進去，背景可以先看RAG 的基本概念。選廠商時的其餘問題，整理在外包軟體的廠商選擇。
手上有標案需求書的話，把寫到弱掃、滲透的段落，透過聯絡頁面寄給開發團隊。開發團隊可以幫忙分清哪些屬於檢測方，哪些由維運方配合。
