採購單上寫的是「滲透測試」，交來的報告卻可能只是弱點掃描器匯出的清單換了封面；也有公司連資產清冊都還沒建好，就先買了紅隊演練。弱點掃描、滲透測試與紅隊演練名稱相近，回答的卻是三個不同的問題，所需的人力、價格、頻率與驗收方式也都不一樣。買錯了，錢花了，真正想知道的事情還是不知道。
這篇寫給要編列預算、撰寫採購規格或驗收測試報告的 IT 人員與主管：先說明三者（以及台灣法規定義的資安健診）各自找得到什麼、找不到什麼，再整理法規要求的最低頻率、發包前要寫清楚的範圍與交戰規則、怎麼判斷一份報告的品質，以及如何把結果接進修補流程。
三種測試，各自回答不同的問題
弱點掃描：自動比對已知漏洞
弱點掃描用工具辨識主機、作業系統、應用程式與開放的連接埠，再和掃描器資料庫裡的已知漏洞比對，找出過時的軟體版本、缺少的修補與錯誤設定[1]。它快速、可以大量重複，適合定期而全面地掌握「已知問題」的暴露程度[1]。採購時要分清兩個維度：
- 外部或內部：外部掃描從組織邊界之外（通常是網際網路）看進來，會被防火牆擋住，只能掃到允許通過的連接埠；內部掃描通常會發現比外部更多的弱點，NIST 認為兩種視角都重要[1]。
- 未驗證或已驗證：未驗證掃描不帶帳密，看到的就是沒有帳密的外部攻擊者看得到的東西；已驗證掃描（authenticated／credentialed scan）以具權限的帳號登入，可以看到設定、已安裝軟體與權限，發現的弱點多得多[2]。
掃描的盲點也很明確：
- 只看得到運作中的系統，依賴每次掃描前都要更新的特徵資料庫；誤判率高（回報不存在的弱點），也會漏報，結果需要懂網路與作業系統安全的人判讀[1]。
- 找不到必須串連多個弱點才能利用的風險：每個弱點單獨看都是低風險，合起來可能是高風險[1]。
- 掃描器給的等級不等於你的風險。NIST 舉例，掃描器可能因為 FTP 以明文傳送密碼而標為中風險，但如果那台 FTP 只是不需要密碼的匿名公開伺服器，實際風險可能低得多[1]。
- 業務邏輯與客製化程式的問題。OWASP 指出自動化工具不會創意思考，例如一個藏在 30 個字元參數值裡的管理後門，掃描器幾乎不可能猜中[3]。
滲透測試：由人在範圍內實際攻擊
NIST 對滲透測試的描述是：評估者模仿真實攻擊，找出規避應用程式、系統或網路安全機制的方法，常常會用攻擊者慣用的工具與技術，對真實系統與資料發動真實攻擊[1]。和掃描最大的差別在於，多數滲透測試會尋找可以串連的弱點組合，取得單一弱點做不到的更高權限；它也可以用來了解防守方能否偵測並適當回應[1]。測試可以模擬外部攻擊者（只拿到目標 IP 範圍，從公開資訊開始蒐集），也可以模擬已在內網、具一般員工權限的內部人員，嘗試一路提權[1]。
滲透測試同樣有侷限：
- 人力密集、需要高度專業，也可能讓系統受損或停擺，這個風險無法完全消除[1]。
- 本質上是抽樣。OWASP 引述 Gary McGraw 的看法：滲透測試只能找出所有可能風險中一小部分具代表性的樣本；網頁應用程式多為客製開發，網頁滲透測試更接近研究工作[3]。
- 不能取代掃描。PCI 安全標準委員會（PCI SSC）明確表示滲透測試不是弱點掃描，兩者互補，前者不能取代後者[2]。
紅隊演練：以目標為導向，考驗偵測與應變
依 NIST 詞彙表引用的定義，紅隊演練是在貼近真實的條件下，模擬對手試圖破壞組織的任務或業務流程，以全面評估組織與系統的資安能力[4]；紅隊的目的是展示攻擊成功會造成的影響，以及哪些防禦在實際運作環境中真的有效[5]。換句話說，紅隊演練的範圍通常是一個目標（例如取得財務系統的付款權限），而不是一張 IP 清單。NIST SP 800-115 所說的「隱蔽測試」（covert testing）接近這種做法：只有高階主管知情、IT 人員不知道，用來檢驗技術控制、IT 人員面對疑似事件的反應，以及員工對政策的落實；它要看的是對手能造成多大損害，不會測試每一項控制，也不會找出每一個弱點[1]。因為要放慢動作避免被察覺，隱蔽測試往往耗時又昂貴[1]。
美國 CISA 公開過一次紅隊評估的經過：2023 年對一個聯邦民政機關進行未事先通知的長期模擬，紅隊利用一台未修補網頁伺服器上的已知漏洞，以及網路釣魚取得初始存取，最後拿下整個網域，還透過信任關係跳到外部合作機構；在整個第一階段，防守方都沒有偵測到紅隊[6]。這種結論是掃描報告給不了的，它衡量的是「被打進來之後，你多久會發現」。
資安健診：台灣法規定義的檢查項目
資安健診是《資通安全責任等級分級辦法》附表中的應辦事項，項目包括網路架構檢視、網路惡意活動檢視、使用者端電腦惡意活動檢視、伺服器主機惡意活動檢視，以及目錄服務系統設定及防火牆連線設定檢視；A、B 級另外包括核心資通系統資料庫安全檢視[7]。它看的是架構、設定，以及環境裡是否已經有惡意活動；弱點掃描與滲透測試則在附表中另列於「安全性檢測」項下[7]，彼此不能互相替代。想定期檢視整體架構、設定與流程，可以參考資安健檢服務。
怎麼選、多久做一次
先確認要回答哪個問題
- 「我們有哪些已知漏洞、修了沒有？」選弱點掃描，而且要定期、全面。
- 「攻擊者能不能從這個入口打進核心系統？」選滲透測試，範圍明確、由人執行。
- 「真的被入侵時，我們會不會發現、擋不擋得住？」選紅隊演練，前提是已經有監控與應變機制可以被檢驗。
NIST 的建議是定期執行網路與弱點掃描，中間穿插週期性的滲透測試；滲透測試成本高、對系統影響大，NIST 認為每年一次可能就足夠[1]。如果資產清冊與例行掃描都還沒有，先把基礎做好再考慮紅隊：SP 800-115 指出，隱蔽測試通常就是利用最基本的弱點取得網路存取[1]，花大錢只會證明一件例行掃描早就能告訴你的事。
資通安全責任等級分級辦法的最低頻率
適用《資通安全管理法》的公務機關與特定非公務機關，要依責任等級辦理分級辦法附表的應辦事項；現行版本於2026年1月7日修正發布[7]。公務機關與特定非公務機關在同一等級的頻率相同[7]：
- A 級：全部核心資通系統弱點掃描每年兩次、滲透測試每年一次；資安健診每年一次。
- B 級：全部核心資通系統弱點掃描每年一次、滲透測試每兩年一次；資安健診每兩年一次。
- C 級：全部核心資通系統弱點掃描與滲透測試都是每兩年一次；資安健診每兩年一次。
- D 級：沒有這三項要求，只要求啟用防毒軟體與網路防火牆，並完成教育訓練。
附表另規定，這些項目從初次核定、等級變更或核心資通系統異動後的次年度起辦理；特定非公務機關辦理資安健診時，也可以改採中央目的事業主管機關認可、具同等以上效用的其他措施[7]。適用對象與其他義務，見資通安全管理法重點整理。
不在名單上的民間企業，也可能透過委外契約承擔測試義務：《資通安全管理法施行細則》第7條規定，受託業務包括客製化資通系統開發時，受託者應提供安全性檢測證明；屬委託機關核心資通系統或委託金額達新臺幣一千萬元以上者，委託機關應自行或另行委託第三方進行安全性檢測[8]。
PCI DSS：處理信用卡資料的企業
PCI DSS 第 4 版第 11.3 與 11.4 節的要求如下[9]：
- 內部弱點掃描至少每三個月一次，重大變更後也要執行；高風險與重大弱點要修復，並重新掃描確認[9]。
- 內部掃描須採已驗證掃描，無法接受帳密的系統要記錄在案[9]；PCI SSC 說明這是 4.x 版新增、2025年3月後強制的要求[2]。
- 外部弱點掃描至少每三個月一次，由 PCI SSC 認可的掃描廠商（ASV）執行[9]；通過的條件是 CVSS 分數 4.0 到 10.0 的弱點都已修復[2]。PCI SSC 也強烈鼓勵比每三個月更頻繁地掃描[2]。
- 內部與外部滲透測試都至少每 12 個月一次，重大基礎設施或應用程式升級、變更後也要執行；可由內部或外部的合格人員執行，但須具組織獨立性[9]。
法規之外的觸發點
法規給的是下限。美國 CISA 的約束性營運指令 BOD 23-01 要求聯邦民政機關每 7 天做一次自動化資產探索、每 14 天對所有發現的資產做一次弱點列舉，並盡可能使用具權限的帳密[10]。相較之下，每兩年一次的掃描或許能通過稽核，對日常修補卻遠遠不夠。除了固定排程，新系統上線前、重大改版或架構變更後（PCI DSS 也把重大變更列為掃描與滲透測試的觸發點[9]）、新增對外服務、併購，以及資安事件復原後，都應該安排測試。
發包前：寫清楚範圍與交戰規則
NIST 定義的交戰規則（Rules of Engagement，ROE），是在測試開始前訂定、規範測試執行的詳細準則與限制，讓測試團隊不必另外取得許可，就能執行已定義的活動[1]。SP 800-115 附錄的 ROE 範本，可以直接當作採購規格的檢查表[1]：
- 目標與排除清單：列出授權測試的 IP、網域與應用程式，也列出明確不得測試的系統[1]。拿到公有 IP 清單時，測試前要先確認這些位址確實屬於組織[1]；使用雲端服務、對外 IP 會變動的環境更要逐一核對。
- 測試類型與時段：外部或內部、是否已驗證、是否提供測試帳號、要模擬外部攻擊者還是內部人員；營運中的系統可能要安排在離峰時間測試[1]。
- 允許與不允許的活動：例如是否允許社交工程或實體入侵、可否在系統上建立、修改或執行檔案，以及測試結束後如何處理這些檔案[1]。掃描器的阻斷服務類測試可以整批關閉，以降低影響主機的風險[1]。
- 停止條件與緊急聯絡：測試影響到系統，或剛好遇上真正的攻擊時，何時停止、通知誰；附上事件應變的聯絡鏈[1]。
- 資料處理：測試資料如何蒐集、保存、傳輸與銷毀；測試結果正是攻擊者想要的資訊，應視為敏感資料[1]。
- 回報與簽核：每份報告至少要包含什麼、多久回報一次（例如每日狀態報告）；至少由測試團隊負責人與組織高階主管簽署，確認雙方理解範圍與界線[1]。
也要求廠商記錄每一項測試的時間、類型、工具、指令與測試設備的 IP[1]，系統出現異常時才釐清得了是不是測試造成的。紅隊演練則可以指定可信任的第三方居中協調，讓防守方發現可疑活動時，先確認是不是測試，再決定是否啟動應變[1]。
驗收報告：怎麼分辨好壞
OWASP 認為，一份好報告要同時讓高階主管與技術人員看得懂[11]。驗收時逐項確認：
- 範圍與限制寫清楚：報告應載明範圍、測試期間與限制，例如沒有帳號或憑證、時間不足、部分功能故障[11]。測試結果只代表某個時間點，不保證找出所有問題[11]。沒有寫範圍與限制的「未發現高風險」，等於什麼都沒說。
- 誤判已經排除：自動化工具的發現通常要驗證才能排除誤判，人工檢查比用第二套工具交叉比對更準確[1]。OWASP 也提醒，附錄裡的工具輸出要整理過，不要原封不動傾倒[11]；整份報告就是掃描器輸出時，代表這一步沒做。
- 證據可以重現：每項發現都應包含理解、重現與修復所需的資訊，包括編號、可利用性、影響、利用方式與修補步驟，敏感資料要遮蔽[11]。你的工程師照著步驟做，應該能重現。
- 風險等級連到業務影響：不能直接沿用掃描器的等級[1]。報告應考量利用難度、是否已有可用的利用程式、需要的權限與對系統的影響，並在附錄說明各等級的判定方式；管理摘要則用業務語言說明合規、商譽等影響[11]。
- 有根因與修補建議：每項發現都應有根因分析與修補建議，包括技術面（例如套用某個修補）與流程面（例如改善修補管理流程）[1]。
- 包含複測：PCI DSS 要求滲透測試發現的可利用弱點依風險修正後，重新測試確認[9]；複測報告也應整理前次發現的最新狀態[11]。採購時把至少一次複測寫進合約。
把結果接進修補流程
測試結果的用途，是作為矯正行動的依據，以及追蹤改善進度的基準[1]。報告交件不是終點，接下來要做的是：
- 匯入資產清冊與工單系統：每項發現指定負責人與修補期限，和既有的掃描結果合併去重。
- 用暴露面與利用情資排序：PCI SSC 也強調，嚴重度沒有情境就不等於風險，建議結合 KEV 與 EPSS[2]。完整的排序方法與修補時限，見修補管理：漏洞修不完時，如何排出優先順序；各種分數的意義見看懂漏洞編號與分數。
- 修完要驗證：可以參考 PCI DSS 的做法，高風險與重大弱點修復後重新掃描確認，其他弱點依目標風險分析處理[9]；不要把工單關閉當成修好。
- 紅隊結果轉成偵測能力：CISA 的紅隊評估發現，以「已知惡意特徵」為主的偵測方式，讓防守方漏掉了其他手法；受測機關要分析主機、內部網路、對外流量與身分驗證日誌，才完整掌握紅隊入侵的範圍，CISA 因此建議偵測以行為為主，而不是只比對入侵指標（IOC）[6]。IOC 的用法與限制，見如何使用通報中的 IOC 比對自己的環境。
如果內部沒有人力判讀掃描結果、排除誤判並排出修補順序，可以參考弱點掃描與評估服務。
行動清單
- 把過去三年的測試報告拿出來，確認每一份實際上是掃描、滲透測試還是健診，涵蓋了哪些系統、有沒有複測。
- 確認公司是否適用資通安全責任等級分級辦法、委外契約或 PCI DSS，列出每項測試的法定頻率與下一次到期日。
- 建立比法規更密的內外部弱點掃描排程，內部掃描改用已驗證掃描，並把無法使用帳密的系統列冊。
- 發包滲透測試前，用 SP 800-115 的範本寫好交戰規則：目標、排除清單、允許活動、時段、停止條件、聯絡窗口與簽核。
- 在合約中寫明報告必須包含範圍與限制、重現步驟與證據、連到業務影響的風險評等、根因與修補建議，以及至少一次複測。
- 新系統上線前、重大變更後安排測試，不要只等年度排程。
- 有了監控與應變機制之後再做紅隊演練，演練後把沒被偵測到的手法逐一轉成偵測規則。
- 追蹤漏洞類通報，把正在被利用的漏洞列為下一次掃描與測試的重點。