DeFi创业者经验谈：如何选择安全审计商，该有怎样的“审计观”

在加密行业中，审计是保证项目完整性和安全性的不可或缺的部分，细心观察不难发现，比较优秀的项目诸如Lido、Compound在审计方面的投入是7位数美金起步的「天文数字」，并且往往会就同一批产品代码，雇佣多个审计服务商介入审计。

这一方面可以看出DeFi夏天以来，链上头部业务/产品所获颇丰，有充足弹药持续打出，构筑更纵深的竞争壁垒；另一方面其实也为同行中的诸多项目、创业者展开了审计的一个切面：审计工作并不会只是「花钱-雇人-出报告-宣发」的流程化简单工作，而是应该有一套完整的「审计观」和方法论——什么样的产品交付需要审计？如何挑选供应商？如何最大程度确保审计工作的有效性？怎样可以最经济实惠又安全完备地完成审计工作？

笔者将在下边的文章中，结合自身经验，从具体做项目，搞创业的角度出发，与各位读者讨论下我心中理想的「审计观」是如何。

安全服务商纵览，货比N家

审计供应商的可选性在近2-3年的光景中可谓是喷涌式增长，盘点下来市面上比较常见的审计供应商大概有15-20家左右（排名不分先后）。

就笔者经验和其他同行的交流，国内的 Peckshield、SlowMist，海外 Trail of bits、OpenZeppelin的综合美誉度、技术能力和覆盖完整度属于第一梯队。

整体上，华人主导的供应商（主要是第一行）仍然是加密行业中文项目的主要选择，时差为零且语言畅通，报价上也比较高性价比，国产供应商的报价基本上是12K-15K USD/人/周的水平，随着市场的淡季/旺季会有所波动；

相比之下，海外的供应商在中文行业存在度比较低，但这些供应商或因品牌溢价，或因创始团队资源关系，或因覆盖度/技术能力，普遍定价还是明显高于华人供应商，基本上是1.5-2倍的报价差异，并且往往能够出一批巨额的订单，譬如OpenZeppelin曾经被Compound以单季度上百万美金的价格聘请进行审计。

与市面上主流的审计供应商平行存在的还有一类服务商，诸如Immunefi、PwnedNoMore。笔者定义为「白帽社区」，在传统的安全圈子中应当属于比较成熟的业态，在加密行业中，属于新近两年冒出来的，不过依然吸引了不少项目进驻采用，基本的运作模式就是项目方去该平台发布希望被审计/debug的模块（前端、后端、合约等），定义bug的严重度以及对应的赏金，以期吸引「白帽」主动report bug，解决问题。这种形式应该视为「公司制审计商」的一种有益补充，须要项目方能够精准，清晰有效地定义bug的分类、层级和需要对方覆盖的范围，并大方地给出悬赏金，往往能获得意外的惊喜。

审计流程、方法论和省钱指南

对于项目方而言，首次要请审计商review前，需要一定的设计和安排，一般建议要保证做到这几个点：

1-送审的代码在内部要进行过2轮以上的测试，如果时间允许，最好是再有一轮社区的公测后再送审，避免「显而易见」的问题需要付费解决；

2-送审的代码要尽量确保按照项目方的milestone，批量打包，一次性交付审计，避免拉高成本；

3-确保送审的对接人清楚产品整体的运行原理、大致的代码量以及主要模块的分布，避免在initial setup阶段需求传达不清，给项目拿回一份不合适的报价单；

4-排期要比较，重要产品节点有必要付费锁定排期。

尽管市面上的供应商诸多，但是每家的排期差异巨大，送审人有必要就同一段代码向至少3个审计商发出评估请求，获得排期、报价和工作量评估，重要的产品节点务必预付费一部分（一般建议30%-50%），锁住审计商的排期，避免影响进度。

就笔者的经验，中文供应商的预约建议至少提前2-4个周（相较于希望报告产出的日期），海外供应商的预约至少提前1个月（这里主要是考虑时差、对接人转介以及老外普遍不996的耗时）。

在秉承上边的送审原则后，确定排期、报价，项目代码交付审计商开始review，过程中，比较负责任的审计商一般都会就review中的疑问和项目方进行讨论，具体的对接人 & 项目方的技术人员有责任也有必要多和审计商沟通排解问题，对接人在过程中须要确保：

1）审计的中间进度如期进行；

2）审计商提供的初版审计报告须要让项目团队中的2位不同技术人员去交叉review，再同步审计商定稿与否；

