報告要過的是銀行那一關：香港金融科技公司面對交易對手審查時的滲透測試

簡短回答：銀行要的這份滲透測試報告，並不是寫給你看的。讀它的人是對方第三方風險團隊裡的一位分析師——他需要在清單上打一個勾，並且日後能為這個勾辯護。讓報告被接受的，是與對方關注點相符的測試範圍、明確寫出的方法論、可復現的證據，以及帶日期的修復與複測記錄，而不是發現問題的數量。

為什麼一家 28 人的金融科技公司，會被銀行要求提交滲透測試報告？

設想一家綜合性的、用於說明情況的香港金融科技公司。全公司 28 人，大約一半是工程師。產品是一個面向企業客戶的支付與對帳平台：企業客戶通過 API 把自己的財務系統接進來，平台負責匹配收付款、標記異常、推送結算指令。整門生意都離不開一家合作銀行——銀行開立客戶資金帳戶、提供支付通道，而且越來越希望用 API 直連，而不是靠上傳文件。

商務條款幾個月前就談妥了。隨後，開戶與接入流程轉到了銀行的第三方風險團隊，然後卡在了一份安全問卷上。大多數問題，技術負責人一個下午就能答完：靜態數據是否加密、生產環境訪問是否強制多因素認證、密鑰怎麼保管、誰有權限部署。只有一行完全答不上來。那一行要求提供最近一次由獨立第三方執行的滲透測試報告，覆蓋本次合作所涉及的系統，且報告日期在過去十二個月之內。

公司從來沒有做過滲透測試。融資前曾經用一個免費掃描器掃過官網，雲服務商自帶的安全面板大部分也是綠色的。可這兩樣都不是滲透測試，也都不是獨立的。銷售團隊已經向三家企業客戶承諾了上線日期，距離現在只剩八週。創始人的第一反應是：找最便宜、能出一份 PDF 的測試。技術負責人的第一反應是：買錢能買到的最徹底的測試。事實證明，這兩種直覺都瞄錯了讀者。

這種情況在香港金融科技圈已經常見到有了固定的形態：團隊很小，對方有正式的准入流程，截止日期由別人定，而那份文件要求聽起來簡單，其實並不簡單。本文要講的，就是這份文件實際上要完成什麼任務。

這和為上線、為監管、為保險做測試有什麼不同？

同一項服務——滲透測試——回答的問題，取決於誰來讀它的結果。如果觸發點是你自己的上線日期，測試是為你自己做的：你想在客戶發現之前知道哪裡會出問題，這個時間規劃的問題我們在對著 App 上線日期安排滲透測試一文中討論過。如果觸發點是發牌監管機構，問題就變成：你是否多年持續運行一套有維護的測試計劃，這是一家香港支付公司沒料到的滲透測試要求一文的視角。保險公司在續保時，通常更想看到持續的安全衛生證據，而不是一次性的深度測試。

交易對手和這三者都不一樣。銀行不是你的監管機構，無權檢查你；也不是你的保險公司，不會把你的風險折算成保費。它是一家正在決定是否把自己的系統和聲譽接到你身上的企業，它的風險團隊有一條政策：擁有這種訪問級別的第三方，必須提供獨立的安全測試證據。這份報告就是那份證據。它會被歸檔，可能會被內部審計抽查，而接受它的那位分析師，個人的名字就記錄在這次接受上。這一點改變了報告需要包含的內容。

實際讀這份報告的是誰？他在找什麼？

想像一下這位讀者。銀行第三方風險或資訊安全部門的一位分析師，同時手上有幾十個供應商和合作方盡職調查在跑。他大概率不會復現你的漏洞利用過程，甚至可能根本不會打開技術附錄。他讀報告時找的是四樣東西，通常按這個順序。

第一，測試是否覆蓋了與這次合作相關的系統。如果銀行要調用你的 API，而你的報告只測了公司官網，那麼無論報告多幹淨，都與這次審查無關。第二，測試是否由獨立方執行、是否採用公認的方法、是否在他們政策要求的時間窗口內。第三，發現了什麼、嚴重到什麼程度——特別是有沒有被評為嚴重或高危、至今仍未關閉的問題。第四，你對這些問題做了什麼，以及有沒有人核實過。

請注意，這張清單上沒有的是：發現問題的總數。一份有四十個低危觀察項、並且修復記錄清楚的報告，比一份只有三個發現、卻看不出後續處理情況的報告更容易被接受。一份零發現的報告反而可能引來疑問——有經驗的分析師知道，一次真正圈定了範圍的線上 Web 應用測試，幾乎總會發現點什麼；結果一片空白，會讓他懷疑到底測了什麼。

