Keone Hon 推廣 Ultrafuzz，令 Monad 的 OpSec 憂慮成為焦點

Monad 聯合創辦人 Keone Hon 正呼籲開發者採用 Ultrafuzz，同時警告安全不僅是找出合約程式碼中的錯誤。Keone Hon 對 Ultrafuzz 的推廣，將 AI 輔助測試與營運安全（OpSec）結合；後者保護圍繞軟件的帳戶、裝置及流程。這個組合之所以重要，是因為即使合約安全，仍取決於持有管理權限的人。

根據 crypto.news，Hon 於 10 月 30 日分享安全資源，並另外鼓勵開發者以 Ultrafuzz 測試其合約。他的呼籲令一個現有開源項目再次受到關注，並不代表推出新產品，亦不獨立驗證該工具的成效。

核心張力在於自動化調查，以及仍由開發者承擔的營運責任。Trail of Bits 的 Echidna 等成熟工具已會測試合約行為。Ultrafuzz 在這類工作之上加入 AI 協調，而其自身文件亦警告，不應讓不受限制的代理程式接近高價值憑證。考慮採用的團隊必須同時評估它產生的發現，以及安全產生這些發現所需的環境。

Keone Hon 推廣 Ultrafuzz，再次喚起對既有安全工作的關注

眼前的新聞是 Hon 再次呼籲採用，而非推出全新的安全產品。

crypto.news 於 10 月 31 日報道，Hon 在推廣合約測試的同時，亦分享涵蓋員工裝置、憑證、管理權限及第三方帳戶的指引。該報道轉載了他於 10 月 30 日的帖文，並提到他另行邀請開發者使用 Ultrafuzz。這些安全建議將軟件審查置於更廣泛的營運規範之中。

這項區別改變了讀者應如何理解這次公告。新版本發布會引發關於新增功能、遷移要求及與早期版本差異的問題；再次呼籲採用則會引發對採用情況、實際效用，以及現有資源能否觸及所需團隊的疑問。

Hon 的訊息亦把機構有時分派給不同人員的責任連結起來。開發者調查合約行為，其他人員則管理帳戶、電腦及敏感操作的審批。安全結果取決於這些責任如何銜接，尤其當一項管理操作可以改變軟件行為時。

智能合約是在區塊鏈上部署、按既定規則執行的軟件。部分合約亦包含可用於升級或其他管理工作的特權功能。審查規則，以及保護修改規則的權限，應對的是不同的失敗路徑。任何一方面成功，並不代表另一方面亦成功。

這正是為何 OpSec 資料應與測試工具一同出現在報道中。據報 Hon 的建議涵蓋一般工作實務，而非僅是一套專門的 AI 防禦措施。這些內容把焦點引向程式碼完成審查後，支援協議的人員及系統。

報道亦有清晰界線。在本次審閱期間，無法直接取得 Hon 的原始 X 帖文，因此其近期言論仍歸因於轉載相關內容的報道。該工具的公開文件則為其存在及運作模式提供了獨立證據。

單憑這次呼籲，無法衡量有多少團隊採用了該指引，亦不能證明用戶已改變簽署實務，或修正了先前未知的弱點。發布、推廣、使用及證明效益，仍是不同階段。

對讀者而言，有意義的發展是這項結合起來的要求。Monad 正要求建設者更廣泛地調查軟件，同時檢視圍繞該軟件的權限。這些要求會否轉化為行為改變，取決於分享資源清單以外的工作。

壓力落在把審計與日常營運分開處理的團隊身上

Hon 的呼籲將責任放在營運協議的機構身上，包括控制帳戶及管理存取權的人員。

合約審查會調查一個界定清楚的軟件目標。機構則會隨著人員流動、新依賴項、權限變動及工作實務調整，而持續改變。把已完成的審查視為永久的安全狀態，忽略了這些持續進行的決策。

設想一個程式碼已獲審查、且有帳戶獲授權批准升級的協議。若未經授權的人取得該帳戶控制權，審查無法執行機構的批准流程。這個假設例子說明了正確的軟件行為與特權權限的合法使用之間的界線。

同樣的推理亦適用於員工的電腦。開發者可以仔細處理合約邏輯，同時在同一部機器上處理無關的軟件及通訊。即使合約本身完全按預期運作，由此產生的風險仍屬於工作環境的一部分。