3）审计对接人要做好勾联同步的作用，确保本团队关键技术、产品人员，与审计商中实际进行代码review的人建立群聊，而不是被动地等待审计商出报告和签字；

4）【锦上添花】对接人能够在审计过程中对市面上其他家审计商发的「安全事件review报告」保持关注，对可能匹配自家项目的情况，主动提出和审计商沟通，前置地把可能没覆盖的问题给debug。

项目方要有鲜明的「偏见」，保留后门有必要

审计公司大多能够完成的工作是代码本身的质量、逻辑、安全性是否完备、十足，对于代码和业务关联触碰很少。往往会出现代码逻辑/安全性上调整到位了，业务逻辑受到了影响的情况。

譬如对于合约权限升级，费率调整、token增销等关键module，从业务早期发展来说，其实需要一个项目方内能做决策的core member单签控制，应对市场变化/突发安全事件及时调整，而不是一味地追求多签控制，影响危机时刻项目的应变能力。

合理的「后门保留」/「超级权限」不仅事关项目，亦可能攸关行业生死，试想，如果BitMex不曾拔网线，Circle不曾停赎回，BNB Chain不曾「停链维护」，行业如今又是什么光景？

持续沟通和分享才能推动长线安全

审计商的服务只能debug而不能确保100%安全，安全事故总有可能在某个点引发。

一方面项目方要主动和审计公司沟通，商讨如何处置（可能是赔付、免费二审、退款，或者其他方案）。

另一方面，每一个安全漏洞的发现 & 补足其实也都事关行业整体的进步，在不涉及项目方关键商业利益的情况下，鼓励所有项目方积极与审计公司一起，公开化地recap每个类似的问题，能更好地让行业共享一套更高的安全标准，其实也是在长期地降低每家项目方审计的成本。

项目方决策层应具备hakcer思维，重视社区力量

审计是一场旷日持久的资金战争，是项目方竞争的重要壁垒。

一方面应该在每一个产品的milestone之间都持续地投入资金，雇佣知名、可靠的外部审计商来覆盖可能的安全漏洞；另一方面也应该重视社区的力量，鼓励诸如Immunefi、PwnedNoMore这样子白帽社区介入项目的安全buidl。

笔者曾以约30K美金的赏金，成功请到一位社区中的白帽人员，debug并协助修复部署了一个托管百万美金的合约。

少另辟蹊径，多复用成熟合约，也是降本增效的好手段。

加密行业的创业门槛已然大幅提高，数百万美金的融资额即使在眼下的市面上，也属于屡见不鲜的存在。从前边的讨论可以看出，要真正支撑一整套可靠、安全、稳定的dApp非常困难，哪怕是Compound、Lido、Uniswap等行业顶流应用也无法保证十足安全。

所以，从成本节约的角度出发，每个初创项目在合约、模型的选用上要最大可能嵌套入已有的成熟设施，避免另辟蹊径，常见的DEX、Lending、收益聚合器、流动性质押 & 再质押，乃至衍生品交易、合成资产等品类，其实都有一批成熟、可用的基础设施给新晋项目方复用、嵌套，这在给项目方降低安全成本的同时，也有效地增强了项目本身的安全性，并且能够确保系统的安全随着复用对象的升级而进化。

从行业的整体角度来讲，要做到十足的安全，其实需要市场上所有主体的参与和贡献。

对于审计商而言，1）防范项目的小心思。部分项目的常见操作是把真正去审计的代码，和面向社区交付上线的代码搞成两套，这样子审计商其实是白白挂了牌子和责任，所以在项目正式部署后，一般建议审计商再去二次查验下实际版本的代码；2）有必要探索和「保险」的结合，对于采购服务到一定量以上的客户，理应在安全事故发生后有赔付机制，保障项目方的权益；3）更广泛地和同行公布审计案例 & debug经验。审计商其实和医疗行业类似，整体的进步一方面依靠长线的技术、科研投入，另一方面高度依赖案例量的积攒。从这个角度看，时常被用户调侃的「PR式审计」其实也是推动行业进步的一种动能，至少更多的审计案例被行业共享。

对于用户而言，1）冷热钱包分离，专门dApp用专门的钱包地址，常常清理陌生授权，不操作莫名的空投token等，degen的时候永远要安全生产；2）高净值的用户有必要养成常常翻阅各家审计商公布的安全事件报告的习惯，对常见的安全风险做到心中有数。