網站弱點掃描多久一次？掃描頻率、排程與重新檢測完整指南

先講結論：採用固定排程與事件觸發的雙軌制度

如果網站長期對外服務，至少應有可預期的定期掃描節奏；如果網站經常上版、調整權限或串接新的 API，還要在重要變更後追加檢測。固定排程用來發現新公布弱點、環境漂移與先前未命中的問題，事件觸發則避免團隊等到下個月或下個季度才看到剛被引入的風險。

對一般企業網站，可以先以每月或每季為基準，再依公開暴露、帳號權限、資料敏感度、交易影響與發布頻率提高密度。高風險服務可能需要每週甚至更頻繁的自動化檢測；低變更、低暴露的內容型網站則可採較寬鬆週期，但仍要保留變更後與緊急事件的掃描能力。

頻率本身不是成熟度。若資產清冊不完整、登入流程沒有覆蓋、掃描規則過舊、結果無人處理，天天掃描也只會累積更多未讀警示。排程必須和資產範圍、檢測深度、修復責任、例外管理及複驗流程一起設計。

為什麼一年掃一次通常不夠？

網站不是一年只改一次的靜態資產。程式碼、套件、雲端服務、DNS、憑證、WAF、身分驗證、第三方腳本與 API 權限都會持續變動；即使企業沒有部署新功能，新的 CVE、攻擊技術與掃描規則也可能改變既有版本的風險判定。

一年一次的檢測只能證明某個時間點、某個範圍、某組憑證與某套規則下的觀察結果。若隔天上線新功能，報告就不再代表目前狀態。企業真正需要衡量的是『風險變化多久能被看到』，也就是發生變更或新威脅後，到下一次有效檢測之間的最長空窗。

因此，年度滲透測試、法遵檢測與日常自動化弱點掃描不應互相取代。人工測試適合深度驗證與業務邏輯；排程掃描則以較低的邊際成本維持覆蓋與趨勢。兩者搭配，才能兼顧深度與時效性。

官方標準怎麼說？沒有一個數字適用所有網站

OWASP Web Security Testing Guide 在維運階段建議對應用程式與基礎設施進行每月或每季的定期健康檢查，並強調每次變更經核准、測試且部署到正式環境後，仍應確認安全水準沒有受到影響。這提供的是制度方向，而不是忽略資產差異的固定答案。

NIST SP 800-137 將持續監控定義為持續掌握資安狀態、弱點與威脅，以支援風險決策；其中『持續』並不等於所有控制都要即時檢查，而是依風險決策所需的時效安排足夠頻率。NIST SP 800-171 Rev. 3 也要求組織自行定義弱點監控與掃描頻率，並在發現會影響系統的新弱點時執行監控與掃描。

部分法遵或治理框架會給出明確下限。例如 PCI DSS v4.x 的特定外部 ASV 掃描要求，是至少每三個月取得一次合格結果；CISA BOD 23-01 則要求美國聯邦文職行政機關每 7 天進行自動資產發現，並每 14 天啟動一次弱點枚舉。這些要求適用於各自規範的範圍，不應直接被宣稱為所有企業網站的通用法定頻率。

• OWASP：維運期間進行每月或每季健康檢查，並在每次正式變更後驗證安全狀態
• NIST：依組織風險與決策需要定義頻率，新的相關弱點出現時也要重新評估
• PCI DSS：特定範圍的外部 ASV 掃描至少每三個月一次，並在修復後重新掃描
• CISA BOD 23-01：為聯邦機關設定 7 天資產發現與 14 天弱點枚舉節奏，是高治理要求的實例

決定掃描頻率前，先回答六個風險問題

掃描頻率應由風險和變更速度推導，而不是從工具方案或行事曆倒推。企業可以先替每個網站回答六個問題，再決定基準週期與必要觸發條件。若其中任何一項快速變化，原本的排程就可能需要調整。

最重要的是把技術資產連到業務服務。相同的網站框架弱點，出現在公開形象站、客戶付款入口、員工後台或供應鏈 API，處理時效完全不同。沒有資產擁有者、資料分類與服務重要度，掃描頻率只能依感覺決定。

• 公開暴露：任何人能否從網際網路存取？是否容易被搜尋引擎或掃描器發現？
• 權限與資料：是否處理登入、個資、付款、機密文件、管理權限或跨租戶資料？
• 業務影響：遭竄改、資料外洩或停機時，會影響多少客戶、收入、法規與營運？
• 變更速度：網站、API、套件、雲端設定與第三方服務多久更新一次？
• 威脅活動：是否出現 KEV、新公開利用工具、供應鏈事件或針對同業的攻擊？
• 處理能力：團隊能否確認結果、派工、修復與複驗？過密排程是否只會造成積壓？

建立資產分級：頻率應跟著風險層級走

