弱點掃描與資安檢測，由具備資格的第三方執行。這篇談的是報告交到開發這一端之後的工作：哪些發現是真問題，哪一條先修，哪些是誤判而需要申覆，修完之後留下什麼證據讓複測能夠逐條確認。NIST SP 800-115（Scarfone 等，2008）是資安技術測試與評估的參考，涵蓋找出系統與網路弱點的技術性測試；這類測試怎麼執行、怎麼判定，屬於測試單位的專業。弱點掃描與滲透測試的差別另有專文說明，這裡不重複。
誤判一定會有，也不能跳過
自動化掃描依特徵、版本字串與回應內容判斷，對系統實際的設定與業務邏輯所知有限。同一個請求，在掃描工具眼中像是攻擊，在系統裡可能只是一筆正常的表單送出。報告裡的誤判難以完全避免。
誤判不能因此直接跳過。Sadowski 等，2018整理了 Google 建置靜態分析工具的經驗，指出誤報會讓使用者不信任分析結果；程式碼審查中的檢查，準則是有效誤報低於 10%。Johnson 等，2013訪談開發者後發現，誤報與警告的呈現方式，是開發者不使用靜態分析工具的主因之一。這兩份研究談的是靜態分析工具，不是弱點掃描報告，但誤報消耗信任的方式可以借來參考：報告裡混著沒處理的誤判，其餘發現也會跟著被打折扣。
所以誤判要逐條處理：確認是誤判、寫下理由、整理成申覆，而不是略過不看。磨人開發團隊配合教育部專案時，工作內容包含配合主管機關要求的掃描、修補中高風險、誤判申覆。
分清真問題與誤判
每一條發現，開發這一端要能回答三個問題：這個問題在這套系統上是否真的存在，被利用需要什麼前提，修補之後怎麼證明。分類就是替每一條找到這三個答案。分類結果與申覆內容，由業主確認後再往下走。
- 重現：在測試環境照報告記載的請求重送一次，比對回應與報告是否相符。
- 對照：報告指出的版本、路徑與標頭，確認是否真的屬於這套系統，而不是前端的代理、舊版服務或其餘主機。
- 前提：確認利用這條發現需要登入、特定權限，或只有內網才能到達。
- 判定：每一條標為真問題、誤判或無法判定，並寫下理由；無法判定的，回頭向出具報告的單位要求補充資料。
分工示意；實際分工依各專案的合約與機關要求而定。
依可被利用的程度排順序，不依分數高低
報告上的嚴重度分數是排序的起點，不是終點。同樣標為中風險，一個在對外開放的登入頁，一個在只有內網才能到達的管理介面，被利用的難度差很多。OWASP Top 10，2025是專家共識整理出的網頁應用程式最嚴重安全風險清單，2025 年版為目前最新版；發現屬於哪一類風險，可以先對照這份清單，再看這套系統上的實際條件。
| 排序時看什麼 | 對順序的影響 |
|---|---|
| 能不能從外部到達 | 對外網址上的發現，排在只有內網才能到達的前面 |
| 利用需要什麼前提 | 不需登入就能利用的，排在需要特定權限的前面 |
| 影響的範圍 | 牽涉個人資料、帳號或整個服務的，排在只影響單一頁面的前面 |
| 現有的緩解措施 | 已有其餘防護擋住利用路徑的，可以排後，但要寫下判斷的依據 |
排完順序，每一條發現的去向可以歸成三種：立即修補、排入下一輪，或提出申覆。
- 重現這條發現在測試環境照報告的請求重送
- 對照系統的實際設定版本、路徑與現有緩解措施是否與報告相符
- 可重現，且能從外部直接利用立即修補修補前後各留一份請求與回應的對照
- 可重現，但需要特定前提，或已有緩解措施排入下一輪記錄前提與排後的依據
- 無法重現，或與系統的實際設定不符提出誤判申覆附上重現過程與設定證據
修補不是裝上一個套件
一批資安修補若在同一天加入標頭防護設定與全域的輸入清洗套件，輸入清洗等相關設定容易在不久後被關閉：全域清洗會改寫使用者送出的內容，與富文本這類正常內容互相衝突。
這類情況說明，修補要針對問題的成因，而不是加上一個看起來有防護作用的元件。磨人開發團隊的取向是輸出編碼、內容安全政策與明確的白名單：內容進入頁面的那一刻，依所在位置編碼；用政策限制瀏覽器可以執行的來源；可接受的輸入以白名單定義，而不是事後整批改寫。
密碼條文逐條落地，容易漏的是另一條路徑
檢核表上的密碼條文，單看每一條都不難實作：長度、字元規則、更換期限、不得與帳號或前幾次密碼相同。密碼規範分批落實時，容易漏的不是條文本身，而是另一條登入路徑：一般登入先套用了初始密碼的判斷，第三方登入若沒有同步判斷，規則就只落實了一半。
- 註冊與修改密碼
- 一般登入時的初始密碼與更換期限判斷
- 第三方登入
- 重設密碼的流程
- 後台管理介面與 API 兩邊的規則
- 前端的規則說明文字
做法是用檢核表，把每一條規則對應到每一條登入路徑，而不是只改註冊頁。後端的判斷為準，前端的提示同步更新，兩邊對規則的說明保持一致。
後端關掉開關，不等於前端不再依賴
驗證碼的答案不能由伺服器回給瀏覽器。若報告指出回應裡帶有驗證碼的值，修補要在兩端同時收尾：後端不再輸出，前端也不再讀取。只關掉後端的開關，前端仍在取用那個欄位，問題就只修了一半。
確認有沒有修乾淨，要從兩端看。後端這一端，確認回應內容裡已經沒有那個欄位；前端這一端，確認程式不再讀取，而且欄位消失之後，畫面與流程仍然正常運作。兩端都確認，這一條才能標為已修補。
範圍邊界要在開工前寫下
報告涵蓋的系統，可能包含運行多年的舊程式。本輪要修的，是報告列出並經分類確認的發現；舊系統裡其餘既有的問題，先記錄在清單上，不趁機翻修。但新寫的程式不得新增任何風險。這一條要在開工前寫進文件，由業主與開發團隊共同確認：本輪涵蓋哪些發現，哪些既有問題只記錄、不更動，新程式遵守什麼規則。沒有寫下來，範圍會在修補過程中逐漸擴張，每一次改動都得重新討論。新寫的程式至少守住以下幾條：
- 資料庫查詢一律參數化
- 涉及個人資料的存取，查詢條件要包含擁有者，例如同時比對資料編號與使用者編號
- 外部系統的回呼一律驗證簽章
- 機密不進版本庫；記錄與狀態訊息裡不印出原文，只比對雜湊或印出長度
複測要留下什麼證據
公部門的委外專案，法規把選任與監督受託者列為機關的責任。資通安全管理法，2025第 10 條要求公務機關與指定的非公務機關，在委外建置、維運資通系統或提供資通服務時，選擇適當廠商、要求其維持有效的資安管理機制並加以監督，並以書面契約約定權利、義務與違約責任。資通安全管理法施行細則，2026第 7 條規定，選任與監督受託者應考量人員配置、複委託、客製系統的安全測試、事件通報與契約終止時的資料處理等事項，並須定期稽核受託者，或於得知事件時查核。
對廠商這一端，這代表修補的每一個決定，事後都可能需要說明。公部門專案的維運證據另有專文整理；就弱點掃描報告而言，複測之前，每一條發現都要有對得上的證據。
| 報告上的狀況 | 複測前要能拿出的證據 |
|---|---|
| 已修補 | 修補前後同一個請求的回應對照，以及變更的位置與核可的人 |
| 誤判 | 重現過程、系統的實際設定，以及判定為誤判的理由 |
| 暫不修補 | 風險由業主接受的決定、現有的緩解措施與理由 |
| 不在本輪範圍的既有問題 | 範圍清單上的記載，說明為何沒有更動 |
複測由具備資格的第三方執行，開發這一端的工作，是讓每一條都有證據可以對上。修補是否到位，可以對照 OWASP ASVS，2025：這是供開發者在建置、撰寫程式與測試網頁應用及服務時對照的應用程式安全驗證需求清單。每一條修補都對照同一份清單，就不會各自用不同的標準判斷。
不適合的情況
- 手上還沒有掃描或檢測報告。這篇談的是拿到報告之後；掃描與檢測要先由具備資格的第三方進行。
- 目標是一次翻修整套舊系統。本文的做法把報告列出的發現與既有問題分開處理，不是重寫計畫。
- 只要求報告上的分數降到某個水準，卻不處理實際風險。排序依可被利用的程度，不依分數。
聯絡前先準備的資料
- 報告全文，包含每一條發現的編號、嚴重度，以及受影響的網址或元件
- 掃描的範圍與環境，是正式站還是測試站
- 系統的技術架構概況，以及目前負責維護的人員
- 已知暫時不動的舊系統範圍，以及合約或機關對修補範圍的要求
- 要求回覆的期限，以及複測由誰、何時進行
備齊以上資料之後，可以聯絡磨人開發團隊，說明報告的來源與目前的處理進度。由開發團隊承接的修補與申覆，屬於系統維運與修補這一端；掃描與複測仍由具備資格的第三方進行。