分析師還得寫下點東西。他的內部記錄大致會是這樣一句話：“合作方提供了日期為 X 的獨立滲透測試，範圍覆蓋 Y，無未關閉的嚴重或高危問題，修復已於 Z 日核實。”如果你的報告讓這句話裡的每一個空都很容易填上，審查就會走得很快。如果分析師得回信問你測了哪些範圍、某個高危問題修好沒有，你就損失了一週——在只剩八週的截止日期面前，一週很重要。

一份讓交易對手接受的滲透測試報告，需要具備什麼？

去掉排版格式，幾乎所有工作都由四個要素完成。缺了其中任何一個，往往就會招來追問；四個都齊全，報告通常就會被直接歸檔。

範圍說明是否與對方關注的內容一致？

範圍說明是風險分析師第一頁認真讀的內容。它應該用對方能認出的方式列出被測系統：銀行將要對接的生產 API 端點、面向客戶的 Web 應用、承載這些服務的環境的外部邊界，以及任何可能觸及客戶數據的管理界面。它應該說明測試的是哪個環境——生產環境，還是與之一致的預發佈環境；如果是後者，要說明為什麼它有代表性。

同樣重要的是，要寫明哪些不在範圍內、為什麼。“企業內部辦公網絡不在範圍內；與生產環境無網絡連通”——只要屬實，這是一句完全可以接受的話。讀起來糟糕的是沉默，因為沉默逼著分析師去猜，而猜恰恰是他不被允許做的事。

方法論是明確寫出來的，還是靠對方去推斷？

分析師需要看到，測試遵循的是公認的方法，而不是臨場發揮。對於 Web 應用和 API，通常意味著要寫明：測試覆蓋了 OWASP Top 10 各類別及以上內容；採用的是黑盒（測試人員事先不掌握內部資訊）還是白盒（測試人員拿到了文檔、帳號或代碼）；使用了哪些測試帳號和角色；以及測試進行的日期和時間段。

黑盒還是白盒，是一個有實際後果的選擇。黑盒告訴你一個外部人員能做到什麼。白盒加上每個用戶角色的認證訪問，能告訴你多得多的東西——恰恰是銀行真正擔心的那件事：你的某個企業客戶，能不能通過你的 API 看到甚至挪動另一個客戶的錢。對一個多租戶支付平台做交易對手審查，對 API 做認證後測試通常是更有用的證據。

一個不在場的人，能復現這些證據嗎？

每一個發現都應該附有概念驗證證據：發出的請求、收到的響應、必要時附截圖，並且細節足夠讓一位沒有在場的合格工程師復現出來。每個發現都應該按公認標準給出風險評分——常用的是 CVSS——再加上一段用普通語言寫的業務影響說明，以及分步驟的修復指引。

這對交易對手之所以重要，原因與你的工程師無關。可復現的證據，是區分真實測試與“為了應付問卷而生成的文件”的關鍵。如果分析師看到的是一串模糊、沒有證據的發現，他無從分辨二者，只能按後者來對待這份報告。

有沒有帶日期的修復與複測記錄？

這是小團隊最常漏掉的要素，因為它發生在測試人員離場之後。銀行想看的報告，不只是最初的發現，而是最初的發現加上一份記錄：哪些已經修復、何時修復、並且有獨立的人核實過修復。實際操作中，這要麼是一份更新版報告，多了一列修復狀態；要麼是一封單獨的複測函，按編號引用原始發現，逐條記錄為已關閉、部分關閉或已接受風險。

沒有這份記錄，分析師看到的就是一份列著你平台漏洞的清單，卻沒有任何證據表明它們已經消失。從交易對手的角度看，這比完全沒做測試還糟糕，因為現在對方的存檔裡多了一份寫明已知弱點的文件。

該測什麼？哪些東西交易對手很少要求？

大部分成本和大部分價值都是在劃定範圍時決定的，所以值得就本文場景中這類平台，把常見的候選範圍逐一過一遍。