實務上可以把網站分成關鍵、高、中、低四個層級，並為每一級定義擁有者、固定排程、觸發事件、掃描深度與通報路徑。分級不是永久標籤；當網站開始處理敏感資料、增加外部 API、成為客戶登入入口或進入重要行銷活動，層級也要跟著調整。

下面的頻率是建立內部政策的起點，不是通用法規。企業仍須依契約、產業規範、服務可用性、環境限制與自身風險承受度調整。高風險不一定代表每天進行完整深度掃描；較合理的做法可能是高頻率的安全基線檢查，加上較低頻率的完整登入掃描與定期人工測試。

哪些事件發生後，不應等待下一個固定排程？

事件觸發掃描的目的，是處理兩次固定掃描之間的變化。只要事件可能改變攻擊面、權限邊界、資料流或安全控制，就應進行相應範圍的檢測；不一定每次都要重新掃描整個網站，但必須覆蓋受影響功能與可能的相鄰路徑。

觸發條件應寫進變更管理與事件應變流程，而不是只靠資安人員記憶。部署系統、工單或資產管理平台可以在符合條件時自動建立掃描任務，並把版本、環境、負責人與範圍帶入紀錄。

• 新網站、子網域、API、管理介面或雲端服務首次對外
• 登入、權限、付款、檔案上傳、搜尋、表單或跨租戶流程發生重要變更
• 框架、CMS、外掛、伺服器、容器映像或第三方元件重大升級
• WAF、CDN、TLS、DNS、Cookie、CORS、身分提供者或雲端權限設定變更
• 新的重大 CVE、CISA KEV、供應鏈事件或可用攻擊工具涉及現有技術堆疊
• 資安事件、異常流量、未授權變更或憑證外洩調查後
• 弱點完成修復、套用補償性控制或風險例外到期時

把掃描放進部署流程，但不要讓工具破壞正式服務

現代開發流程可以在不同階段使用不同深度。Pull Request 或測試環境先進行快速安全檢查；正式上線前執行較完整的預備環境掃描；部署後再以安全、受控的方式確認公開版本、標頭、路由與關鍵流程沒有因環境差異產生新問題。

不是所有測試都適合在正式環境自動執行。刪除資料、付款、寄信、建立大量帳號、上傳大型檔案、登出所有工作階段或高負載探測，都可能造成營運副作用。排程前應定義允許方法、速率、測試帳號、禁止路徑、測試資料與停止條件。

成熟的流程會把掃描任務連到可辨識的版本與部署事件。若報告無法指出測的是哪個 Commit、映像版本或發布批次，團隊就難以判斷後續修復是否已包含在正式環境，也難以比較變更前後風險。

掃描頻率之外，覆蓋深度同樣重要

只掃公開首頁，無法代表登入後的會員、後台、訂單、檔案與 API。排程設計應同時記錄匿名與登入範圍、帳號角色、URL 與 API 覆蓋、允許的測試行為、掃描規則版本及被排除區域。若登入失敗或 API 規格匯入異常，結果應明確標記為覆蓋不足。

高頻率的淺層掃描可以快速發現公開配置與基礎攻擊面變化；較低頻率的完整掃描則可投入更多時間探索登入後流程。企業可以採分層排程，而不是要求每一次任務都使用相同深度，藉此兼顧時效、穩定性與成本。

掃描規則也要保持新鮮。CISA BOD 23-01 對適用機關要求弱點偵測簽章在供應商發布後不超過 24 小時完成更新，說明了規則時效的重要性。對一般企業而言，至少要能追蹤掃描器與規則版本，並確認工具有持續取得更新。

風險頻率決策：固定排程、變更觸發與複驗要連成一條線

完整制度會從資產風險決定基準節奏，再以變更與威脅事件縮短空窗，最後由修復複驗關閉問題。這三種任務的目的不同：固定掃描維持可見性，事件掃描驗證新的攻擊面，複驗則確認既有弱點真的不再成立。

團隊不應把所有任務混在同一個排程名稱下。每次掃描都要標示觸發原因、目標版本、範圍、憑證、策略與預期輸出，才能比較結果並追蹤哪一項控制真正降低風險。

修復後多久要複驗？原則是越早證明越好

修復完成不等於弱點已關閉。開發人員可能只修正其中一個路徑、變更尚未部署、快取仍提供舊內容，或防護規則只在部分節點生效。複驗應在修正部署到目標環境後儘快執行，並使用原始重現條件確認問題不再成立。

複驗範圍至少包含原始位置、相同根因的其他位置、必要的角色與租戶，以及正常功能回歸。若是緊急弱點先以 WAF、停用功能或存取限制緩解，仍要記錄永久修復期限；補償性控制通過複驗，只代表暴露已暫時降低，不代表程式缺陷已消失。

批次等待下一個月度掃描才複驗，會讓工單長時間停在不確定狀態。較好的做法是由修復部署事件自動觸發針對性複驗，完成後再由下一次完整排程確認沒有同類問題或回歸。

