大门安全课 03｜Gate & GoPlus：如何读懂审计报告，排查合约漏洞

一份审计报告描述的是某一天、某个团队看过的某个版本。而合约会升级，权限会变更，项目依赖的预言机和跨链桥会变，新的攻击手法每周都在出现。报告交付的那一刻，它就开始过期了。更麻烦的是那些几年前部署、当年顺利通过审计的旧合约，正在被重新批量扫描，一个上线多年的合约，深层漏洞可能在十几分钟内就被找出来。

这是 Gate 特别策划《大门安全课》的第三期。我们邀请 Web3 安全服务商 GoPlus Security 与 Gate 安全团队，从安全服务商和交易平台两个视角，聊一聊审计和漏洞排查这件事：为什么审计过的项目还会出事，一份报告该怎么读，平台在上币前后分别做哪些检查，以及普通用户可以怎样在签名之前做一轮自查。

嘉宾简介

GoPlus 合伙人 Adam：Adam 是 GoPlus 合伙人、安全研究院负责人。

GoPlus Security 正在构建 Web3 和 AI 的首个去中心化安全层，通过利用区块链和前沿的人工智能安全解决方案，为用户提供智能、高效和去中心化的安全产品与服务。自 2022 年以来，GoPlus 实现了指数级增长，日 API 调用量达到 3000 万次，为用户防止了近千亿美元的潜在损失。

Gate 安全团队：Gate 安全部门负责平台账户、交易与资产安全体系的建设，同时也长期处理用户的异常账户申诉与协查请求。

Gate 成立于 2013 年，是行业内首家推出 100% 储备金证明的交易平台，目前服务全球超过 6000 万用户。安全是这门生意能够成立的前提，我们希望通过《大门安全课》，把这些真实风险背后的共同机制讲清楚。

Q1. 为什么很多项目通过了审计之后仍然被盗、仍然出现权限滥用？

GoPlus 合伙人 Adam：「一次审计」不等于「一直安全」，传统合约审计服务如今存在四个结构性失效：

1）快照式检查。审计本质上是审计工程师在某个时间点的半人工检查，效果依赖工具质量、个人水平、工作状态。但合约代码会升级、管理权限会变更、参数配置会调整，一次性审计报告交付的那一刻起，它就在「过期」。

2）无法预判未来。新漏洞类型、新攻击手法层出不穷，历史审计覆盖不了未来风险。

3）外部依赖失控。项目普遍依赖预言机、跨链桥、第三方协议，这些依赖项的风险变化不在传统审计范围内。

4）旧合约集中暴雷。数年前部署、当年「审计过」的合约，正被自动化工具批量重新挖出漏洞，例如 Balancer、Yearn 这类正式上线数年都没被发现的深层漏洞。

至于权限滥用，它更多发生在运营阶段而非合约代码本身，原因包括：Owner 权限过大（可随意增发、拉黑名单、暂停交易）、管理员私钥泄露、多签管理不当、恶意提案和治理攻击……这些都是运营阶段容易出现的安全问题。审计报告里即使标注了权限风险，之后谁来盯？操作是否安全、合理都无法解答。

合约审计后上线只是安全工作的起点，而非终点。项目需要的是覆盖合约全生命周期的持续安全，而不是一份一次性的审计报告。

Gate 安全团队：审计能告诉用户代码能做什么，但告诉不了用户项目方打算做什么。

这是我们做上币审核这些年体会最深的一点。很多事故的根源在项目方的意图上。一个合约可以在技术上完全合规，所有者权限的设计也在正常范围内，但项目方照样可以挑一个时间点把这些权限用起来：改交易规则、开黑名单、增发代币。这些动作在代码层面全是合法的，审计报告也不会标成漏洞，因为它们本来就是设计的一部分。

所以技术审计之外还得有一层约束。Gate 的做法是在上币环节做严格的项目筛选和审核，同时和项目方签署不作恶声明，再对履约情况做监督。这一层要解决的就是审计解决不了的那部分：代码没有漏洞，不代表这个团队不会做出损害用户的选择。

已上架的项目我们会做定期安全审计，同时用链上事件监控跟踪合约状态，用户也可以随时查某个合约当前的风险项。

Q2. 既然一次审计不等于一直安全，项目方和整个行业应该怎么调整？