• 外部網絡邊界。承載產品的環境中，一切從互聯網可達的東西：負載均衡、API 網關、VPN 接入點、暴露在外的管理端口、被遺忘的子域名。幾乎總在範圍內；一次聚焦的外部測試，是最小的、可信的工作單元。
• Web 應用與 API。面向客戶的應用，以及最重要的——銀行將要調用、企業客戶正在使用的 API。對支付平台來說，這是報告的核心：身份認證、租戶之間的授權隔離、輸入處理，以及業務邏輯層面的濫用，例如重放或篡改結算指令。
• 雲配置。存儲權限、身份與訪問策略、日誌、生產環境與其他一切之間的網絡隔離。通常與外部測試一起審查，而不是單獨做一次，而且小團隊真正的風險敞口往往就在這裡。
• 內部網絡。假設已被入侵的測試——如果攻擊者進入了一台員工手提電腦或一台內部服務器，他能橫向走多遠？對於生產環境完全在雲上、辦公網絡與之不通的金融科技公司，這一項在本次審查中的優先級可能較低；如果辦公網絡可以直達生產環境，那就不是了。
• 人員。社會工程與釣魚模擬。有價值，而且越來越多真實事件正是從這裡開始的，但審查技術對接的交易對手，很少把它列為準入條件。值得做；但通常不是解開這份問卷卡點的那一項。

實際的原則是：把範圍圈定在觸及這次合作及其所承載數據的系統上，再加上對方問卷中明確點名的內容。如果問卷寫得含糊，就直接問銀行的風險對接人，他們希望看到哪些系統被覆蓋。一封郵件，就可能省掉一次測錯對象後的返工。

為什麼最便宜的掃描過不了關，最貴的項目又做過了頭？

場景裡的創始人和技術負責人，各對了一半。成本確實重要，徹底性也確實重要。但問題不是“測多少”，而是“哪一種測試能產出這位讀者需要的證據”。

自動化掃描 vs. 圈定範圍的滲透測試 vs. 範圍過大的項目

• 自動化漏洞掃描：快、便宜，作為週期性控制措施確實有用。它按特徵庫檢查已知漏洞和錯誤配置。它測不了你的業務邏輯，判斷不了租戶 A 能否讀取租戶 B 的交易，產出的是機器生成的報告，沒有人對可利用性做出判斷。大多數要求滲透測試的交易對手風險團隊不會接受用掃描代替，而交上一份掃描報告，往往會讓你在後續審查中失去信譽。
• 圈定範圍的滲透測試：由人來執行，範圍與這次合作相匹配，方法論明確寫出，對掃描器標記出來的和它看不到的問題都進行人工利用，發現帶 CVSS 評分和概念驗證證據，幷包含修復與複測環節。這才是問卷真正在要的東西，對這種規模的平台來說，通常能在時間線內完成。
• 範圍過大的項目：完整的紅隊演練、大規模社會工程、物理入侵、每一個內部網段。其中一些本身很有價值。但對這位特定讀者來說，大部分都是噪音——分析師會直接翻到 API 和外部邊界的章節——而多出來的範圍會把日程拖過截止日期，把預算推到一家 28 人公司不該為一份文件花的程度。

圈定範圍的測試，不是另外兩者之間的折中。它是唯一一個瞄準了讀者的選項。

應該如何從截止日期倒推時間線？

從銀行需要最終文件的那一天往回倒推，而不是從你希望測試開始的那一天往前排。對於本文場景，距離截止還有八週，計劃大致如下。

第一週用於劃定範圍和簽約：與銀行確認他們希望覆蓋哪些系統，與服務商商定範圍和測試窗口，為每個角色準備測試帳號，並確保生產環境的負責人知道測試何時進行。標準滲透測試的設計原則是不干擾業務運行，需要時可以把測試窗口安排在非辦公時間，但測試進行期間，你這邊仍然得有人能隨時聯繫上。

測試本身的時長取決於範圍。大致來說，一次聚焦的外部網絡測試通常需要三到五天；外部、內部加 Web 應用的完整項目通常需要兩到三週。服務商應當在提案階段就給出時間與範圍估算；沒有這一項的提案，不要籤。

接下來是所有人都低估的部分：修復。你的工程師需要實實在在的時間去修復發現的問題、測試修復效果、再部署上線。如果測試在第四周結束，而銀行在第八週要文件，那麼在複測之前，你大概只有兩到三週的修復時間。修幾個嚴重問題夠用；如果發現的是 API 中結構性的授權問題，就不夠了。這正是接下來兩節之所以重要的原因。

為什麼複測是小團隊最容易忘記談的那一部分？

幾乎每一個第一次採購的人，都把注意力放在測試本身，把複測當作細節。可在交易對手看來，恰恰是複測把一份問題清單變成了“風險可控”的證據。

簽約之前，要弄清三件事：複測是否包含在內，條件是什麼？初次報告出具後，最晚多久可以安排複測？複測產出的是什麼——一份修訂版報告，還是一封引用原始發現編號的獨立函件？