報道所述的指引，透過裝置分隔、憑證實務及簽署交易前的檢查，處理這個周邊環境。其建議不依賴新穎的 AI 功能，而是要求團隊明確界定日常責任，並在日常工作中維持這些責任。

這不只對個別開發者帶來壓力，也對創辦人及工程主管帶來壓力。必須有人決定誰可批准敏感操作、哪些裝置支援這些操作，以及如何通報可疑活動。這些決策需要有人負責，而不只是再進行一次自動掃描。

AI 改變了討論方向，因為 Hon 將能力更強的攻擊者視為加強防禦的理由。這是他所陳述的理據，而非證明 AI 導致了某宗特定事件。要確定 AI 參與攻擊，須有關於該次攻擊本身的證據。

即使沒有更強的歸因，營運上的含意仍具參考價值。若團隊採用自動化來增加其安全工作量，仍需要圍繞存取權制定清晰規則。更多調查不會自動減少透過帳戶、裝置或簽署程序暴露的權限。

壓力亦延伸至評估協議的買家及合作夥伴。聲稱軟件已接受自動測試，回答的問題比機構能否安全營運它更狹窄。審閱者需要了解審查了甚麼，以及哪些責任仍在審查範圍以外。

例如，一份關於合約行為的報告，不能證明員工的復原流程已受保護；一項關於帳戶受保護的聲明，亦不能證明會計邏輯能正確處理異常交易序列。當其範圍保持清晰時，兩種說法都可以有用。

這令 Hon 的綜合訊息比單純要求試用工具更具要求。它要求團隊將技術調查與營運問責對齊。實際問題變成是否有人負責這些活動之間的風險，尤其當每位專家都以為由另一人處理時。

Ultrafuzz 圍繞既有測試方法協調調查工作

Ultrafuzz 的主張在於組織安全工作，包括代理程式調查的問題，以及它們在不同階段之間傳遞的證據。

Monad 於 9 月 10 日發布的開源版本說明，其支援 Solidity 和 Vyper，兩者均是用於編寫智能合約的程式語言。該文稱，來自逾 20 次生態系統運行的經驗，促成了這次發布。這些是該基金會對開發過程的說法，而非獨立的保護成效衡量。

模糊測試是一種生成多樣輸入、尋找意外行為的測試技術，構成工作流程的一部分。不變量是系統所達狀態中應一直維持為真的條件。定義這些條件，為調查提供具體的測試問題。

重要的設計選擇出現在生成輸入之前。系統需要對預期行為、相關用戶及有意義的失敗條件作出有用描述。若該描述不完整，大量測試可能會徹底調查了錯誤的問題。

Antonio Viggiano 於 9 月 21 日發布的技術導覽追溯了該項目的起源：協助一個團隊準備外部安全審查。他描述了模糊測試方面的缺口，以及把部分工作自動化的嘗試。他的敘述將 Ultrafuzz 定位為支援安全參與工作的工具。

這個工作流程會先繪製參與者及操作，再調查屬性。以借貸應用程式為例，借款人、貸款人及清算人會透過不同操作互動。理解這些關係，有助調查人員推理涉及一連串步驟、而非個別操作的失敗情況。

這個順序很重要，因為某項條件可能在單一操作後仍成立，卻在多次互動後失效。有用的調查必須考慮系統不斷變化的狀態。為失敗產生具說服力的解釋，仍有別於證明失敗確實發生。

既有測試工具已處理了這個問題的部分環節。Trail of Bits 將 Echidna 描述為基於屬性的模糊測試工具，並將 Medusa 描述為平行智能合約模糊測試工具。其合約測試工具亦包括 Slither，後者無須執行完整應用程式即可檢查程式碼。

因此，這項比較關乎工作流程範圍，而非一場簡單的替代競賽。Echidna 專注測試所提供的屬性；Ultrafuzz 嘗試圍繞目標協調更廣泛的調查，包括準備及解讀工作。機構仍必須評估屬性及所產生證據的質素。

Viggiano 的敘述亦討論了代理程式依賴先前代理程式輸出時的困難。這一點很重要，因為協調式工作流程會繼承錯誤，也會繼承有用資訊。若沒有另一階段提出質疑，流程早期的一個錯誤假設便可能影響後續工作。

