用Claude對自己的原始碼做敵意測試

簡而言之： 讓模型「審查一下這段程式碼」，你會得到一份客客氣氣的總結。讓它在一個具體的信任邊界上、去打破一個具體的假設，你才會得到值得分診的發現。兩者都只花五分鐘，但只有一個有用。讓它奏效的紀律是：任何你沒有重現過的發現都不算數。讓它正當的紀律是：這是你自己的程式碼、你自己的系統、並且你有授權。

大多數軟體從來沒有被人蓄意攻擊過。它被寫它的人審查過，跑過建置流水線裡的那些檢查，然後就上線了——而它遇到的第一個真正帶著敵意的讀者，並不站在你這邊。

由合格的人來做的滲透測試是這件事的正確答案，而它要花真金白銀、也要排真實的檔期。在「什麼都不做」和「正式立案一次委託」之間，還有一個便宜的中間步驟：花一個下午，用一個非常擅長讀陌生程式碼、並擅長就「它會怎麼壞」提出假設的模型，去攻擊你自己的程式碼。做對了，這能找出真實的缺陷。而按多數人的做法去做，它什麼也找不到，還讓所有人感覺安心了——那比不做更糟。

下面的一切都假定：程式碼是你的、系統是你的，或者你持有所有者的書面授權。這不是走形式——它是資安工作與另一回事之間的那條線，而且值得在動手之前就拿到白紙黑字，而不是在有人問起之後。

為什麼「讓AI審查一下這段程式碼」幾乎什麼也找不到

問題出在提示詞上，不在模型上。

它沒有目標，於是它去最佳化涵蓋面。 被要求「審查」時，它回傳的是那些對任何程式碼都永遠成立的東西：錯誤處理可以更好、這個函式太長、建議加測試。全都對，但沒有一條是漏洞。

它不知道哪些輸入是攻擊者可控的。 沒有信任邊界，一個字串就只是一個字串。同樣的串接，出現在一個啟動指令碼裡無關緊要，出現在一個請求處理函式裡則是嚴重問題，而檔案本身沒有任何東西告訴模型它正在看的是哪一種。

除非你另外交代，它預設是順著你的。 「這看起來安全嗎？」是一個邀請你被安慰的問題，而你會如願。框架必須讓「找到問題」成為成功的結果，而不是尷尬的結果。

孤立地看一個檔案，恰恰丟掉了要緊的那部分。 誰呼叫了它、帶著什麼、代表誰、在哪些檢查之後——這些脈絡活在程式碼庫的別處，而只審查這個檔案，就是在審查一個片段。

敵意框架改變了什麼

怎樣提示Claude去攻擊一個假設，而不是總結一個檔案？

用一句話說出你想被打破的那個假設，然後要求它推翻。不是「審查這段驗證程式碼」，而是「這個端點假定呼叫方只能引用屬於自己組織的訂單ID——找出所有能讓這個假定不成立的路徑」。一次只打一個假設。目標越窄，輸出越可用。

要一條可利用路徑，而不是一個結論。 一條發現應該以序列的形式到達：這個輸入、在這個狀態下、由這個角色發出、產生這個結果。沒有路徑的主張，是一個打扮成發現的猜測；而「要路徑」這個動作本身，就能在你動眼之前濾掉相當一部分。

給它「找不到」的許可。 明確地說：就這段程式碼而言、針對這個假設「找不到可行的攻擊」，是一個可接受且有用的回答。不這樣說，那片空白就會被填滿。

讓它對照你自己的模型排序。 問它：這些發現裡，攻擊者真正會先試哪一條、為什麼。它給出的理由往往比排序本身更有資訊量，而且能暴露出模型在哪裡誤解了你的架構。

哪些脈絡才真正改變答案？

四樣，而它們的缺席正是多數嘗試失敗的原因。

信任邊界——攻擊者可控的資料從哪裡進入，以及系統對這條線兩側的資料分別相信什麼。驗證與授權模型——呼叫方的身分如何被確立、權限在哪裡被檢查、檢查被跳過時會發生什麼。資料模型——什麼是按租戶隔離的、什麼是按使用者隔離的、什麼根本沒有隔離。威脅模型——一個有十二個具名使用者的內部工具，和一個公開註冊表單，值得完全不同的關注度。

把這些給它，它就在對你的系統推理。不給，它就會憑空造出一個看著合理的架構，然後審查它自己造的那個。

一次實作的敵意排查，逐步拆解

