附录 A：三次线上会议记录（脱敏）
我快速介绍一下两边的同学，麻烦 Lucifiel 老师再给我们展示一下你遇到的问题。Lucifiel 是我们之前做整体用户访谈、包括产品 web beta test 这块都非常积极活跃的老用户、老社区成员，在我们 Discord 里也非常积极地帮助我们。我们团队这边，产品技术的主要负责人也都在。今天把老师在 Telegram 群里同步的情况也提前跟两位提过了，他们都非常重视，所以快速拉一个会，听老师详细讲一下目前在安全上可能对 Donut 系统架构产生较大威胁的一些攻击链路。老师整理了文字资料，方便的话请老师开始帮我们过一下。
好的，我共享一下屏幕。我做了一份简单的 PPT，给大家介绍一下。首先感谢大家参加本次会议。我本身是做渗透测试方向的网络安全的，看到 Donut 有安全漏洞挖掘的活动后参与了多次。本次挖掘一共发现了 23 个安全漏洞，最高一个达到 CVSS 10.0 的标准，其中有一个致命、三个极高危、六个高危。我在前期测试时已经用该漏洞产生了 9 次链上交易成功的记录。
先讲最严重的。在黑盒挖掘过程中，我发现 Donut 使用的是一个第三方（Turnkey）的钱包托管服务，从黑盒视角看，私钥托管在服务端。交易流程是：由 Donut 服务器调用私钥发起签名，广播到 Solana 链，再由 Turnkey 做最后的交易确认。
我体验了 Donut 的两款产品。正常情况下，由 AI 或我自己发起交易时，会有一个弹窗确认（签名确认）。流程是先发送到一个接口构建未签名的 swap 交易，返回信息再同步到第二个执行接口，后端调用 Turnkey 自动签名，再广播到 Solana 链完成交易。
我做的事情是直接跳过了前端的用户确认流程，直接向接口发起未签名 swap 交易，用返回的数据包提交到执行接口，就可以直接调用服务端的 Turnkey 并广播，完成整个交易——没有确认弹窗、没有 2FA、也没有签名请求。
我测试了四个方向的交易，前四笔是 swap，第五笔是 wrap，第六、七笔是同源交易链，第八笔是跨用户钱包充值，都有成功记录，都可以在区块链浏览器查看。
这个漏洞不需要接触用户的物理设备。原因是 Donut 的 CORS 同源策略使用了通配符，允许该域名下所有子域名携带凭证访问 API；DNS 也使用通配符解析，任何子域名都可以解析，哪怕这个子域名并不存在。这就导致攻击者可以模拟一个自己的子域名，加上恶意页面，发送钓鱼链接给用户。用户只要访问或点开这个页面，就会触发整个交易流程，甚至钱被转走了都不会有任何察觉。
还有几个比较致命的。第一个是付费功能绕过：目前非会员每天只有十次 AI 使用次数，通过这个漏洞我已经实现了无限次调用，不需要相关次数限制。第二个是弱参数注入：给 AI 发消息时有一个权限参数，默认是 user，可以通过修改请求把权限改为 system 等。不过因为我手里只有自己这一个账号，没有更多权限账号做测试，它的具体危害程度和范围暂时待定，但确实可以借此绕过安全限制。第三个是无认证钱包创建：通过一个接口可以无需 Donut 账户、无限制地创建钱包，支持 13 条链。这可能导致无限消耗后端资源，且这些钱包明确由 Donut 创建，如果被黑产利用放入黑钱，会形成洗钱效果，对 Donut 有法律风险。第四个是计划暴露：会员策略接口公开可见，现阶段意义不大，但后续收费时可能有影响。
接下来讲跨用户攻击链。第一步通过接口获取到真实用户钱包地址；第二步通过接口查询该钱包——虽然钱包资产在链上可查，但通过 Donut 的接口可以看到更多信息，包括 Donut 内部计算的成本、均线等，而且似乎不需要登录就可以调用；第三步创建签名，跳过用户授权签名这一步；第四步后端签名发送，资金被转走。全程不需要用户参与和点击授权。这个攻击链包含侦查、资产探测、交易构建、签名确认四步。
通过 Donut 暴露的一些接口，我还发现了一些数据：有一个价值约 76,000 美元的钱包（845 个 SOL 加 2034 个 USDC 等），还有一个约 15,000 美元的钱包，完整交易历史我都能看到，都是通过这个接口无认证查询到的。目前我可以看到 Donut 有 1212 个活跃钱包，K8s pod 名称也全部暴露，这些都是无需认证可直接获取的，包括 175 个后端 API 我也都掌握了。
我在本地写了一个 PoC，给大家演示一下。（演示）这是我的账号，十次次数，有一些 SOL 和 USDC。现在我登录后不进行任何操作，切换到我写的 PoC——这个 PoC 只是为了演示，实际可以没有界面。我设置将 0.001 个 SOL 兑换为 USDC，点击执行，它正在创建链路……现在已经完成，返回了交易哈希，我们点进去看链上是否有成功记录……现在已经有记录了。再回到 Donut 这边刷新 history，时间已经变成新的，哈希都能对上。这就是我刚才创建的一次交易，没有涉及任何用户授权。如果我不来平台查看，根本不知道账户被攻击了。
影响评估：第一，直接资金风险，任何登录用户的钱包资金都可被静默转移；第二，远程可利用，不需要控制用户的终端设备，可远程触发；第三，业务损失，无限调用绕过了收费机制；第四，AI 安全绕过，权限可被更改、信息可被写入数据库形成自动化攻击链。我也列了修复优先级：P0 立即修复、尽快修复、计划修复。
非常感谢你的反馈，而且非常系统、非常完整。我们在产品发布过程中也知道有比较多比如反钓鱼这些工作还没开始，通过社区活动我们能快速拿到这些反馈，应该会尽快修复。而且我觉得我们甚至可以进行一个相对长期的合作。因为我们也在对现在已有的整个 AI 的分析做升级，可能会有更多安全隐患，这个可以考虑一起合作一下。
感谢[产品负责人]的发言，正好我也想跟团队聊一下这方面。我参与这个项目比较久了，从第一次访谈开始，每次访谈和漏洞挖掘活动我都有参与。据我了解，团队这边没有专职安全人员。之前[首席运营官]还在对接的时候，我跟他聊过这方面的想法，不知道有没有反馈给公司。我自己专业从事网络安全，Donut 在做的产品很吸引我——我自己也有一套自动化交易系统，但效果差强人意。Donut 的长期愿景也是我想做的东西，区别是 Donut 想做的是面向所有人的基础服务，我们是给自己的小团体用。我挺佩服这个愿景，如果有可能，我也比较想参与到这边来。
理解，非常好，团队内部应该也会再规划一下。我先说一下，我们的安全团队确实还没有非常完善地搭建，但这也是我们计划内的事情。我们现在域名对外都还是 beta 的状态，更想先把产品和体验真正做到用户满意。我们没有去碰一些比较浅度的、只做 research 的东西，更希望把交易做得更深刻一些，所以在产品和 AI 这块花了挺多时间，在安全上确实有所懈怠。今天你这一分享，让我回去要调整一下优先级。
我也讲一下我的角度。作为初创团队，优先考虑产品完善度，这是正确的策略。但我从业安全差不多十年了，一直在 Web2，对 Web3 有一些朋友。据我了解，包括一些在交易所的朋友，策略跟你们差不多，都是先让产品跑起来、优化体验再做安全。但这会导致很大问题，比如前年 [某头部交易所] 被盗币的安全事件；包括不少朋友那边都有被盗。以安全的角度，在搭建产品的过程中，写好一部分代码后就应该由安全人员审计，内部审计完再更改，同步进行会比较好。如果全部做完再改，一是系统架构层级的漏洞修改工作量会非常大，甚至要推翻重来；二是安全和产品长期堆积会有很大的后期风险。
另外，之前我跟[首席运营官]聊过团队的想法，团队可能按 Web3 以往的做法找一个安全公司做三方审计。但我深度参与、深度体验之后的想法有些不同：Donut 想做的产品，从安全模型上更偏向于交易所。如果只找三方审计，他们能做的是对一个静态快照做审计；但 Donut 一直在持续更新，可以说每分每秒都在产生交易。所以我认为应该结合本地 SOC（安全运营中心）+ 三方审计的模式。差别在于：没有 SOC 的话，一笔有问题的交易会被执行完，发现时损失已经造成，再请三方审计进驻调查会有时间差（可能一两天才能进场），只能做事后复盘；而有 SOC 的话，发现第一笔风险就能第一时间拦截、编写策略、再做紧急修复。据我了解，在 Web3，几乎只有交易所才会配置 SOC 中心。Donut 的安全模型跟其他 Web3 项目有很大差异，其他 DeFi 产品可能一次安全事件后就是那一次资金损失，但 Donut 这种时刻在交易的平台，仅靠事后复盘是不够的。
理解，非常好，我们也会重新思考这个优先级以及团队的组建。
好的。还有我想提出一个想法。这个漏洞我会按安全行业的负责任披露流程来处理。我会提供一份脱敏报告供你们修复；在风险全部修复后，大概 30 天到 90 天范围内、跟团队取得明确确认后，我可能会编写一份安全研究报告发布在行业里，一是提升我自己的知名度，二是作为技术共享，但前提是相关风险已修复且团队许可，这个可以后续再沟通。
第二，如果团队有漏洞赏金方面的计划，我个人希望可以争取到一些奖励，毕竟这一份我投入了很多时间和技术资源。后续如果还有研究成果，我也会继续提交。因为这个产品我个人很看好、很感兴趣，也很想参与进来。
理解了，我特别能理解你后面提的两个点。我们会针对这两个点给到你一个非常明确的反馈。
好的。我再说明一下，作为安全研究的负责任披露流程：会有 7 天时间确定前期的修复方式和对外披露流程；7 到 30 天我会协助团队修复；30 天到 90 天根据修复情况考虑是否对外披露；90 天以后，我可以根据自己的情况选择是否披露——哪怕届时没有修复，我也有选择披露的权利。这是安全行业的披露原则，希望您知悉，具体可以再沟通。
OK 可以的，对对。
好的。稍后我会把脱敏报告发在 Telegram 群里，里面有技术情况但不包含技术细节。技术细节那一份会在后续洽谈合作意向时酌情提供，因为不太方便通过互联网传输，需要私下沟通。
理解，OK 没问题。我们会尽快跟进你发的文件以及你提出的几点想法。
（会议结束）
完整录音留存备查。
在另一位同事进来之前，我们先简单介绍、闲聊一下。你现在个人的情况大概是什么样？可以简单自我介绍一下。
我在 Web2 的网络安全领域从业十年左右，此前一直在 [工作单位] 从事网络安全攻防工作，后来转做红队负责人（red team leader）。去年9月离职后，因为对 Web3 很感兴趣，就彻底转做自由安全研究员，研究 Web3 方向。当时看到 Donut 这个项目，你们做的事情我自己很感兴趣——我自己也有一套量化交易系统在用，所以觉得很符合我的想法，正好看到有挖漏洞的活动，就来参与了这方面的技术研究。
那你大概什么时候接触 Web3 的？
我接触得很早，大概几年前就知道了，只不过那时候国内对这块态度比较尴尬，所以没往这个方向发展。我有很多朋友已经在 Web3 里就职，平时也有很多交流，包括各大头部交易所那边我都有朋友，我们有一些技术交流。每次出现安全事件后，我们也会一起复盘，思考造成那些安全风险的原因。
挺好，你们是有一个安全方面的社群是吧。
对，我们有一个小团体，平时交流，或者需要什么资源时互相调配一下。比如偶尔哪个项目需要人或搞不定了，找朋友帮忙，这些都很常见。
除了 Donut，你还关注过其他做量化、做 AI 量化的团队吗？
这块倒没怎么关注。我个人更多关注交易所那边的问题。之前我跟某个 top 级交易所聊过，他们想招一名 CISO，但因为一些非技术原因最后没谈拢，就没去，还是自己继续研究。
你现在是个人职业工作者，大概会花多少时间在安全和量化这两方面？
我 80% 的精力投入在安全研究上。交易那套系统是我们团队几个人在用，有一个专门做交易比较专业的人（以前也是 KOL，有交易资源），账号大部分时间由他调配管理。晚上我们会交流一下心得、对行情的判断，以及行业和安全的现状，大概投入 10% 左右的精力在交易上。
从你的视角，Donut 吸引你的点是什么？
Donut 用自然语言做交易这一点非常符合我的想法。我研究过程中发现它是基于 OpenClaw 底层去搭载各种库、或者自研的 skills 来加载交易的。首先我觉得你们的提示词部分比市场上大部分做得好，能符合大部分人的需求；其次可以用自然语言很好地验证整个过程。我自己也尝试过用 OpenClaw 搭一套类似系统，但效果差强人意，基本需求能满足，但维护会花掉大部分时间。基于 Donut 现在的进度，我觉得对那些不太懂交易、没有技术背景的潜在客户来说，是比较符合他们需求的，这也是让我眼前一亮的地方。
你说的这个也是我们的用户画像。我们确实还在非常早期的阶段，还在寻找 PMF，内测用户也不多。所以在安全 scope 上，我们优先级暂时还没那么高，但我们同时也找了专业的机构来做相关的审查。
其实我发现你第一版给我们的报告，后来重新看了几遍，我感觉比花了很多钱找的那个专业团队给的报告，有些角度是比较深的。所以我觉得你作为一个个人开发者，经验也是比较多的。
这个会议主要分两块：第一块我们还有一些疑问，比如你做攻击时整体的思路；有些攻击链路的细节不是特别清晰，所以有些情况我们也没办法复现，少部分因为不太了解攻击链路，没办法证明它已经被修复。第二块是聊一下合作方式和你的意愿。
好的。我先就三方审计简单说明一下，因为在座各位可能没有安全从业经验，而我是专门做安全出身的。三方审计的角度更多是从代码层面做白盒代码审计，看代码里是否有相应问题，是一种可批量化、有打分标准的验证模式。而我个人研究的业务逻辑漏洞这一块是没法做量化的，行业内研究逻辑漏洞的人也偏少。我大部分的漏洞都是各种各样的小漏洞，组合起来形成一整套很严重的攻击链——这不是从代码审计的角度、或者用 AI 就能完成的测试。所以这是三方审计不太理想的地方。
关于修复情况，我这两天（2号、3号）做了一下复测。目前我手里的，包括 AI 浏览器（第一套对话模式的产品）和 D0 这套系统，一共有 49 个漏洞，包括 10 个严重、19 个高危、16 个中危、4 个低危。我验证下来完全修复的只有 11 个，部分修复的占一小半。剩下 D0 这套，因为我当时确实没有报告，所以也没有做修复。针对其他业务链，有几个核心漏洞目前也还没有修复，这是我检查下来的结果。
关于合作意向，我想先听一下团队这边的方案。因为我更多是以外部视角参与的，掌握的信息没有三方审计公司那边多。还有一个核心点，之前[首席运营官]还在的时候我提过，不知道团队是否知道：我认为 Donut 的业务模型建立起来后，其风险模型更偏向于交易所，不是常规的那种项目，所以我更多是以交易所的视角来看待这个项目。
我的测试过程跟他们有些不一样：我首先以用户的角度体验整个产品的业务流程，然后以黑客的视角去想能从哪些地方攻击、把平台或客户的代币盗走，再以安全人员的视角排查潜在风险。以这三个视角挖出了一整套漏洞。三方审计公司有很多客户，不可能在一个项目上投入所有精力，所以他们对 Donut 业务的了解度没有我深。
你觉得对你自己来说，是以白盒视角找问题更精准，还是第三方视角？
以白盒视角更精准。因为黑盒的话，很多不确定的东西只能靠猜测，得出的结论或论证过程可能有错误；白盒的话，我在过程中发现哪里有异常，可以做方向纠正。
那你之前十年的 Web2 经验和 [工作单位] 的经验，大部分是黑盒还是白盒？
两个方向都有。我自己带团队，攻击团队和防御团队我都带，一些重大安全事件中我很多时候是总指挥，所以两个视角我都做。黑盒和白盒我认为不是对立的，而是可以相互结合、相辅相成的。
我们回到第一个话题。我们最关注的几个点之一是：分析报告里你写了完成 9 笔真实的链上交易，这肯定是用你自己的钱包做的。那跨用户攻击这一块，是否真的有相应的链路？
跨用户这一块在我的报告里应该是没有呈现，因为当时给的是一份脱敏的部分报告，达成合作后我会给出所有详情报告。我做个说明：在正常业务请求流程中我也尝试了，有两个视角。
第一，我发现平台有一个总资产价值约 7 万 U 的钱包，我以我的账号权限去对它进行操控，这边平台卡住了，因为它不在钱包托管体系里，从我黑盒视角猜测是轮询时没找到相关资料导致卡住，最后返回了 AUTH003 状态。
第二，我拿了平台内另一个用户的钱包去发起请求，这边在平台内请求构造是通过了，发送到了第三方（Turnkey）那边，由他们进行 AUTH001 拦截下来。拦截提示大概意思是我发起的权限和钱包不符。所以平台这边的安全限制已经被绕过了，最后的拦截是被第三方拦下的。
但作为安全研究员，我对完全的纯黑客手法不如他们，以他们的视角我不确定能否突破。以我目前的视角，我觉得有突破的可能性。但目前我只有思路，没有去经过真实验证。
理解。这里有两个可以讨论的点。第一，在我们后台，整个用户体系里所有用户加起来都没有这么多钱，加起来就几千 K，所以我不太确定你看到的这个钱包是哪来的，有可能是测试。它是真实链上资产吗？
对，真实链上资产，是通过我们这边 175 个 API 里其中一个查询功能发现的，我不确定那个钱包的作用是什么。
这个我们下来查一下，比较奇怪，因为我们线上用户不可能入金这么多。我们是托管，由 Turnkey 托管钱包，需要用户自己入金，不会有这么大金额，所以可能是个误报，我们排查一下。第二件事，你刚才说的跨用户那一块你说已经验证了，那前面那个链路的用户，是你已经登录过的业务用户，还是你通过我们接口爬到的其他用户？
这是平台内一个真实的另外的用户，我是直接找他要的钱包地址，拿过来做的测试。
那这个情况是真实存在的。你在我们平台做了推特和谷歌登录之后，会签发一个签名的 key，只有你这个签名的 key 才能对你绑定的钱包做签名。所以你拿到他的 wallet，如果没有办法拿到他对应的签名 key，你也没办法帮他签名，所以会在第三方被拦下来，这个解释一下。
因为我以我自己的签名权限去发起请求，请求过程中有一个参数包含我自己的钱包地址，我把这个地址替换成了别人的钱包地址（from 改成别人的钱包，to 换成我自己的钱包）。这块在平台内请求构造是成功的，只不过在第三方那边被拦截了，因为签名和发起权限不一致。
理解。这是一个产品的问题，不是安全层面的问题，因为安全层面最后被拦住了。产品的问题应该是在前端，以别人的钱包发起转账时就应该拒绝掉。
这个我觉得应该划分到安全问题，因为这属于越权。正常来说，以我的权限去发起别人账户的交易请求，应该在平台内就被拦截。所以这是一个安全防护没做到位的问题。
理解，对，这是我们产品安全的一个问题。第二个点：你做攻击链路时用自己的账号，我看到你做了一个网页，相当于拿到了你自己钱包的 key 来做签名完成转账。你想表达的是不是说，这个东西一旦被钓鱼或恶意插件攻击，从网页拿到这些 key，就可以把当前用户的资金全部转走？
也不完全。我这个 key 没有内置到钓鱼页面里。那个页面会自己通过同源配置和子域名通配，直接去调取浏览器内已存在的凭据。因为我这台电脑登录的是我的账号，但如果是别人来点这个页面，盗取的就是他的 key。所以这是一个我认为行业内非常严重的问题——不是说我拥有自己的 key 才能进这个账号，而是只要点击这个页面的人，只要登录了平台，他就会被盗。
理解，就是我们同源隔离这块没做得特别好。这个点我们之前没想到，也没去验证，我们要把这个做好一点。这块我大致没有其他问题。第二个，OpenClaw 这边我们看有两个：一个是 AI，你通过角色注入的方式能让 AI 产生一些问题。这块我们在上层有隔离，每个用户的 agent 只有他自己能访问，包括前端入口、TG 入口我们没有开放群聊，所以只有当用户自己绑定的 TG 被盗之后才会有效。所以这块我不太理解你想表达的攻击链路是什么？
是这样，我首先通过 D0 这个平台能获取到 OpenClaw 控制面板的地址，再通过这个地址登录进去之后，严格来说我已经可以伪造交易了。但我发现里面有三层安全限制：第一是提示词里做了安全相关的限制，禁止执行敏感命令；第二，我拿到面板后理论上可以修改提示词，但平台有一个检测提示词是否被修改的机制，被修改会覆盖还原——这个机制我也可以绕过；第三，绕过之后我发现 Claude 本身有安全限制，导致我无法执行一些敏感命令，但我通过其他方式，通过一个 Openclaw 的 0Day 也把这个机制绕过了，最后拿到了一个 shell。
我想表达的是：这套漏洞现在理论上只能影响我自己的账号。但我在研究过程中发现存储用的容器是 K8s，我也尝试在做容器逃逸，理论上是可以成功的，但需要一些时间。是否影响其他账号，我觉得配合钓鱼也可以拿到别人账号的 OpenClaw 面板。而且我没有跟 Telegram 进行任何交互，直接通过网页端就能获取到这些东西。
这个攻击链路我觉得还是有风险的。
我补充一下，我想再 double check 一下，我们之前有做过类似容器逃逸的实践吗？我抛出一个点：针对 OpenClaw 本身漏洞以及沙盒逃逸相关的事情，我觉得可以立一个专项去讨论。因为这不仅仅是我们 D0 产品的问题，现在大部分基于容器沙盒的 Agent 产品都会有这个问题。如果通过容器逃逸的方式能找到问题，应该大部分产品都有这样的风险。我现在正在写一套更安全的 Sandbox 服务，如果后面有合作，这块可以重点聊。
所以我想了解，你现在发现的容器逃逸攻击链路大概是什么样的？
容器逃逸的方法，目前我们只是判断有几种可能性，还没有经过实测，所以这块研究不太便于做说明，只是从这个角度来说确实存在这个可能性。
另外，前面提到的 OpenClaw 的 RCE，它不是针对 OpenClaw 这个产品本身的，而是你们二次开发以后留存下来的问题，在 OpenClaw 原生版本中是没有的。我也下载了原生版本做了本地搭建测试，发现不存在这个问题，仅存在于 Donut 这边。还有，我判断从 D0 系统面板跨到 OpenClaw 的过程中，理论上也存在几个越权风险，但这段时间我有其他事情，还没顾得上这个研究。
理解了，关于容器逃逸这块，我们之前立了一个专项专门去防，从白盒角度我觉得已经防住了，但从黑盒角度有各种其他方式，不一定真正防住，所以这块还有很多讨论空间。
对，我觉得这块在所有项目、所有使用云服务的产品中都是值得讨论的点。
好，从你的角度，我们还有哪些你觉得还没被修复的比较严重的问题？
首先是自动签名，就是签名伪造绕过那一块，目前确实还没解决。然后是跨用户取消限价单——我有一个核心漏洞，可以用我的权限把别人账户里的限价单取消掉，虽然我无法创建，但可以把别人的止盈止损跨用户取消掉，我认为这是一个很严重的问题。
在这个基础上，AI 浏览器和 D0 这边的提示词都泄露了（Ai浏览器有四套提示词，D0 这边有八套提示词）。我自己不是专门研究 AI 安全的，略懂一些，这部分我有朋友专门在研究。以他们的视角，拿到提示词后可以尝试通过提示词注入，把一些现在没法判断的漏洞直接绕过。还有 AI 浏览器这边，非会员每天有十次使用次数，这个我目前也可以绕过。CORS 这块同源配置只修复了一部分，有一些还是可以被绕过。还有 MCP 工具层的认证与权限边界不足，我依然可以把 MCP 工具枚举出来并调用。
MCP 这块其实我们是设计成让用户能拿到所有 MCP 的。
对，因为我不清楚你们的规则，是以个人角度做的研究。这个我理解为一种正常场景。剩下基本就是 D0 那边的内容了，因为 D0 我前期没有做报告，所以这块漏洞都掌握在我手里，我自己也还在做研究，暂时没写成报告。另外浏览器那边有个权限参数，我不太清楚它的作用，但目前看是可以被修改注入的，我尝试改成 system 等都可以执行成功，但具体能起到什么作用我还不确定。
那正好聊到第二层。你刚才聊下来，如果我们要合作的话，你的整个经验其实还是在 Web 端和正常的攻击链路上，而像 AI、链上这些新型攻击，你还在一个学习和研究的阶段。我想了解一下你未来对自己的规划是什么样的？
我个人还是偏向于 Web3 的安全研究者。我是从事安全出身，对安全的兴趣远高于开发。对于新兴的东西我们也有研究尝试，包括对 OpenClaw 的研究（我也给他们提了不少 issue），还有 AI 方向，目前更多是使用过程和提示词注入的攻击研究，我们也有一些研究成果。
链上这块细分领域比较多，三方审计公司对链上攻击比较熟练，我们接触相对较少。因为我更多是业务逻辑层面的研究——业务逻辑研究不是只针对外部或某一个端，而是整个业务链条上的逻辑漏洞研究。这一块在行业内比较少，但需求量非常大，只是因为无法量化，导致很多人的学习体系有偏差，所以我对这块研究相对较多。
今年我看了一下数据，发生的安全事件造成的损失有八千多万美金，而 Web3 行业内的安全事件，70% 其实不是系统层面漏洞引起的，反而都是业务逻辑漏洞引起的，包括[某交易所]被盗币的事件，我复盘发现底层也是业务逻辑漏洞引起的。
我快速说一下我们对这个角色的要求。我们整个公司是 AI 驱动的，所以希望这个岗位有两个核心：一个是你说的业务逻辑，包括所有外部攻击链和我们整个产品的业务逻辑；第二个核心是 AI 部分的攻击，比如通过外部影响 agent 交易、通过 agent 对话绕过现有逻辑机制攻击到内部系统，以及 agent 暴露面的问题。这些都是这个岗位负责范围内的事情。
我觉得你在第一部分（业务逻辑/资历经验）非常多，这也是我们非常关注的点。这部分我在想，如果仅仅是第一部分，合作模式可能会像外部审计公司那样——我们发一个版本时做一次审计；但如果你能 cover 所有面，我觉得可以作为一个常态的岗位。
明白。我想纠正一个点：审计公司的角度和业务逻辑的角度不太一样，他们更偏向代码安全。我认识的一些做审计的，早期也是做代码方面研究，后来 Web3 兴起后创立了相关公司，他们更突出的还是代码安全。而业务逻辑确实是行业内比较少有的研究方向，因为它没法发布一个很有权威性的研究成果——不像系统层面的 CVE 那样可以拿出来，所以很多人不会选这个方向。
至于 AI 安全，它是一个才刚兴起的方向，行业内现在也没有标准化的参考标准来界定什么人达到什么水平。我们更多是自己研究后大家聚在一起讨论，或者在 AI 安全大会上分享研究成果。这些都还在摸索阶段，没有哪个公司或团队能做到很标准化地量化产出。所以这块如果有需求，我可以带着去做这个方向。
还有，安全这个领域的专精度非常高，可能需要不同方向的人。可能安全所有方面我都了解，但某个方向我有专精，另一个方向我可能只是了解。所以如果条件允许，我觉得再多配一两个岗位会更合适。我了解到其他交易所基本也是各司其职，一个人完全 cover 的情况相对较少，随着业务量增大会慢慢投入更多专精的人。
理解。回到合作形式，安全这块本身对安全员的信任度是很重要的一点。所以我觉得前期我们可以以合作的形式、以节点外包的形式——比如我们发一个有较大功能的版本时，以外包或外部合作的形式开展；当形成一定信任后，再考虑更深度的合作形式。
针对这块我有个想法。如果想更好地检测到相关问题，我可能还是得接触一些核心的东西。从外部合作的方式来说，第一它有很大的安全风险，因为确实有那种伪装成人员参与到项目方然后投毒的情况，这种情况不少。第二，对于新人接触这一点，我想说一个可圈可点的地方：如果我有坏心思，我完全可以把这些漏洞留着，等 Donut 拿到 A 轮融资、扩大规模以后我直接动手，而不是发现问题就来跟团队说明、希望一起修复。如果我有坏心思，完全没必要做这种事。对黑客和白帽来说，收益是完全不成正比的，差距非常大。理论上按我掌握的漏洞，如果继续研究下去，等用户更多的阶段我直接动手，说实话我有自信你们团队抓不到我。
那从你个人意愿来说，你平时是接外包、安全审计比较多，还是做白帽项目比较多，还是深度参与一个项目比较多？
我之前在 Web2 公司就职时，大部分时间都沉浸在某些特定的核心客户上，比如一些大型企业客户、监管单位，对保密需求非常高，都是深度参与他们的项目。金融这块我也接触比较多，[某金融机构]、[某监管单位] 的一些安全审计也是我做的。
从外部参与和内部参与有很大差异：外部参与我可以用现有的内部信息做检测，能省掉 80% 的探索时间，产出更多成果。而每次以外包、发版本的形式，第一我对信息的掌握度有限，第二每次都得重新投入做检测，不够针对性。如果是长期参与，比如每次有新功能点，在开发之前我就可以给出安全评审意见，提前把安全做起来，发布版本后我再做安全防护能力的检测——那时是在已知情况下做检测，而不是每次都当成一个新项目，既省掉大量探索时间，也能输出更多安全研究成果。
理解，我觉得我们一步一步来。之前的这些成果循序渐进，有机会我们可以线下见个面，慢慢培养信任度。你之前做的这些事情，我觉得价值是非常大的。我们也可以考虑后续是否以这样的合作形式继续下去，讨论一个双方都觉得不错的、每次的报酬。[产品负责人] 有什么要补充的吗？
没有，我觉得你们聊得挺好的。
你觉得 OK 吗？OK 的话我可以拉我们的 HR 一起谈一下，具体讨论。
我其实不太清楚团队内部对合作形式的具体想法。对于三方审计，我实话实说，如果只是代码层面的审计，那些审计公司会比我专业；但对于逻辑漏洞，我可能比他们理解得更深入一些。
可以，确实能体感出来，你找出来的这些漏洞从攻击者视角会更全一点。我们这个会议之后拉一个会，找一下我们 HR，单独约一下。
披露这一块跟这个是比较独立的，你可以按照自己的节奏去披露，然后内容的话就一定要保持、保证公平客观，包括沟通过程。
然后披露是这样，我披露的话我是只做技术层面的披露，我不会去掺杂我个人的想法这一块的东西。因为我认为我是一名负责任的安全研究员，我不是说去表达我自己情绪化的东西，所以我是只会去说明我发现的一些技术上的东西。
OK 没问题，我们之前节奏上的披露没有任何问题，它是比较独立的，你按之前的节奏去披露就 OK 了。也很感谢你持续关注我们这个项目，持续帮我们找了这两轮、两个比较大版本的漏洞。
好的，辛苦。
那我们接下来单独拉一个会，我先跟 HR 聊一下，再约时间。
（会议结束）
完整录音留存备查。
不好意思，刚刚网络有点慢，进来晚了一点。这次的会，[技术负责人] 跟我说过，你之前给我们发过一些 bug，想聊一下后续深度合作的机会。我听说你最近又扫过一次我们的项目，做了一份分析对吧？
我把目前手里掌握的 49 个漏洞做了一次复测，发现其中只有 11 个中低危是修复了的，一些严重的问题都还没有修复。
了解。这个已经同步给 [技术负责人] 了吗？
还没有。因为我三月份初报的时候说过，我给的是脱敏报告，完整的报告会在我们达成一个基础的合作之后，我再完整提供给团队协助修复，包括我的修复方案。
明白。我想先了解一下，你这边是一直在做白帽这个事情吗？
对，我在国内是合法合规的，在[监管单位]那边正规备过案的安全研究员，一直做的都是合法合规的事情。
明白。你是怎么关注到我们项目的？
我一直在做 Web3 相关的，当时找一些项目看的时候，看到了 Donut 的介绍——做 AI 自动化交易，我自己正好也有一套量化交易系统。我想做的、目前在做的事情，正是我一直想做的，所以一下子就感兴趣了。深度参与研究之后，发现 Donut 的一些理念和我的理念非常合得来。
明白。你现在有同时给其他项目做吗？还是主要 focus 在一个项目上？
我个人比较习惯沉浸进去，一直做同一个项目。所以我目前一直在研究 Donut 这个项目。
好的。你希望的合作形式大概是什么样的？
我了解到 Donut 这边没有专职的安全工程师。如果有机会，我想一起参与进来，把 Donut 的安全架构这块的责任担起来。我在 Web2 也从业了十年，各种攻防经验、基础架构建设经验都比较丰富。所以如果有机会，我想加入团队，一起把这个事情做起来。
了解。我们对安全工程师这个岗位的考虑是这样：首先这个岗位肯定要是我们非常信任的人。之所以现在有这个 call，也是因为 [技术负责人] 跟我说和你沟通有一段时间了，所以相对其他人信任基础更高。但我们在这上面还是会比较谨慎。如果是一个 full-time 的安全工程师，相当于是完全透明地把安全交给你做；而外部合作可以是比较黑盒的状态去做安全审计。所以我们的想法是，前期先短暂合作 2 到 3 个月，建立更深的信任基础、对你能提供的情况有更深入了解之后，再去聊更深一步的合作，比如 full-time 或其他形式。你看这样的形式可以接受吗？
我这边有个想法。昨天 [技术负责人] 提出以节点形式合作，发一个大版本时我去做一次或一轮测试。我觉得这种方式从成本、工作效率和安全性来说都是比较低的。我也思考了一下，有一个合作形式，你听一下觉得如何：我们还是以正常员工的形式参与进来，但我以外部黑盒的形式参与，就像你说的 2 到 3 个月，类似国内试用期的概念。这期间我随时提供安全方面的咨询或测试，团队需要什么提供给我就可以，我来做，我也不接触核心的东西。
因为我自己也是安全从业者，站在团队角度，对安全的担忧我很理解——如果接触到核心，就等于整个项目透明地放在面前，如果是白帽还好，如果是黑客，给团队带来的可能是毁灭性的灾难。所以不知道你觉得我这种合作方式怎么样？
我理解你的意思。我觉得我们肯定需要前期几轮合作，才能有更深入的了解和信任，所以 2 到 3 个月没问题。但这个阶段我们还是会更倾向于 [技术负责人] 说的那种 check point、或者每次发版的形式。因为我们发展速度比较快，大概看到一两次分析之后，我们也会更了解你带来的价值大概有多少。
我直接说，我们也需要评估：你给我们的完整报告到底是什么样的？你的技术能力是什么样的？如果是 full-time 员工，前面我们会有几轮面试，但现在相当于没有这些环节，可以参考的就是你给的这份分析报告。所以我更倾向于：先在这次发版的基础上看到你给的报告，同时评估你的技术情况，然后再去谈 full-time 加入。因为 full-time 相当于每个月给你付薪资，怎么定薪资、怎么评估技术能力，前期我们都需要一些依据。
我觉得有一个很简单的评估方式。我前面那份报告已经写得很完善了。而且之前也聊过，作为我之前的安全研究，这块应该有一个合适的漏洞赏金。在支付漏洞赏金之后，我会把完整报告给到团队，并给出修复意见，协助团队一起修复。我觉得这里面可以很明确地看到我的能力在什么级别。
再加上你提到的那种方式，我也可以接受。但实话说，每次发版的评估不太好做价值评估。而且这种方式，我个人认为你们的支出可能比每月支付一笔薪资更高，因为外部审计的一次审计费用其实不低。
明白。假如我们现在想先得到你的完整分析报告，这部分你希望的价格是多少？我也想了解，如果按发版单次的形式，你的预期大概是怎么样的？
发版单次的话，按外部审计的价格，一般根据测试标的的难易度和复杂程度，按投入人天评估。按我了解的 Web3 这块团队的收费，大概每次单独审计是 5000 美元到 5 万美元之间，这是一个大众评估，针对不同情况会有特殊定价。所以我的意思是，如果一个月有两次以上的评估，其实还不如每个月固定支付一笔薪资或报酬。
关于漏洞赏金这块，目前我对这一系列一共 49 个漏洞、包括 3 到 4 套攻击链整体评估下来，以 HackerOne 和 Web3 这块已经报过的高危漏洞的内部评估标准来看，是 50 万到 100 万美元。但考虑到我们是初创公司，在这个基础上有一个很大的降幅，总体应该也在 15 万到 20 万美元之间。但这个我觉得我们是可以沟通商量的。
明白，但这个报价确实比我们合作的一些审计公司都要高了。这个是怎么计算的呢？因为我们找一个外部审计公司，可以提供的人力不止一位，而且这个 cost 其实比你刚提到的价格要低很多。
是这样，针对不同的人员能力和级别，报价是不一样的。我可以很自信地说，你们找的那些团队，派出的人能力一定没有我强。比如举个例子——我不太了解其他公司，他们的核心团队，在审计上可能比我专业，但在业务逻辑这块的研究，我认为他们可能只有一两名核心成员会跟我能力差不多。我不能说他们一定比我强，因为各自有各自的研究。我个人在逻辑漏洞这块也钻研了十年时间，所以我认为我在这块的能力评估还是比较高的。再加上我在 Web2 时工作于 [工作单位]，我认为我的能力和人品已经得到了相当程度的认证。我离开 [工作单位] 是因为自己的一些发展想法，比较想往 Web3 这边发展。
明白。我想了解一下，你对于前期先按次合作、和直接 onboard 成为全职员工，很明显感受到你希望直接以全职身份加入，你在这方面有什么顾虑吗？
是这样，我个人是一个比较喜欢稳定的人，做一份工作如果不是逼不得已，我不太喜欢更换。所以我更希望找到一份合适的全职工作。我在来这儿之前，跟某个头部交易所聊过一份 offer，他们要招一名 CISO，我经过四轮面试，技术面全部都过了，但后面在一些洽谈方面没谈拢，不太符合我的想法，所以最后拒绝了那份 offer。
所以我想表达的是，我个人更偏向于深度参与一个项目，如果有可能想一直参与下去，而不是一直更换。而且长期合作和节点式合作有很大差异：节点式的话，每次需要我审计测试，我可能都要从头开始；长期做的话，我可以有一个叠加式的工作状态，每次的成果可以积累到下一次复测使用。比如长期合作，也不用每次发一个大版本才给我测试，而是某个功能点上新了就让我对那个功能点测试，最后达到的效果一定大于临时的一次检查。这是我十年工作得出的经验，而且这样给团队带来的安全成果更高，付出的成本也更低。
工作形式上我认为没有特别大差异，我这边随时待命，需要咨询、测试、复测，或者跟三方公司那边对接，这些都可以由我完成。
方便问一下，你之前和那个头部交易所聊的时候，具体是因为什么原因最后没谈成？
一个是长期发展，一个是所在地的原因。因为那是一家头部交易所的子公司，我可能未来很长一段时间都需要常驻海外。再加上他们的工作模式和面临的一些问题，我认为存在比较重大的问题，但我提出的一些意见他们不太能采纳，所以我评估下来这份工作可能得不到一个很完整的改进，最后评估不太适合，就没有去。
明白。如果我们现在讨论全职工作的话，你希望这个全职的 package 大概是多少？
如果团队觉得我的能力可以担任 CISO（首席信息安全官），我个人希望以这个职称作为薪资评估，个人期望是月薪 15K 到 20K 之间，或者年薪 18 到 24（万美元）。当然我不确定你们内部的薪酬评估体系，如果按评估体系下来，跟我说我们给不到这个薪资，只能给到什么样的薪资，只要有一个有理有据的依据，我也是可以接受的。
明白，这个我们确实得想一下。因为你提的这个 package，在我们公司我可以非常直接地跟你说，我们公司没有这么高的岗位。目前不管是 C level 还是 founder，都没有这么高的待遇。而且我们公司目前除了[创始人]以外没有 C level 岗位，我们是比较扁平化的管理，基本没有 title 之分，基本上是[创始人]对所有人都是这样。
明白。我指的首席安全官主要是这么一个职位——它负责公司整个安全的体系架构，也不一定叫首席安全官，可能叫安全负责人，有很多种称呼。我的意思是，我不是说一定要有多高的薪资才接受，而是基于一个合理的评估体系，评估出来你们认为可以给我这个薪资，这能说服我就 OK。因为我作为技术人员，无非就是两件事：第一是赚钱，第二是得到尊重。能满足其中一件就 OK，能满足两件那肯定更好。
其次是我能给团队带来的资源，我想不只是我个人。我自己搭建过很多个企业的安全体系，还有安全运营中心（SOC）的体系。如果需要，我可以随时把国内外一些知名公司的安全体系拿过来，改成适合我们这边的方案。还有，安全领域的资源我比较多，都可以调配过来，包括一些头部机构里的安全工程师，很多都是我的朋友，我们经常有技术交流，谁那儿需要临时帮忙，我们都可以调配资源帮忙。所以我认为这个价格不只是对我个人的工资评估，还有我所带来的资源的评估。
了解。这个我感觉我们可能得先内部讨论一下了，因为这个 package 确实超出我们预期挺多。不管是刚提到的全职合作，还是你想要的单次报价，其实都远高于我们的预期，我们可能得再考虑一下。
没有问题，我认为这确实需要团队内部讨论，这个我可以接受。然后还有，针对我之前贡献的安全赏金，我不太确定团队这边的态度是多少。
明白，这个我可能得先和团队确认一下，因为我目前不太确定大家得到的信息有多少。
我可以先同步一下。目前完整的报告是没有给到团队的，我提交的大概只有三分之一到四分之一的漏洞。我目前告诉团队的是有 10 个严重级漏洞、19 个高危、16 个中危、4 个低危，其中 35 个是第一套产品（Donut 浏览器，对话式的那个），13、14 个是 D0 这边的漏洞。因为 D0 是五月份后面才开始弄的，所以我后面的一些研究成果暂时还没同步给团队。但这块我对 D0 目前掌握的信息一定超过团队的预期，包括后端 OpenClaw 这个面板，我找到了一枚可以命令执行（RCE）、拿到服务器 shell 的 0Day 漏洞，光这一枚漏洞在市场上的价值就不会低。
了解，这个我们可能也需要做一下 research，包括市场上这种赏金大概都是怎么给的。因为我们确实也是刚开始对外、刚有一些用户进来，所以这部分之前确实没有非常深入地考虑过，也是在你跟我们聊了之后，我们才去关注市面上这种赏金的问题。所以可能暂时我还无法在这个 call 上给你一个回复。
我忘记自我介绍了，我这边其实不是技术人员，我主要负责公司的法务、人力和财务这三个部分。所以前期你给到的这些技术内容，我也需要去和团队确认。
目前 Web3 这边有一个专门挖 SRC（漏洞赏金）的平台叫 immunefi，你们可以去参考一下它的标准，他们的标准是针对已经上市运营、比较成熟的团队体系的。
我这一套漏洞应该是有多个漏洞，可以评估为 50 到 100 万美元，但考虑到我们现在的阶段，这个价格会骤降非常多，所以需要团队做一个合适的评估。我自己的评估大概是 15 到 20 万美元左右，但也需要团队内部评估。后面如果团队需要我的漏洞清单，我是可以提供清单的。
好的，我这边和技术那边拉个会讨论一下。今天非常感谢你的时间。
好的，也感谢你的时间。有什么问题群里说。
（会议结束）
完整录音留存备查。