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 issue，并调查了从业者在使用这些系统时面临的困难。该研究并未评估 Ultrafuzz。

它的相关性在于区分“可用技术”与“可用工作流”。一项工具可以满足真实的技术需求，同时仍带来配置、解读和维护方面的工作。评估 AI 协作时，除发现结果外，也应衡量这些负担。

这为 Ultrafuzz 建立了公平的评价标准。其开发者可以展示有价值的证据，而无需声称覆盖完整或普遍优越。明确界定范围的示例、可复现的故障，以及对未成功运行的坦诚描述，都有助于外部人士判断该工作流在哪些环节带来贡献。

相应的怀疑立场并不要求否定 AI 辅助调查。它要求避免从“该系统发现了问题”直接跳到“该系统证明了安全性”。这两种说法对证据的要求不同，而后者的范围超出任何单次活动。

对于正在评估 Keone Hon 推动的 Ultrafuzz 的团队而言，实际结论很直接。采用该工具应产生可供他人检查和质疑的产物。信心应来自这些产物及其解决过程，而非参与其中的代理数量。

不受限制的代理使运行环境成为评估的一部分

Ultrafuzz 自身的警告表明，隔离是负责任评估的前提条件，而非测试开始后才考虑的细节。

该项目的代理安全警告建议使用一次性、隔离的虚拟机，即与日常工作站分离的软件模拟计算机。警告指出，代理以不受限制的权限运行，并提醒不要在包含高价值数据或凭据的环境中使用。

这项警告改变了尝试该工具的含义。开发者是在允许软件在某个环境中执行操作，而不只是要求它对粘贴的代码发表评论。该环境中可用的权限因此成为评估的一部分。

隔离可以应对非预期操作带来的后果。它并不能证明每项生成的发现都正确，也不能证明所有相关的合约行为都得到了关注。即便两者都会影响一次活动是否有用，运行时隔离与分析准确性仍是不同的要求。

这一差异也适用于机密代码。隔离的机器可以限制对无关文件的访问，同时仍持有分析所需的敏感项目材料。团队必须了解这些材料在所选配置中如何被处理。

当组织已有审查外部软件的规定时，这一点尤为重要。安全工具应与其他能够访问代码仓库的软件一样，经过相同的决策流程。其防御用途并不能免除理解其权限的必要性。

没有依据表明 Ultrafuzz 曾入侵用户的工作站。文档中的警告确立的是已说明的风险和部署边界，不应被转换为针对某一具体有害事件发生过的指控。

更有用的解读关乎问责。必须有人准备环境、决定哪些内容进入其中，并审查产生的结果。活动的自动化阶段并不会消除这些责任；它们使机器活动与人工判断之间的交接更为关键。

这正是该工具与 OpSec 主张最直接交汇之处。采用 AI 调查合约的团队，必须将运营纪律同样应用于这一调查。否则，它可能把安全工作流视为其在其他领域所要求实践的例外。

对于评估类似产品的组织而言，这还意味着采购层面的影响。部署要求应与支持的语言和报告功能一并纳入比较。一项工具是否有用，部分取决于组织能否在满足访问权限和保密要求的前提下运行它。

由此产生的权衡十分具体。更高的自主性让代理无需持续干预即可完成更多工作，但运行环境必须限制这种自主性可能造成的后果。正确的评估应考虑整个活动，包括准备、执行、审查和处置。

因此，Keone Hon 推动的 Ultrafuzz 不能仅凭开发者是否启动活动来判断。更有力的采用信号是，团队遵循文档规定的边界，并对结果保留清晰的责任。运行软件只是正确使用它的一部分。

关注已验证的发现、持续使用与运营变化

接下来的证据应将自动化调查与修复、重复使用以及对敏感操作更严格的控制联系起来。

首个值得关注的信号是可由独立人士复现的发现。在未来几个月里，详细披露或可展示所检查的目标、失效的行为，以及另一位审查者如何确认该问题。这类证据将强化这样一种判断：该工作流的贡献不止于生成候选警告。

被接受的修复将提供另一项有价值的联系。一项公开发现即使没有影响已部署系统，也可能很有意思。若有证据表明开发者理解并修复了该问题，就能显示发现如何转化为工程工作。

没有公开披露并不能证明失败。团队可能在修复问题时保密，披露时间也可能不同。不过，这会使外部观察者缺少独立评估有效性的证据。

第二个信号是超出初次试用的持续使用。代码变更后，团队再次使用该工具，与一次性的演示相比会提供不同的采用信号。重复使用表明该工作流适合持续的开发流程。

当使用者说明所需投入时，这一信号会更强。有关配置困难、失败活动、审查时间和有用输出的说明，将帮助其他团队评估适用性。相比明确说明工作流在哪些方面有所帮助，未经限定的赞誉提供的实用信息更少。

仅凭代码仓库关注度无法回答这些问题。公众兴趣可能反映好奇心、推广或研究，而非生产环境使用。当采用主张说明完成的任务和负责审查结果的人员时，其信息价值会更高。

第三个信号是技术测试之外的运营变化。遵循 Hon 更广泛呼吁的团队，会审查特权访问、签名安排以及敏感工作的隔离。这些行动将支持这样一种观点：该信息的影响已超出合约分析。

一次活动报告无法证明这些变化确实发生。证据需要来自运营相关协议的组织，同时应妥善处理敏感细节。清晰的责任归属和书面化流程，比泛泛声称重视安全更有意义。

这些信号检验的是同一命题的不同部分。已验证的发现评估分析价值；持续使用评估实际适配性；运营变化则评估更强的测试是否伴随着对管理软件系统更强的控制。

对开发者而言，直接行动是在启动活动之前界定哪些证据足以支持采用该工作流。确定谁将审查发现、如何复现故障，以及哪种环境满足项目的运行要求。对于买方和合作伙伴，应询问最终报告实际涵盖什么，以及哪些责任仍在其范围之外。Keone Hon 推动的 Ultrafuzz 提供了重新审视这些问题的有用理由。阅读文档中规定的边界，将其与组织的实践进行比较，并思考下一次安全演练是否既能产生更好的证据，也能让无法由这些证据解决的风险拥有更清晰的责任归属。