對採用者而言，關鍵問題是這種協調能否以較少專業人力產生可供審查的結果。答案需要檢視實際測試活動。一份冗長報告或複雜的工作流程圖，無法證明調查已涵蓋協議最關鍵的失敗路徑。

自動化發現仍需要可重現的證據

要信任一項安全發現，所需證據比產生一項看似合理的警告更具體。

AI 生成的報告可以描述一個真實可信的失敗情況，但不能證明目標系統允許它發生。相反，調查亦可能因其假設排除了相關行為而錯過失敗情況。評估工具時，必須同時留意缺乏支持的發現及被忽略的弱點。

重現程序是可在既定條件下可靠展示所報失敗的測試或程序。對審閱者而言，它將解釋與可觀察行為連結起來。若沒有這種連結，團隊便須投入額外工作，以判斷警告是否適用。

目標修訂版本同樣重要。軟件在開發過程中會有變動，而針對較早版本的發現，未必仍適用於計劃部署的版本。報告需要提供足夠背景，讓另一位審閱者能辨識產生該結果的程式碼與假設。

這些要求同時適用於人手審查及 AI 系統。自動化會增加壓力，因為它產生的候選發現可能多於團隊能即時調查的數量。這類輸出的價值，部分取決於它能否清楚區分已獲證實的失敗與尚未解決的疑點。

因此，有用的評估會追問發現出現後發生了甚麼事。開發人員有否重現問題？團隊有否接受其根本問題？修正措施有否處理已證實的行為？這些問題把自動化發現與工程成果連繫起來。

工具之間的比較同樣需要謹慎劃定範圍。不同的目標、模型選擇、提示詞及可用資源都可能改變結果。若一項比較同時改變多個條件，便無法分辨究竟是哪項設計選擇帶來表面上的改善。

獨立研究為採用問題提供背景。研究 Human Side of Fuzzing 檢視了 381 個涉及 Echidna 及 Foundry（智能合約開發工具組）的 GitHub issues，並探討從業者使用這些系統時遇到的困難。該研究並未評估 Ultrafuzz。

它的相關性在於區分可用技術與可用工作流程。一個工具可以滿足真實的技術需要，但仍可能帶來設定、詮釋及維護工作。評估 AI 協作時，除了發現結果，亦應衡量這些負擔。

這為 Ultrafuzz 建立了公平的標準。其開發人員可以展示有用證據，而無須聲稱完整覆蓋或普遍優勝。範圍清晰的例子、可重現的失敗，以及坦誠描述未成功運行的情況，都有助外界判斷該工作流程在哪些方面帶來貢獻。

相應的懷疑觀點並不要求否定 AI 輔助調查，而是要求避免從「這個系統發現了問題」直接跳到「這個系統確立了安全性」。兩者對證據的要求不同，後者更超出任何單一活動的範圍。

對於評估 Keone Hon 推廣 Ultrafuzz 的團隊而言，實際後果很直接。採用這套工具應產生可供他人檢視及質疑的產物。信心應來自這些產物及其解決過程，而不是參與的代理數目。

不受限制的代理令運行環境成為評估的一部分

Ultrafuzz 自己的警告表明，隔離是負責任評估的先決條件，而非測試開始後才考慮的細節。

該項目的 代理安全警告 建議使用可棄置、隔離的虛擬機器，即與日常工作站分開、以軟件模擬的電腦。警告指出，代理以不受限制的權限運作，亦提醒不要在包含有價值資料或憑證的環境中使用。

這項警告改變了嘗試該工具的意義。開發人員是在允許軟件於某個環境內執行操作，而不只是要求它評論貼上的程式碼。該環境可提供的權限，因而成為評估的一部分。

隔離處理的是非預期操作的後果。它並不能證明每項生成的發現都正確，亦不能證明每個相關的合約行為都獲得關注。即使兩者都會影響一項活動是否有用，運作上的遏制與分析準確性仍是不同的要求。

這個區分同樣適用於機密程式碼。隔離機器可以限制存取無關檔案，同時仍可保存分析所需的敏感項目資料。團隊必須了解這些資料在所選配置的整個流程中會如何被處理。

