去年資安檢測過，今年就安全？系統一變，檢測時鐘就該重算

作者：奧微軟體 AugurSoft。本文由提供資安檢測與軟體開發服務的團隊撰寫，與文中服務入口有商業關係。查核日期：2026-10-11。

公司去年做過資安檢測，報告也收好了。今年網站加了會員功能、後台接了新供應商、雲端搬了主機，老闆問：「不是已經檢查過了嗎？」問題就在這裡：去年檢查的系統，可能已經不是今天正在營運的那一套。

檢測報告不是安全保固書。它記錄特定時間、範圍與方法下的結果；沒有列出某個問題，不等於所有入口、帳號與業務流程都安全。企業真正要問的不是「一年做一次夠不夠」，而是「哪些風險可以照週期追蹤，哪些變更根本不能等到下次排程」。

先把三種工作分開，別只買一個日期

定期弱點檢查、較深入的滲透測試、修補後複驗，回答的是不同問題。弱點管理追蹤已知問題與環境變化；滲透測試則從攻擊者目標檢查防線是否能被突破。CIS 的兩項控制分別談持續弱點管理與模擬攻擊目標，不是同一張年度報告的兩個名稱。CIS Control 7；CIS Control 18。

所以「每天跑掃描」不能直接換成「每天做完整滲透測試」；「今年做過滲透」也不能取代之後的弱點追蹤。至於修補後複驗，目的是回到原問題所在的版本與路徑，確認修正真的生效，而不是重新買一份漂亮報告。

頻率由風險決定，但新風險不能等日曆

NIST SP 800-171 Rev. 3 的 03.11.02 同時列出組織自訂的弱點掃描頻率，以及發現影響系統的新弱點時的檢查。它針對美國受控非機密資訊環境，不是台灣所有公司的法定週期；可以借鏡的是「固定排程加事件觸發」這種管理方式。NIST 官方文件。

實務上，先盤點對外入口、保存的資料、權限敏感度與變更速度，再訂各系統的檢查週期、負責人和例外處理。會員網站、純展示頁與內部工具，不必假裝有完全一樣的風險。法規、客戶合約或產業要求若另有規定，也不能拿一般建議替代；適用性要另外確認。

下面是本文整理的管理判斷表，不是官方統一時限，也不是每次都得重做全站。重點是先找出變動的範圍，再決定必要測試。

最常漏掉的，是「報告之後改了什麼」

假設一家虛構公司的網站去年只開放查詢，今年新增會員匯出。若沿用去年報告，卻沒測會員能否讀取別人的匯出資料，漏掉的不是報告日期，而是新增的授權邊界。這是假設情境，不是客戶事故或實測結果。

每次變更都應留下版本、影響入口、負責人、測試範圍與結論。把「上線了」和「安全相關測試完成」分成兩個狀態；沒有證據就維持待確認，不用一句「應該沒事」替它結案。小變更可以採聚焦檢查，重大架構或權限改動則重新評估範圍。

預算有限，先讓檢測對得上正在跑的系統

先列出最不能出事的服務，再整理自上次檢測後的變更。詢價時交付這份差異清單，比只問「一年一次多少錢」更容易對齊範圍。也要講清楚正式環境測試的授權、時段、禁止操作與停止條件，不能為了找漏洞影響營運。

如果團隊無法判斷網站、內部系統、資料庫與程式源碼哪些變動需要驗證，可以從奧微智盾資安服務討論檢測範圍。既有服務包含 AI 輔助滲透測試與人工驗證、風險分級報告及優先修補建議；奧微是軟體開發團隊，也可協助修補。這不代表提供全天候監控、保證無漏洞或通過特定認證。

下次檢測前，先找出這三個答案

上次報告測的是哪個版本與哪些入口？之後哪些功能、設定或串接改過？誰會在出現新風險時啟動檢查，而不是等年度預算？

把這三個答案寫清楚，檢測才會跟著系統走。去年做過，是歷史；今天是否有證據，才是管理責任。