在提示任何東西之前，先建立目標模型

花半小時寫下：進入點、角色、每個角色被允許做什麼、你最不願意丟的資料在哪裡，以及那三個「一旦發現是錯的、你會最難受」的假設。這份文件是整次排查的執行基準，而且即使你就此打住它也有價值——多數團隊從沒把它寫下來過，而這本身就是問題的一部分。

一次只跑一個攻擊假設

按邊界、按假設逐個來。一個涵蓋十個關注點的提示，會在十個上面都回傳淺層輸出；一個只涵蓋一個的提示，回傳的是你能動手的東西。把範圍控制在「合在一起才講得通」的程式碼上——一個處理函式，加上它依賴的中介軟體和資料存取，而不是整個儲存庫；整個儲存庫放不下，就算放得下也會稀釋注意力。

刻意地更換攻擊者。一個未驗證的陌生人、一個屬於另一個組織的已驗證客戶、一個權杖尚未過期的前員工，以及一個能重放自己一小時前合法發出過的請求的人——這是同一段程式碼的四種讀者，而他們找到的東西不一樣。

分診：沒重現之前，什麼都不算數

每一條發現只能貼一個標籤。已重現意味著你真的讓那件壞事發生了——在測試裡、在本機執行個體上，並且步驟寫了下來。已推翻意味著你順著路徑追過了，它不存在。資訊不足是一個暫存區，不是一個結論；一條在那裡待了一週的發現，是一條沒人相信的發現。

只有已重現的那些才變成工作。這條規則在第一輪時會顯得嚴苛，而它正是這整件事值錢的全部原因。

敵意AI審查 vs 靜態分析 vs 真正的滲透測試

成本 — AI審查完勝。它的價格是一份訂閱加一個下午。
程式碼涵蓋的廣度 — 靜態分析勝出。它在每一次建置上跑過所有東西，不需要誰來決定該看哪裡。
對意圖和商業邏輯的理解 — AI審查明顯勝出。掃描器無法知道「這條退款路徑本就不該被客戶走到」；一個對照你的目標文件推理的模型可以。
誤報負擔 — 靜態分析和AI審查都輸，只是輸法不同。掃描器產出大量機械式誤報，你會學會過濾；AI審查產出的更少，但可信得多。
跨服務的鏈式利用 — 滲透測試完勝。把一個薄弱的重設流程和另一個服務裡的資訊洩漏組合起來，是有經驗的測試者會做的事，而另外兩者根本不嘗試。
能拿給客戶或稽核看的保證 — 滲透測試勝出，而且差距很大。一份合格測試者出具的報告是證據；一段聊天紀錄不是。

請把它讀成一個序列而不是一份菜單。先AI審查、再靜態分析、最後委託，意味著那個昂貴的步驟不會被花在「你本來免費就能找到的東西」上。

誤報問題

流暢、可信的散文是模型最強的輸出，也是你最大的成本。有兩種失敗模式要緊，而它們在紙面上長得一模一樣。

第一種，是一條準確地描述了某個真實漏洞類別的發現，而程式碼其實並不那樣做——模型比對到了一個形狀，然後把後果敘述了出來。第二種，是一條技術上正確卻不可達的發現，因為上游三層的一個檢查早已把它擋住了。兩者讀起來都自信、具體、令人警覺。

還有一項人們會漏掉的代價：一個被你*修掉*的誤報，比一個被你忽略的誤報更糟。你改動了本來正常的程式碼、花掉了一次審查，還帶著「系統比原來更安全了」的信念走開。請先重現。永遠如此。

這件事永遠抓不到什麼

執行時和基礎架構的錯誤設定。 權限設錯的物件儲存空間、對全世界開放的安全群組、還掛著預設憑證的管理後台——這些都不在原始碼裡。

任何你沒有提供的程式碼，其中包括你所有的相依套件。

跨服務的鏈式利用。 那個單獨看無害、卻能把一次困難攻擊變成容易攻擊的資訊洩漏，活在兩個系統之間的縫隙裡，而你是分開審查它們的。

外部人才看得出的商業邏輯濫用。 定價邊界情況、退款流程、多步驟工作流裡的競態——其中一部分在程式碼裡看得見，而最有價值的那些例子，只對「在想商業而不是在想檔案」的人可見。

你的建置流水線和金鑰處理，除非你刻意把它指過去，而幾乎沒人這麼做。