當機構已有審查外部軟件的規則時，這點尤其相關。安全工具應與其他可存取儲存庫的軟件一樣，接受相同的決策程序。它的防禦用途並不免除理解其權限的需要。

沒有根據可聲稱 Ultrafuzz 曾入侵使用者的工作站。文件化的警告確立的是所述風險與部署界線，不應被轉化成某宗特定有害事件已發生的指控。

更有用的解讀關乎問責。必須有人準備環境、決定哪些內容會進入其中，並審閱產生的結果。活動的自動化階段不會消除這些責任，反而令機器活動與人類判斷之間的交接更為重要。

這正是工具與 OpSec 訴求最直接交會之處。採用 AI 調查合約的團隊，必須對這項調查採取運作紀律。否則，他們有可能把安全工作流程視為自己在其他地方所期望實踐的例外。

對於評估同類產品的機構，這亦有採購層面的含意。部署要求應與支援語言及報告功能一併納入比較。工具是否有用，部分取決於機構能否在其存取與保密要求之內運作該工具。

由此產生的取捨很具體。更高自主性讓代理在無須持續干預下完成更多工作，而環境則必須限制這種自主性的後果。正確的評估應考慮整個活動，包括準備、執行、審閱及處置。

因此，Keone Hon 推廣 Ultrafuzz 不能只根據開發人員是否啟動活動來判斷。更有力的採用訊號，是團隊展示其遵循文件化界線，並對結果保留清晰責任。運行軟件只是善用它的一部分。

留意已驗證的發現、持續使用及運作上的改變

下一批證據應把自動化調查與修正、重複使用，以及對敏感操作更嚴格的管控連繫起來。

第一個值得留意的訊號是可由獨立人士重現的發現。在未來數月，詳細披露或可展示審查了哪個目標、哪種行為失效，以及另一位審閱者如何確認。這類證據將強化工作流程不僅產生候選警告的論據。

獲接受的修正會帶來另一項有用連繫。已公開的發現可以很有意思，卻未必影響已部署的系統。若有證據顯示開發人員理解並修正問題，便能說明發現如何轉化為工程工作。

沒有公開披露並不代表失敗。團隊可能在修正問題時維持發現機密，而披露時間亦可各有不同。不過，這會令外部觀察者較難獨立判斷成效。

第二個訊號是在初步試用後仍持續使用。團隊在程式碼變更後再次使用該工具，所反映的採用訊號與一次性示範不同。重複使用會顯示該工作流程適合持續的開發程序。

當使用者說明所需投入時，這個訊號會更強。關於設定困難、失敗活動、審閱時間及有用輸出的分享，會有助其他團隊評估適合程度。與其只作不加保留的讚揚，清楚交代工作流程在哪裏有幫助，能提供更多實際資訊。

單靠儲存庫關注度無法回答這些問題。公眾興趣可以反映好奇、推廣或研究，而非生產環境使用。當採用主張說明已完成的工作及負責審閱結果的人員時，會更具參考價值。

第三個訊號是技術測試以外的運作改變。遵循 Hon 更廣泛訴求的團隊，會審視特權存取、簽署安排及敏感工作的分隔。這些行動將支持該訊息已超越合約分析範圍的論點。

活動報告無法證明這類改變已經發生。證據需要來自運行相關協議的機構，並對敏感細節作出適當處理。清晰的責任歸屬及文件化程序，會比籠統聲稱重視安全更有意義。

這些訊號測試同一命題的不同部分。已驗證的發現評估分析效用；持續使用評估實際適配性；運作改變則評估更嚴格的測試是否伴隨對管理該軟件系統的更強管控。

對開發人員而言，眼前行動是在啟動活動前，先界定哪些證據足以支持採用該工作流程。確定誰會審閱發現、如何重現失敗，以及哪個環境符合項目的運作要求。對買家及合作夥伴而言，應詢問最終報告實際涵蓋甚麼，以及哪些責任仍在其範圍之外。Keone Hon 推廣 Ultrafuzz 提供了一個有用契機，重新檢視這些問題。閱讀文件化的界線，將其與貴機構的做法比較，並思考下一次安全演練能否同時產生更好的證據，以及更清晰地承擔那些證據無法解決的風險。