作為參考，Brocent 的年度測試套餐包含在初次發現修復之後的一次複測，用以確認漏洞已被關閉、且沒有引入新的問題。如果你向任何一家服務商購買的是一次性項目，不要預設複測包含在內。去問，拿到書面答覆；如果不含，就在測試開始之前把它談進工作說明書——此時談遠比在發現結果出來、截止日期只剩兩週時再談要容易得多。

還要約定由誰來做複測。由你自己的工程師做的複測，不是獨立證據。由執行原始測試的同一家服務商、對照它自己的發現編號來核查，形成的記錄最乾淨。

截止日期前修不完的發現，該怎麼辦？

有時候，誠實的答案是：某個問題沒法在期限內徹底修好。一個深層的授權問題，可能需要重新設計數據模型裡租戶之間的隔離方式；一個過時的組件，可能綁定在一次你無法控制的供應商升級上。這時的誘惑是希望分析師看不出來。他會看出來的，而由此造成的信任損失，會比那個問題本身更大。

行得通的做法由三件事組成。第一，一項能立刻降低風險的補償性控制——把受影響的端點限制為只接受銀行的 IP 段、在網關上增加一道授權檢查、在重建完成前暫時關閉某項功能，或者針對攻擊者必須採取的那種特定行為加強監控。第二，複測應當核實這項補償性控制，並把該發現記錄為“已緩解”而不是“已關閉”。第三，一份帶日期的修復計劃：要做什麼、由誰做、何時完成、如何提供證據——最好再承諾在完成後分享一次進一步的複測結果。

風險團隊對此早已習慣。他們不能接受的，是一個沒有計劃的未關閉嚴重問題，或者一份沒有日期的計劃。一個已緩解、有監控、定好六週內修復、並且有具體負責人的高危問題，在合作方的審查記錄裡是很正常的。

這份報告能拿給下一個交易對手用嗎？

在本文場景中，銀行是第一個提出要求的交易對手，但不會是最後一個。企業客戶、第二家合作銀行、某個支付網絡、潛在投資人，都可能在一年之內問同樣的問題。最好從一開始就為此做好準備。

完整的技術報告是敏感文件——說到底，它是一張“你的平台是怎樣被攻擊的”地圖。大多數服務商和大多數交易對手都預期它只在保密協議下分享，有些項目條款還會限制向其他方轉發。在把報告發給任何人之前，先查一下你和測試服務商之間的合同。一種常見且合理的做法是維護兩份文件：完整報告，只發給真正需要技術細節的一方；以及一份由服務商出具的執行摘要或證明函，寫明範圍、日期、方法論和修復狀態，但不含漏洞利用細節。很多審查方會接受摘要，只有當其中某一點引起疑問時，才會索要完整報告。

複用也有時效。一份在三月份被接受的報告，到了第二年二月未必還能被接受——如果你的平台在此期間上線了重大變更，或者下一個交易對手的政策要求六個月內而不是十二個月內的測試。把被測平台的日期和版本記錄下來，等這個問題來了，你才答得上。

如何把一次性測試變成年度循環？

第一次測試幾乎總是在壓力下買的。第二次不應該這樣。一旦你知道某個交易對手關係要求獨立測試，你就知道明年它還會要求，而且很可能每次你對接口做了重大變更時也會要求。

年度循環有一個可預期的節奏：每年在同一時間點商定範圍、測試、修復、複測，把更新後的報告和摘要歸檔，再向需要的人通報。它也會改變經濟帳。每年測試同一個平台的服務商，會逐漸熟悉它的架構，花在摸底上的時間更少，花在變化部分上的時間更多。你的工程師會知道哪幾類問題反覆出現，並從源頭修掉。而交易對手每年收到的報告，會從一張快照變成一條趨勢線——這正是風險分析師真正想看到的。

也正是在這個節點上，包含修復後複測的年度套餐，會比每次從頭談一個項目更划算。Brocent 的滲透測試服務覆蓋外部網絡、內部網絡（假設已被入侵後的橫向移動）、針對 OWASP Top 10 及以上內容的 Web 應用測試，以及社會工程與釣魚模擬，並提供黑盒與白盒兩種方式；每一個發現都附有 CVSS 風險評分、概念驗證證據、業務影響說明和分步驟的修復指引。

但年度測試說到底仍是某一時點的一張照片。決定明年那張照片好不好看的，是另外五十一週裡發生了什麼。

常見問題

漏洞掃描和滲透測試有什麼區別？