Gate 安全团队：加密行业有一个结构特征：很大一部分业务，尤其是 DeFi，运作模式接近模块化金融。各类平台由共享组件搭建而成，合约、软件库、钱包、价格预言机、跨链桥、连接服务商、网页界面，以及用于推送更新的系统。

所以除了自己的合约安不安全，更要问的是依赖的每一个环节是否依然可靠。上游某一个组件出现故障，损失会沿着链条向下传导。回头看那些重大攻击，问题往往出在比协议逻辑更早的环节：供应商、开发工具、软件触达用户的方式，或者用户批准转账的流程。

GoPlus 合伙人 Adam：黑客利用自动化工具高效挖掘漏洞的攻击范式已然成型并快速蔓延，攻击从「专家手工研究」变成了「流水线」。如果行业的思维还停留在「上线前找审计公司出一份报告」，或者发现了风险再找安全公司「亡羊补牢」，就像用弓箭对抗机关枪。用同样高效的工具去对抗攻击，才是唯一有效的路径。

行业层面的调整方向，是从「一次性审计」或「出问题后找专家」升级为「全生命周期持续安全」。以 GoPlus DeepScan 的「合约安全三件套」为例，这是一个可落地的闭环：

上线前，Token 安全自查：几分钟快速自检貔貅盘/蜜罐、恶意增发（Mint）、黑名单、异常交易税、Owner 权限等后门风险；

上线时，AI 合约审计：深度分析源码、权限管理与业务逻辑，扫描语法层和业务逻辑层漏洞，交付结构化审计报告；

上线后，持续安全监控与定期体检：实时跟踪新增漏洞情报、攻击事件与外部依赖（预言机、跨链桥、第三方协议）风险，持续判断项目是否受影响，常态化预警。定期对合约进行安全体检，持续审计。

Q3. 这两年漏洞挖掘的方式发生了哪些变化？同样一笔资产，放在链上和放在交易所，安全模型有什么不同？

GoPlus 合伙人 Adam：坦率地说，短期看目前攻击方挖漏洞的方式更多样化了。原因有三：

1）自动化工具大幅降低了挖洞门槛，过去需要顶级安全研究员数周的工作，现在攻击流水线几分钟就能跑完；

2）链上沉淀了海量「当年审计过」的旧合约，对攻击者来说是一个储量巨大的「金矿」；

3）攻击是单向变现，找到「一个」漏洞就够了，防御者却要守住「所有」漏洞。

黑客挖走这些钱用了几分钟，防御方找出同样的漏洞其实也只用了几分钟。区别只在于，项目方有没有在黑客之前把工具正确地用上。

更关键的是，防御方拥有攻击方没有的三个结构性优势：

1）先手优势：防御者可以在上线前、运营中无限次复查，攻击者只能赌防御者没做过复查；

2）成本优势：AI 审计按次或包年收费，成本低到可以常态化、全量化；

3）知识复利：安全知识库随每一起新攻击事件持续进化，防御系统越用越强。

在链上、链下两种模式中，「谁在保护你的资产」和「你面对的风险类型」完全不同。

链上自托管：安全 = 私钥安全 + 合约安全。 你是唯一安全责任人——私钥丢失/被盗没有"客服"可申诉；每次交互都承担链上风险（授权漏洞、钓鱼签名、貔貅盘）；优势是资产不依赖任何平台信用。

交易所托管：安全 = 平台安全 + 账户安全。 私钥由平台管理（冷热钱包分离、多签、风控），相当于你把「技术安全」外包给了交易所；但也需妥善保护好自己的交易所账号安全（密码、2FA、钓鱼、API Key 等），同时一定要注意选择平台信用有保障的交易所。

总的来说，链上是「私钥保护 + 自我操作风险」，交易所是「平台信用 + 安全基建风险」，前者考验你的 Web3 安全意识，后者考验交易所平台基建和你的账户安全习惯。

Q4. 作为交易平台，Gate 在安全性上有哪些提升？

Gate 安全团队：首先我们会对已上架项目做定期安全审计，同时通过链上事件监控持续跟踪合约状态。合约有没有升级、权限有没有变更、是否出现异常的大额操作，这些都是需要持续看的，因为一份上币时的检查结论，和 Adam 讲的审计报告一样，也有保质期。用户也可以随时查询某个合约当前的风险项。

再说平台自己这一块。Gate 的安全漏洞赏金计划一直开着，全球的安全研究人员发现问题都可以提交给我们，渠道有三个：sec@gate.com、工单，以及 HackenProof 平台。我们要求项目方接受检查，自己这边也得接受检查，这件事不应该只有单向的要求。