如何避免排程掃描造成服務影響？

自動化掃描會送出大量非典型請求，某些測試也可能觸發資料寫入、警示、鎖定或第三方費用。對正式環境建立排程前，應先取得資產擁有者授權，確認服務容量、監控與聯絡窗口，並從低速率、小範圍開始驗證。

掃描窗口不一定只能放在深夜。若半夜沒有人能判斷異常、停止任務或處理影響，風險可能更高。合理窗口應考量流量、值班能力、時區、批次作業、備份與發布時程，並保留可立即停止的機制。

高可用服務可以使用分批資產、節流、測試環境先行與金絲雀策略降低衝擊。對工控、醫療設備或其他可能因探測產生安全風險的環境，不能直接套用一般 Web 掃描做法，應由專業人員評估替代方法與補償性控制。

• 合法授權：目標、期間、來源 IP、方法、禁止操作與資料處理方式
• 安全策略：速率、並行數、逾時、登入帳號、排除路徑與最大執行時間
• 可觀測性：系統負載、錯誤率、WAF、應用程式日誌與第三方服務告警
• 應變能力：值班聯絡人、停止條件、Kill Switch、回復方案與事件紀錄

不要只看『執行了幾次』：應追蹤五類營運指標

掃描次數很容易增加，卻無法證明風險變得更可控。成熟制度應同時衡量資產覆蓋、結果時效、驗證品質、修復效率與例外狀態，才能發現真正的流程瓶頸。

指標還要能區分分母。例如『完成 100 次掃描』沒有說明企業共有多少資產；『Critical 平均 5 天關閉』也可能把誤報與風險接受混在一起。每個指標都應定義範圍、時間窗、狀態與資料來源。

• 資產覆蓋率：應掃資產中，於政策週期內成功完成有效掃描的比例
• 變更檢測延遲：重大上線或設定變更到掃描完成之間的時間
• 結果新鮮度：距離最近一次有效掃描的時間，以及掃描規則更新狀態
• 修復與複驗時間：從確認、指派、修復部署到複驗關閉的各階段耗時
• 積壓與例外：逾期弱點、重複發現、風險接受、誤報與未覆蓋資產的趨勢

90 天導入計畫：從最重要的網站開始

企業不需要第一天就讓所有網站每天掃描。比較務實的方法，是在 90 天內完成資產基線、風險分級、固定排程、事件觸發、修復責任與指標，再逐步擴大範圍。優先選擇對外且業務影響明確的少數網站，可以快速驗證流程而不會把團隊淹沒在結果中。

• 第 1–30 天：盤點網域、子網域、API、環境、資產擁有者、登入角色與重要資料
• 第 31–45 天：完成風險分級，定義各級基準頻率、掃描深度、窗口與排除條件
• 第 46–60 天：建立上線、重大設定、新 CVE／KEV、事件與修復完成的觸發規則
• 第 61–75 天：串接工單，定義確認、派工、修復、風險接受、到期與複驗狀態
• 第 76–90 天：檢視覆蓋率、變更延遲、積壓與服務影響，調整頻率後擴展到其他資產

掃描頻率政策檢查清單

以下清單可用於建立內部政策、檢查供應商服務或審查既有排程。只要其中一項沒有答案，企業看到的掃描頻率就可能只是表面數字。

• 是否有完整資產清冊、負責人、環境、公開暴露與業務重要度？
• 是否依風險層級定義固定頻率，而不是所有網站套用同一週期？
• 是否將部署、權限、元件、雲端設定、新威脅與事件列為觸發條件？
• 是否區分快速基線、完整登入掃描、API 掃描、人工測試與修復複驗？
• 排程是否記錄版本、角色、範圍、規則版本、限制與失敗原因？
• 正式環境是否有授權、節流、監控、停止條件與值班聯絡人？
• 結果是否自動指派負責人、期限與複驗，而不是只寄出報告？
• 是否追蹤覆蓋率、變更檢測延遲、結果新鮮度、修復時間與例外趨勢？
• 法規或契約頻率是否被視為最低要求，並依實際風險提高檢測密度？
• 是否定期檢討頻率與掃描深度，避免制度跟不上網站與威脅變化？

最好的頻率，是能在風險空窗與處理能力之間取得平衡

網站弱點掃描多久一次，最專業的答案不是『固定每季』或『越多越好』。企業應以風險分級建立可持續的基準排程，再透過版本上線、新資產、重大設定、新威脅與修復部署觸發額外檢測。這樣才能真正縮短風險空窗，而不是只增加任務數量。

當資產清冊、掃描範圍、結果驗證、修復責任與複驗紀錄連成同一條流程，頻率才有治理意義。先從少數關鍵網站建立一個能穩定運作的節奏，再根據覆蓋率、積壓與服務影響調整，會比一開始追求全面高頻更可靠。