漏洞掃描是對已知漏洞和錯誤配置的自動化檢查。滲透測試是由人主導的、嘗試利用弱點的過程，包括掃描器看不到的業務邏輯缺陷，並提供實際可以做到什麼的證據。掃描是很好的週期性控制措施；但一個要求滲透測試報告的交易對手，通常不會接受用掃描代替。

一次滲透測試需要多長時間？

取決於範圍。一次聚焦的外部網絡測試通常需要三到五天；外部、內部加 Web 應用的完整項目通常需要兩到三週。在此之前要留出劃定範圍的時間，在此之後要留出修復和複測的時間；要從交易對手的截止日期往回倒推，而不是從今天往後排。

報告會是英文的嗎？

把報告語言明確寫進工作說明書，而不是想當然。如果交易對手的風險團隊以英文工作，報告就應該從一開始用英文撰寫；事後翻譯的報告，可能恰好在分析師讀得最仔細的地方——範圍、嚴重程度、修復狀態——引入歧義。

複測是否包含在內？

取決於你買的是什麼。Brocent 的年度測試套餐包含在初次發現修復之後的一次複測。對於任何一次性項目，無論向哪家服務商購買，都要在測試開始之前書面確認是否包含複測、條件是什麼；如果不含，就把它談進去。

報告能分享給不止一個交易對手嗎？

通常可以，但需要在保密條款下進行，並且要先查看你與測試服務商之間的合同。實際做法是：執行摘要或證明函可以較廣泛地分享，完整技術報告只給需要細節的一方。記錄好誰收到了哪個版本。

如果發現了嚴重問題怎麼辦？

能修的先修，通過複測核實修復效果；對於來不及修的，部署補償性控制，並寫下一份帶日期、有具體負責人的修復計劃。如實披露。一個已緩解、已排期的問題，在合作方的審查記錄裡很正常；一個被隱瞞的問題則不是。

多久應該重新測試一次？

只要該交易對手關係仍要求獨立測試，至少每年一次；此外，在範圍內系統發生重大變更之後也要測試——新的 API 版本、新的部署環境、重大的身份認證調整。也要核對交易對手自己的政策，有些要求的間隔短於十二個月。

報告由誰簽署？

由測試服務商簽署，而不是你。報告應當寫明服務商、測試日期、報告版本以及測試負責人；任何證明函或複測確認，也應當由服務商以自己的名義出具。自己簽署的文件不是獨立證據——而獨立，正是對方提出這項要求的全部意義所在。

讓明年的報告保持乾淨的工作，究竟在哪裡完成？

回到本文的場景。這家金融科技公司拿到了報告，修掉了大部分發現，緩解了其餘的，銀行完成了對接。十二個月後，同樣的問題又來了。第二份報告是輕鬆還是痛苦，幾乎完全取決於這中間發生了什麼——而其中與滲透測試有關的部分少之又少。

第一次測試裡的大多數發現並不稀奇：一個沒打補丁的組件，一條管理路徑上沒有強制的多因素認證，一個權限比預期寬的存儲桶，一項偏離了基線的配置，一個沒人盯著的已知漏洞。這些都不需要一年一次的測試來發現，它們需要的是每週都有人盯著。

這種週期性的安全衛生，正是管理型IT外判服務存在的意義。Brocent 按用戶計費的管理型IT外判服務方案建立在五大支柱之上——7×24 小時 NOC 監控、多語種服務台、安全治理、備份與災難恢復，以及 vCIO——每個方案都包含 BCS Beam 終端代理：一項只讀的安全與健康審計，按 CIS 對齊的基準檢查設備，依據 CVE、CVSS、EPSS 以及 CISA 已知被利用漏洞清單對漏洞進行優先級排序和持續關注，並跟蹤補丁狀態。需要更多保障的企業，可以通過管理型安全服務把這套能力延伸到專門的檢測與響應。Brocent 2007 年創立於北京，2016 年起設立香港辦公室，2021 年起總部設在新加坡；我們的金融服務客戶，經常要面對這類交易對手審查。

香港地區的方案價格按每用戶每月公開：Startup（1–5 名員工）HK$855.14，Established（5–300 名）HK$1,247.40，Growth（10–500 名）HK$1,561.21，Enterprise 按需報價。一支 28 人的團隊選擇 Established 檔，按公開價格計算為每月 HK$34,927.20——換來的是讓下一份報告變短的那些日常工作。完整明細請見價格頁面，或者聯繫我們，一起為今年的測試劃定範圍，並談談怎樣讓明年的測試更輕鬆。

測試是一張照片。而方案，決定了沒人拍照的時候，你是什麼樣子。