滲透測試不是交報告就結案！企業安排 PTS 前必定的 5 大範圍與驗收條件
企業編列預算安排 PTS（Penetration Testing Service，滲透測試） 時，最常踩的坑就是把採購目標單純設定為「拿到一份評估報告」。
但現實很骨感：測試報告只代表當下的檢查快照，並不等於企業風險已經有效降低。 若前期沒有界定測試資產、缺乏明確的授權邊界，事後也沒有追蹤修補與複測機制，往往花了大筆經費，最後依然無法向董事會、稽核單位或供應鏈客戶交待：「我們到底測了哪些核心資產？發現的弱點誰來修？什麼時候才算真正驗收結案？」
想讓每一筆資安預算轉化為實質防禦力，企業在簽約發包 PTS 前，務必先定好以下 5 大核心範圍與驗收條件。
1. 盤點具體測試資產，避免「通用掃描」帶過關鍵業務
不要在需求規格書上只寫籠統的「網站滲透測試」。
在評估報價前，企業應先將預計受測的數位資產逐一條列，包含：對外網域、公用 IP、後端 API 節點、行動 App、雲端管理後台、測試專用帳號以及第三方金流或物流串接，並清楚標註是「正式上線環境（Production）」還是「測試驗證環境（Staging）」。
明確的資產清單能帶來兩大效益：
- 防止漏測死角： 避免廠商只測了形象官網，卻漏掉串接核心資料庫的後端 API。
- 鎖定核心商業邏輯： 若系統涉及身分登入、金流付款、權限提權或敏感個資存取，應直接列為「重點必測情境」，要求資安專家進行深度的邏輯驗證，而不是拿自動化工具掃一掃就交差。
2. 把授權邊界、測試時段與緊急煞車機制白紙黑字化
滲透測試本質上是「模擬真實黑客的攻擊手法」，只要涉及具攻擊性的封包測試，就存在服務負載上升或誤觸警報的風險。因此，合約中必須寫明白以下作業邊界：
- 明確授權清單： 明列合法授權人、滲透測試團隊的來源 IP（Whitelist IP）、指定測試時段（如：離峰深夜或一般上班日）。
- 禁止攻擊手法： 清楚界定是否排除阻斷服務攻擊（DoS/DDoS）、破壞性寫入資料庫或社交工程釣魚測試。
- 緊急停止窗口（Kill Switch）： 萬一正式機台出現效能瓶頸或服務異常，雙方即時通報的負責窗口是誰？誰有權限立即下令暫停測試？
若是租用 AWS、GCP 或 Azure 等公有雲服務，亦須確認是否符合雲端業者的滲透測試規範，避免引發平台端風控阻擋或合規爭議。
3. 依業務風險決定測試深度，拒絕「只看人天」的無效測試
許多企業在採購時常陷入「這家報價 5 個人天，那家報價 8 個人天」的迷思。然而，測試重點從來不是天數多寡，而是測試手法的深度與涵蓋面。
不同風險等級的模組，應配置不同的驗證深度：
- 高風險核心資產： 涉及金流交易、管理員後台、會員認證與敏感 API，必須依循 OWASP Top 10 等標準，著重在「人工邏輯驗證」、「身分越權漏洞（BOLA/IDOR）」及「業務流程繞過」。
- 低風險資訊展示頁： 一般靜態宣傳頁面，則可採取標準檢查，將預算集中在真正會造成營運損失的攻擊路徑上。
在比價與挑選廠商時，記得詢問團隊的人工複驗比例與商業邏輯測試經驗，才能確保預算花在刀口上。
4. 規範可落地的交付證據，兼顧 IT 修正與稽核舉證
一份實用的滲透測試交付報告，不該只有高深難懂的專有名詞，而是要能讓不同角色各取所需：
- 給開發與維運團隊（IT / RD）： 必須提供詳細的漏洞重現步驟（PoC）、請求封包截圖、精準受影響路徑與具體的修補代碼建議，讓工程師能立刻著手修復。
- 給管理層與外審稽核（CISO / Auditor）： 需具備執行摘要（Executive Summary）、整體資安風險評級，並在報告中妥善去識別化或遮蔽敏感機密。
建議在發包前就與廠商約定報告範本，確認是否包含完整的測試方法說明與時間戳記，避免日後拿去應付主管機關或國際供應鏈客戶審查時，被要求重新補件。
5. 將「漏洞修補」與「免費複測」列為最終驗收標準
收到測試報告絕不是專案的終點。從「發現漏洞」到「完成修補並通過複測」，才是完整的資安防護閉環。
在專案驗收條件中，應明確約定以下項目：
- 內部修補時限（SLA）： 依弱點嚴重度（重大、高、中、低）訂定內部修復優先序。
- 複測範圍與次數： 合約內應包含至少一次針對原始弱點的免費複測服務（Retest），確認漏洞確實被阻斷且沒有衍生新問題。
- 結案證明文件： 廠商需出具載明複測日期與修復狀態的「複測結案證明」，作為內部資安治理及外部稽核的合規紀錄。
常見問題快速解答（FAQ）
延伸閱讀
讓每分滲透測試預算，轉化為真正擋得住攻擊的實戰防線
做滲透測試不是為了買一張漂亮的及格證明，而是為了看清系統真正的破綻在哪裡。在正式發包前，把資產範圍、授權界線、深度要求、證據格式與複測條件先梳理清楚，才能在確保營運不中斷的前提下精準補強，向管理層與客戶展現紮實的資安治理成效。