说完币和平台，再说账户。

我们的建议是别去找那个「最安全的地方」，按使用频率把钱分开放更实际：要经常交易的留在现货账户里，随用随取；半年一年都不会动的，放进 Gate 保险箱。

保险箱用的是 MPC 加 2-of-3 签名。私钥被拆成三片，用户设备、Gate 和一家独立第三方各拿一片，完整的私钥在任何环节都不会被拼出来，Gate 和那个第三方谁都没办法单独发起一笔交易。所有转出还要再等 48 小时才到账，这 48 小时是留给用户的安全缓冲期，期间随时可以把这笔转出冻掉。大部分被盗案例里，用户察觉到不对劲都比攻击者晚一步，而链上转账一旦出去就撤不回来，但在 Gate 保险箱的这 48 个小时里，用户随时可以把它冻掉。退一步说，就算真出了意外，48 小时的延迟也给你留出了发现和冻结的时间。

再说第二个，Gate 的账户安全保障计划。

Gate 账户安全保障计划基于安全分。账户的安全设置原本散在各个页面里，登录验证、身份验证器、双重验证、通行密钥、交易限额、提现限额，用户很难说清自己到底做到了哪一步。安全分把这些项折成一个 0 到 100 的分数，开了哪些、还差哪些，打开就能看到；分数有变化的时候，系统也会提醒用户去补。

安全分到 80 分、账户状态正常，就能开通保障计划。开通之后意味着用户自己把防护做到位之后，又多了一层兜底：保障生效期间，账户里的资产如果被人未经授权转走，符合规则的话可以申请补偿，单次事件额度目前最高是 20 万美元。这个额度接下来会有所增加，根据 VIP 等级分档最高为 100 万美元。申请要在事件发生后 45 天内，通过「我的保障」联系安全客服提交，材料包括警方报案记录、资产转出记录这些。

Q5. 一份完整的审计报告应该包含哪些内容？安全评分、关键发现、修复建议分别该怎么用？

GoPlus 合伙人 Adam：一份能指导行动（而不是只能存档）的审计报告，至少应该包含四个要素：

1）安全评分（可量化等级），用来做「快速筛选」，不是用来做「最终结论」。项目方可以把评分作为内部安全评估的量化锚点，每次迭代后对比变化；交易所适合用于上币初筛，把明显不达标的项目挡在第一道门外；普通用户则把评分当作「入口」，低分直接避雷，高分再看关键 findings。

2）关键发现（高风险问题与核心结论），用来做「决策」。这是报告的「执行摘要」：哪些问题是 blocking 级别、必须先修才能上线。对非技术背景的管理者和上币评审团队来说，读懂关键 findings 就够了。

3）问题详情（漏洞证据与影响说明），用来「定位问题」。这是给技术团队的部分，包括漏洞位置（精确到合约、函数、代码行）、漏洞类型、严重性等级、攻击路径描述与根因分析。好的问题详情要给出可复现的执行路径与触发条件，而不只是一份问题清单。

4）修复建议（可执行整改方案），用来「闭环」。修复建议必须具体到代码层面、可执行，并且修复后要重新扫描回归验证，形成「评分、关键发现、问题详情、修复、复扫」的完整闭环。

Gate 安全团队：我们从做合约审计功能的实践补充三点。

第一，最容易被省略的，恰恰是最前面的两项：审计目标与限制，还有范围说明。我们给报告定了八个维度，审计目标与限制、范围说明、严重性矩阵、优先级判断、漏洞详情、风险路径、威胁模型、关键函数分析和修复建议，而决定读者会不会把整份报告读歪的，就是前两项。限制没写清楚，读者会默认它什么都覆盖了；范围没写清楚，读者分不出它审的只是主合约，还是连资金池、策略合约、预言机和外部依赖都一起审了。很多宣传只写一句「已通过审计」，不说审了什么，这种说法基本没有信息量。

第二，看关键发现时，要把那些单独拎出来都不算漏洞的风险放在一起看。举一个报告里常见的组合：合约所有者可以把地址拉进黑名单冻结资产，交易对可以被重置、导致普通用户转不了账，最低持仓要求会让用户没法完整卖出，单一所有者还能随时改动多项关键规则。这四条分开看都属于正常设计，合起来就意味着这个合约的控制权高度集中在一个人手里。