這份清單，正是「這能取代滲透測試嗎」的誠實答案是「不能」的原因，而把這句話說出來本身就是論點，不是免責聲明。

把這件事做對：原始碼保密、授權，以及何時該讓IT介入

在這變成日常之前，有三件事要先定下來。

第一，授權。你自己的程式碼、你自己的系統；如果其中任何一部分屬於客戶，請在動手之前拿到書面許可。當你走到「這些發現需要獨立驗證」的那一步——或者客戶、保險公司、稽核方要的是證據而不是保證時——那正是由持證測試者進行的滲透測試所提供的，包括開箱式（白箱）委託：測試者拿到架構細節，用和本文一樣的方式工作，只是附帶了責任。

第二，保密。原始碼通常是一家公司最敏感的資產，而這套工作流會把它送出你的環境。請讀一讀你所用那個具體產品層級的資料處理與訓練條款，而不是靠假設，因為商業版和企業版通常與消費級不同，條款也會變。把憑證從你要貼上的任何東西裡剝掉——而如果含有有效金鑰的程式碼已經進過任何外部工具，請輪替那個金鑰，而不是去推理它是否被留存。

第三，這些發現之後怎麼辦。已重現的缺陷應該進到你其餘工作被追蹤的地方，並附上重現步驟；我們那篇把支援工單變成結構化缺陷報告講的正是這個書寫問題。我們的AI+支援服務幫你把這類工作建在公司帳號和受治理的權限上，而不是某個開發者的個人登入上；我們的託管IT支援則涵蓋這次排查往往會暴露出來的憑證輪替和權限衛生。Brocent自2007年在北京創立以來，一直在亞洲提供託管IT與資安服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

把專有原始碼傳給AI模型安全嗎？

這取決於層級和業者，而且這是一個應該刻意去做、而不是預設發生的決定。請核對你所用那個具體產品當前的資料處理與訓練條款，優先選擇條款就是為此而寫的商業版或企業版，並把任何已被貼上過的金鑰視為已外洩。對真正敏感的系統，請限定離開你環境的範圍，而不是貼上整個儲存庫。

它的發現裡通常有多少是真的？

預期第一輪裡大部分是雜訊，並且不要相信任何給出普適數字的人——這高度取決於你的提示方式、你的程式碼庫，以及你提供了多少脈絡。要緊的是測量你自己的比率：把「已重現」對「已推翻」記錄幾輪，你很快就能看出你的框架有沒有奏效。

這能取代滲透測試嗎？

不能。它只審查你給它看的程式碼、別無其他；它無法在它沒見過的系統之間串聯發現；而它的輸出不是任何人會接受的證據。它是一種便宜的方式，讓你在為昂貴的那一步付錢之前，先把明顯的問題找出來修掉——而這恰恰讓昂貴的那一步更值。

我們能把它跑進CI嗎？

把它當作對變更程式碼的一道閘口，比當作對整個儲存庫的掃描要好得多。拿一份diff對照「與這次變更相關的安全假設」來審查，是有界而有用的；而在每次建置上跑一次無界的敵意排查，大約一週就會造成告警疲勞，最後以所有人徹底忽略它收場。

一條我們重現不出來的發現該怎麼辦？

把它連同推理一起留在一份清單裡，等相關程式碼變動時再回頭看。不要修它、不要向上呈報、也不要讓它變成一個任務——一條未重現的發現是一個假設，而把假設當成缺陷來處理，正是團隊對這整件事失去信心的方式。

模型需要拿到整個程式碼庫才有用嗎？

不需要，而且把所有東西都給它通常會讓輸出更糟。有幫助的是那一「片」對的東西——你正在測試的邊界、它的呼叫方、以及中間的那些檢查——外加你寫下來的目標模型。這裡精準勝過體量，這也正是「一次一個假設」比「一次掃一遍」更管用的原因。

從哪裡開始

挑那個「一旦失效後果最糟」的假設：通常是「一個使用者不能觸及另一個組織的資料」。用一句話把它寫下來，把那個處理函式以及它一路呼叫到資料庫為止的所有東西收集起來，然後要求給出所有能讓它不成立的路徑。接著，在告訴任何人之前，先把回傳的東西重現一遍。把一個邊界做扎實，比把整個儲存庫審一遍能教給你更多關於你自己系統的事，而且它給了你一個可以複用到下一個邊界的形狀。如果你更希望讓持證測試者來驗證這項工作，或者把它暴露出來的憑證與權限衛生問題妥善處理好，歡迎與我們聯絡。